Reputation: 23613
Im working on a large project and the settings.php file is in the repository. I need to override the username and password locally as my details are different. I dont want to affect the main settings.php file as this is used by other developers. Can this be done? If I could create a new file then I could ignore it locally with GIT meaning it didnt affect the repository.
Upvotes: 1
Views: 496
Reputation: 31
You can add this to the bottom of your settings.php file:
/**
* settings file for local development only.
*
* This file should NEVER be committed to version control and should never exist
* on a non-local development machine.
*/
if (file_exists('./' . conf_path() . '/settings.local.php')) {
require './' . conf_path() . '/settings.local.php';
}
Then just do like you suggested and add the settings.local.php to your .gitignore file.
The link posted by Screenack should be all you need.
Upvotes: 1
Reputation: 4043
You can do this in a number of different ways:
Make the file in your dev environment read only. This makes it so you can set your local file to whatever without it being overridden by syncs from version control. You will need to manually exclude the file with each commit though.
Exclude the file from version control. If you need the settings to be available to other developers, you can create a separate file called settings.base.php that they can use that to create their own local settings.
My preference is to make it so the settings are universal. Obviously it's not a problem to have whichever resources have the same username and password, where you might run into an issue is with the host. You can have each developer/server override it's host mapping to the actual server you want it pointed to. In Linux it's /etc/hosts, in windows it's /windows/system32/drivers/etc/hosts.
Example host settings for #3:
Developer machine
127.0.0.1 databaseserver.com
Staging machine
192.168.1.100 databaseserver.com
Production machine likely wouldn't need a remap. Unless you never had a hostname for the database, in which case you create some made up hostname like my.database.srv and then set that for production as well.
One thing that is handy about all of the above, especially #3, is that it is a platform independent solution, so you could do this for any type of project (not just Drupal).
Upvotes: 0