Handling the Drupal settings.php file when using Git across multiple servers - database

We are using Drupal 6 for a number of our web sites. We are moving them all into Git for version control. Each site will have a dev server, a test server and a live server. I'm wondering about best practices for handling the settings.php file since the database connection info will obviously differ between the servers. I've seen solutions ranging from switch statements to an include file. The include file solution stated here http://drupaldork.com/2011/11/local-settings-development-sites seems to be a good solution, but I'm wondering what you end up leaving in the ACTUAL settings.php file. In other words if each server has a "local" settings file like settings.local.php which contains the connection info for that particular server, do you remove the connection info from the real root settings.php? Or do you leave it? If you leave it, what do you put there? Does it matter because it just ends up getting overridden by the local settings file anyway? Should the connection info in the main root settings.php be some kind of default connection info?

One of the way, i would prefer is not to keep settings.php in Git.
https://help.github.com/articles/ignoring-files
In our case, we keep codebase under Git but settings.php files are ignored. So that Prod, Sandbox & local environment will have their own settings.php files.

We keep 2 settings.php file includes in the repo but not the base settings.php.
My settings.php file for production is as normal. Just databsae settings and default stuff.
For development my settings.php file has the database settings and an include to a file that is stored in the repo called settings.dev.php.
# Additional site configuration settings.
if (file_exists('/Users/User/Sites/site.com/sites/default/settings.dev.php')) {
include_once('/Users/User/Sites/site.com/sites/default/settings.dev.php');
}
Settings.dev.php includes switches to turn off caching and set environment indicator:
// Secure Pages
$conf['securepages_enable'] = FALSE;
// Environment Indicator
$conf['environment_indicator_color'] = 'blue';
$conf['environment_indicator_enabled'] = TRUE;
$conf['environment_indicator_text'] = 'Development Server';
// Robots disable
$conf['robotstxt'] = 'User-agent: *
Disallow: /';
// Turn off Caching and such
$conf['cache'] = FALSE;
$conf['page_compression'] = FALSE;
$conf['preprocess_css'] = FALSE;
$conf['css_gzip'] = FALSE;
$conf['preprocess_js'] = FALSE;
$conf['javascript_aggregator_gzip'] = FALSE;
Settings.php is ignored in the repo but the settings.dev.php is included. We also keep a settings.stage.php in the repo. Setting values in settings.php file for prod needs to be done very carefully as it can interfere with some modules and prevents you from being able to quickly change settings if needed. But you can do the same thing with a settings.prod.php.

Related

Restrict a file to being edited in gitlab (.gitlab-ci.yml)

as you know We have a file for gitlab ci configuration named '.gitlab-ci.yml'
and this file shouldn't be edited by any developers so I decided to avoid developers to edit it.
the thing is gitlab said you can lock file to being edited but the prerequirement of this action is to have a premium account.
what can I do when I haven't premium account?
do you have any idea to lock a file to being edited?
Check if you have access to a Push Rule feature, which is a kind of pre-receive hook.
Or you can set a pre-receive hook if your GitLab server is on-premise.
In both cases, you can list the files being pushed in that hook, and fails if one of them is .gitlab-ci.yml.
As of today, the official way (~workaround~) for this seems to be creating a different repository for the .yml file with more restrict permissions and then referencing that .yml file from your project:
A .gitlab-ci.yml may contain rules to deploy an application to the production server. This deployment usually runs automatically after pushing a merge request. To prevent developers from changing the .gitlab-ci.yml, you can define it in a different repository. The configuration can reference a file in another project with a completely different set of permissions (similar to separating a project for deployments). In this scenario, the .gitlab-ci.yml is publicly accessible, but can only be edited by users with appropriate permissions in the other project.
https://docs.gitlab.com/ee/ci/environments/deployment_safety.html#protect-gitlab-ciyml-from-change
Also, there is a discussion on this matter here:
https://gitlab.com/gitlab-org/gitlab/-/issues/15632

stuck on Overview line at the time of drupal database update

I am trying to up-grade my website 7.22 to 7.26 and i was follow all the steps which is defined in Drupal forum.
The steps are:
Log in as a user with the permission "Administer software updates".
Go to Administration > Configuration > Development > Maintenance mode. Enable the "Put site into maintenance mode" checkbox and save the configuration.
Remove all old core files and directories, except for the 'sites' directory, the original install profile in the 'profiles' directory and any custom files you added elsewhere.
If you made modifications to files like .htaccess or robots.txt, you will need to re-apply them from your backup, after the new files are in place.
Sometimes an update includes changes to settings.php (this will be noted in the release announcement). If that's the case, replace your old settings.php with the new one, and copy the site-specific entries (especially the lines giving the database name, user, and password) from the old settings.php to the new settings.php.
Download the latest Drupal 7.x release from http://drupal.org/project/drupal to a directory outside of your web root. Extract the archive and copy the files into your Drupal directory.
Re-apply any modifications to files such as .htaccess or robots.txt.
Run update.php by visiting http://www.example.com/update.php (replace www.example.com with your domain name). This will update the core database tables.
If you are unable to access update.php do the following:
Open settings.php with a text editor.
Find the line that says:
$update_free_access = FALSE;
Change it into:
$update_free_access = TRUE;
.
But it is stuck on Overview line at the time of drupal database update.
I click continue and nothing moves forward. There are no errors or anything, I'm not sure how to proceed.
Please suggest me what can i do .
Thank you in advance.

weblogic domain server.out log file manually modified locked

I have a 2 questions regarding Weblogic.
I am using Weblogic 10.3.6.
Yesterday I deployed the war file.
Following are my 2 questions
1) When I restart the server the sys out logs at location
domains//servers//logs/Server-name.out
domains//servers//logs/Server-name.log
are not getting updated
Actually logs were getting updated initially but I cleared the log file by manually opening the log file and deleting its content.
Later I found on official oracle website that
"Oracle recommends that you do not modify log files by editing them manually. Modifying a file changes the timestamp and can confuse log file rotation. In addition, editing a file might lock it and prevent updates from WebLogic Server, as well as interfere with the Accessor"
I think my log files got locked due to above reason.
Is there any way I can do to get updates in log files.
I have restarted the server as well but the logs are not getting updated.
2) I have deployed my web application using packed war file. When I deploy using war file it is expected that the war file gets exploded at some temporarily location in weblogic server. War gets deployed successfully but when I checked the contents of
WEBLOGIC/bea10.3.6.0_BI/user_projects/domains/Managedserver_7011_7012/servers/Server-chanakya/tmp/_WL_user
It is blank.
I was expecting that war should get exploaded inside the _WL_user folder. But it is not happeining right now.
Please let me know what I can do with respect to above problems.
Thankx in advance.
First question:
Generally speaking the .out file is created during server start and not updated once the server reaches the RUNNING state. The .log file should be updated continually however. It is safe to delete both of these files and once the server is restarted they should be regenerated. If for some reason they are not, go to server name -> Logging tab -> Log file name and specify the full path and name for a new log file.
Second question:
If you chose nostage for your deployment, it will not be copied to your server and will live wherever the file originally was. stage mode should copy the file to tmp/_WL_user after starting out under a stage directory. You can remove your deployment from the weblogic admin console and also delete the tmp and cache folders and try the deployment again if you need to. It's also possible the deployment failed... check the Deployments link in the admin console to make sure it reached the Active state.
Last - welcome to Stack Overflow. In general you should ask one question at a time.

Changing the host of my CakePHP site

I bought an application made in ​​Cakephp, everything was fine before, but once I wanted to host it on another server (with keeping the same database and folders), I find the links to the CSS, JavaScript and images do not work.
Please I have no knowledge in CakePHP.
Did you clean up the database?
I had to change some entries by hand once, because the servername/ip/url didn't change.
go to your db management system and search for your old IP/Path/domainname etc....
Did you copy over the (often hidden) .htaccess files when you moved to the new host?
There are three .htaccess files, one in the root of your site, on in the /app directory, and one in /app/webroot
Is mod_rewrite enabled on your new server?

magento upgrade from 1.6.2 to 1.7.0.2 - Will the db base be changed?

i am looking into upgrading my magento community from 1.6.2 to 1.7.0.2.
First i will do this on my test server, but there are some errors during updating in magento connect, so i have to upload some files my self ...
but when i going to put these data into the live environment, can i just simply copy my data from the ftp to the live website?
Or are there also some new/changed settings in the database?
And if yes on the last question, which lines are changed?
I was able to successfully upgrade Magento from 1.6.1 to 1.7.using Connect Manager.
Here are the steps I had foung and followed
Go to yourdomain. com/magento/downloader/ (of course, make this
match your installation’s path.
Because I had installed Magento using tar.gz package provided with a skin I wanted to use, Magento Connect didn’t have all the
extensions listed for upgrading. I had to type
“connect20.magentocommerce.com/community/Mage_All_Latest” in the
“Install New Extensions / Paste extension key to install”
If you run into an error along the lines of “CONNECT ERROR: Package ‘Mage_All_Latest’ is invalid” repeated several times, once
for each package, it is because the files already exist, and you
have to remove a line of code in order for it to over-write data.
After everything has updated, you will probably have some errors. Make sure you clean the cache and session directories (delete
everything in /var/cache and /var/session)
If you receive a “500 Internal Server Error” it is more than likely because of file and folder permissions. It took .5 sec to
reset all of the permissions to what they needed to be.
If you receive a “Service Temporarily Unavailable The server is temporarily unable to service your request” error on a Magento
formatted header, it is probably because the store is set to offline
mode to prevent visitors from screwing up the installation process.
To fix this, delete the“maintenance.flag” file found in the root of
your magento installation directory.
Everything should be ready!
Avoid upload core library changes via ftp.
The fastest and more secure way is to patch your application using the diff files
patch -p0 -f < 1.6.2.0-1.7.0.0.diff
Then when you first visit your site Magento will automatically upgrade your db
best way to update is get a fresh mage zip 1.7.1 or whatever, and connect it to your current DB. When you go to index - the new install will update your DB to the latest MAge DB. This way you dont have to use connect etc. The mage zip has its own sql updates.
Make sure you put your current theme into the new install etc, and test it 1st on localhost etc.

Resources