Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

Is there a best practice for including your wp-config.php file in your version control repository?

I'm considering creating a new site with this type of configuration, (similar to Alex King and Mark Jaquith):

/index.php
/local-config.php
/wp-config.php
/wp/ (core)
/wp-content/ (plugins, themes, etc.)

How can I do this without exposing my passwords to git, in case this repository ever becomes public?

Especially in Mark's post, it looks like the local-config.php can store local database details and passwords, but the production ones stay in the wp-config.php. Is this too much trouble and should I just leave wp-config.php unversioned?

share|improve this question
    
I think the way Mark Jaquith does it isn't much trouble and works fine and is slightly better than the answer below. –  Wyck May 22 '12 at 20:09
    
IMO, everything should be put under versioned control and the system should be able to handle different environments without any hackery stuff along keeping things secure and simple to work with. I just posted on how I do it, that covers all your concerns :) Let me know if you have any questions about my setup. –  Ashfame May 23 '12 at 9:09

4 Answers 4

up vote 27 down vote accepted
+50

Here is how I do it and I haven't come across anything better than this. I keep a different version of wp-config.php file under version control and then keep a file one directory above which holds all the database credentials and salts/keys. Also this way, I am able to distinguish between the type of setup I am running and do things differently on basis of that.

Here is the wp-config.php I keep under git (https://gist.github.com/1923821):

<?php

/**
* Define type of server
*
* Depending on the type other stuff can be configured
* Note: Define them all, don't skip one if other is already defined
*/

define( 'DB_CREDENTIALS_PATH', dirname( ABSPATH ) ); // cache it for multiple use
define( 'WP_LOCAL_SERVER', file_exists( DB_CREDENTIALS_PATH . '/local-config.php' ) );
define( 'WP_DEV_SERVER', file_exists( DB_CREDENTIALS_PATH . '/dev-config.php' ) );
define( 'WP_STAGING_SERVER', file_exists( DB_CREDENTIALS_PATH . '/staging-config.php' ) );

/**
* Load DB credentials
*/

if ( WP_LOCAL_SERVER )
    require DB_CREDENTIALS_PATH . '/local-config.php';
elseif ( WP_DEV_SERVER )
    require DB_CREDENTIALS_PATH . '/dev-config.php';
elseif ( WP_STAGING_SERVER )
    require DB_CREDENTIALS_PATH . '/staging-config.php';
else
    require DB_CREDENTIALS_PATH . '/production-config.php';

/**
* Authentication Unique Keys and Salts.
*
* Change these to different unique phrases!
* You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}
* You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
*/

if ( ! defined( 'AUTH_KEY' ) )
    define('AUTH_KEY', '9*W=5&lt;Rw-)c].9}g?^[:!j]h+Efr&lt;y$&lt;YmV0XOo|lOIujEE}+[R}iAQZ :Sy3wN}');
if ( ! defined( 'SECURE_AUTH_KEY' ) )
    define('SECURE_AUTH_KEY', 'APge3~H;g+b0FyNF&amp;e`$=g?qj9@FQwqFe^Q4(@p#kDa=NR? $Z9|@v*a(tOj*B+.');
if ( ! defined( 'LOGGED_IN_KEY' ) )
    define('LOGGED_IN_KEY', '5l0+:WTpj8#[V|;&lt;Iw;%rkB(A}r++HwT|s[LW!.wt.=5J!b%Z{F1/[LxQ*d7J&gt;Cm');
if ( ! defined( 'NONCE_KEY' ) )
    define('NONCE_KEY', 'zO2cmQX`Kc~_XltJR&amp;T !Uc72=5Cc6`SxQ3;$f]#J)p&lt;/wwX&amp;7RTB2)K1Qn2Y*c0');
if ( ! defined( 'AUTH_SALT' ) )
    define('AUTH_SALT', 'je]#Yh=RN DCrP9/N=IX^,TWqvNsCZJ4f7@3,|@L]at .-,yc^-^+?0ZfcHjD,WV');
if ( ! defined( 'SECURE_AUTH_SALT' ) )
    define('SECURE_AUTH_SALT', '^`6z+F!|+$BmIp&gt;y}Kr7]0]Xb@&gt;2sGc&gt;Mk6,$5FycK;u.KU[Tw$345K9qoF}WV,-');
if ( ! defined( 'LOGGED_IN_SALT' ) )
    define('LOGGED_IN_SALT', 'a|+yZsR-k&lt;cSf@PQ~v82a_+{+hRCnL&amp;|aF|Z~yU&amp;V0IZ}Mrz@ND])YD22iUM[%Oc');
if ( ! defined( 'NONCE_SALT' ) )
    define('NONCE_SALT', '|1.e9Tx{fPv8D#IXO6[&lt;WY*,)+7+URp0~|:]uqiCOzu93b8,h4;iak+eIN7klkrW');

/**
* WordPress Database Table prefix.
*
* You can have multiple installations in one database if you give each a unique
* prefix. Only numbers, letters, and underscores please!
*/

$table_prefix = 'ft_';

/**
* WordPress Localized Language, defaults to English.
*
* Change this to localize WordPress. A corresponding MO file for the chosen
* language must be installed to wp-content/languages. For example, install
* de_DE.mo to wp-content/languages and set WPLANG to 'de_DE' to enable German
* language support.
*/

define( 'WPLANG', '' );

/**
* For developers: WordPress debugging mode.
*
* Change this to true to enable the display of notices during development.
* It is strongly recommended that plugin and theme developers use WP_DEBUG
* in their development environments.
*/

if ( WP_LOCAL_SERVER || WP_DEV_SERVER ) {

    define( 'WP_DEBUG', true );
    define( 'WP_DEBUG_LOG', true ); // Stored in wp-content/debug.log
    define( 'WP_DEBUG_DISPLAY', true );

    define( 'SCRIPT_DEBUG', true );
    define( 'SAVEQUERIES', true );

} else if ( WP_STAGING_SERVER ) {

    define( 'WP_DEBUG', true );
    define( 'WP_DEBUG_LOG', true ); // Stored in wp-content/debug.log
    define( 'WP_DEBUG_DISPLAY', false );

} else {

    define( 'WP_DEBUG', false );
}


/* That's all, stop editing! Happy blogging. */

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
define('ABSPATH', dirname(__FILE__) . '/');

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

And here is the local config file which I keep one directory above WordPress root and this also makes it outside the web accessible directory, so in case apache stops parsing PHP files and start throwing them out, our database credentials are still safe (https://gist.github.com/1923848):

<?php

/**
 * WordPress config file to use one directory above WordPress root, when awesome version of wp-config.php is in use.
 *
 * Awesome wp-config.php file - https://gist.github.com/1923821
 */

/* WordPress Local Environment DB credentials */

define('DB_NAME', 'project_21');
define('DB_USER', 'root');
define('DB_PASSWORD', 'root');
define('DB_HOST', 'localhost');
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');

/* Keys & Salts */

define('AUTH_KEY',         '5H%)s-nQ,+fn0gwg/p1UjBTmCQ?l[8-!>Q{MW&?X3DM,OF;TaI<SOOTrl0+-@) *');
define('SECURE_AUTH_KEY',  '+%rr@,XIt-V+[.B9++uH1L,L+r)uq}5(:~=&4~Lk|.LV|y;R}fEo?G}+Sntf_JN}');
define('LOGGED_IN_KEY',    'Szv!gQm9#(L&TUD OnM`>sXGge:m1j`L2 5sO;hRNVhlN>IUED1/`%<[ly-GxVJ ');
define('NONCE_KEY',        'o-Jo;>G#-%~,[ki@REqXV%4^I.HDnc.3]P;e8];4pJt% $xe5K<aOb|a2*QKV4c-');
define('AUTH_SALT',        '8-tQb3d|W8,;Y_#mfuFB.1&b%U2fnlLD|F&yH).tLRX=ANEdNap{78o|9tqv6JPt');
define('SECURE_AUTH_SALT', 'RSa%^qd~T|@+!-;qgh,qK-GJ}zPpgxz#+@v6-I;BMwqT`TzGTtg_^n*ILxGOdbq4');
define('LOGGED_IN_SALT',   ']+XV)YK.Q-EU1vR [BT!Y$!d(J_[AO37OP[Fg[/esFx;6cI-L[^O|cvtw9F[;_*Q');
define('NONCE_SALT',       'iP{nTQBzy&f^hSbwBgyan.v9<+ErvAMi2ymLhz`Tl-fF?HXa(j<W`wA*8U3R#-|w');

This way if the above file is named local-config.php, my system behaves like a local install. If its named staging-config.php, it behaves like a staging install and if its named production-config.php. It helps me have different values of certain constants like debugging have different values under different environments and still have everything under SCM (git). Possiblities are endless and there is no hackery required for different enviornments.

This makes sure you never reveal any sensitive information to public anyway and I use this just to start off any project I work on, I have stronger keys in place by default and as soon as I add them to the second config file one directory above, those are used instead of the ones defined here. Bliss!

share|improve this answer
    
Really smart thinking. –  weberwithoneb May 24 '12 at 16:52
    
I like this approach, I'll probably end up doing something like this. –  jjeaton May 26 '12 at 9:25
    
How do you reference the-local-config-file-in-the-parent-directory from the main config file? Via a symbolic link, or via ../ (i.e. ../filename) somewhere? — I didn't find any ../ in the main wp-config.php file. –  KajMagnus May 30 '13 at 3:04
1  
@KajMagnus The constant DB_CREDENTIALS_PATH does that. –  Ashfame May 31 '13 at 22:19
    
@Ashfame Thanks! I didn't notice dirname. –  KajMagnus Jun 1 '13 at 4:46

How can I do this without exposing my passwords to git, in case this repository ever becomes public?

If your wp-config.php file is in version control, then any passwords it contains will also be in version control. The only way to avoid that is to not put the file in version control.

Is this too much trouble and should I just leave wp-config.php unversioned?

My gut feeling would be to keep wp-config.php unversioned entirely. But there are some ways around it.

Extract the part of wp-config.php that contains your passwords and hashes into a separate file and include() it in the regular wp-config.php file. Then, place wp-config.php under version control, but keep your include() file separate.

wp-config.php:

<?php
/**
 * The base configurations of the WordPress.
 *
 * This file has the following configurations: MySQL settings, Table Prefix,
 * Secret Keys, WordPress Language, and ABSPATH. You can find more information
 * by visiting {@link http://codex.wordpress.org/Editing_wp-config.php Editing
 * wp-config.php} Codex page. You can get the MySQL settings from your web host.
 *
 * This file is used by the wp-config.php creation script during the
 * installation. You don't have to use the web site, you can just copy this file
 * to "wp-config.php" and fill in the values.
 *
 * @package WordPress
 */

/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');

/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');

include( 'conf.php' );    

/**#@-*/

/**
 * WordPress Database Table prefix.
 *
 * You can have multiple installations in one database if you give each a unique
 * prefix. Only numbers, letters, and underscores please!
 */
$table_prefix  = 'wp_';

/**
 * WordPress Localized Language, defaults to English.
 *
 * Change this to localize WordPress. A corresponding MO file for the chosen
 * language must be installed to wp-content/languages. For example, install
 * de_DE.mo to wp-content/languages and set WPLANG to 'de_DE' to enable German
 * language support.
 */
define('WPLANG', '');

/**
 * For developers: WordPress debugging mode.
 *
 * Change this to true to enable the display of notices during development.
 * It is strongly recommended that plugin and theme developers use WP_DEBUG
 * in their development environments.
 */
define('WP_DEBUG', false);

/* That's all, stop editing! Happy blogging. */

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

You can see now that passwords and hashes are not included in wp-config.php at all.

conf.php:

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'database_name_here');

/** MySQL database username */
define('DB_USER', 'username_here');

/** MySQL database password */
define('DB_PASSWORD', 'password_here');

/** MySQL hostname */
define('DB_HOST', 'localhost');


/**#@+
 * Authentication Unique Keys and Salts.
 *
 * Change these to different unique phrases!
 * You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}
 * You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
 *
 * @since 2.6.0
 */
define('AUTH_KEY',         'put your unique phrase here');
define('SECURE_AUTH_KEY',  'put your unique phrase here');
define('LOGGED_IN_KEY',    'put your unique phrase here');
define('NONCE_KEY',        'put your unique phrase here');
define('AUTH_SALT',        'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT',   'put your unique phrase here');
define('NONCE_SALT',       'put your unique phrase here');

But honestly, at this point you're just adding a redundant level of abstraction here. The entire reason wp-config.php is separate in the first place is because it's environment-specific. You shouldn't be copying it from a local server to production at all ... so it shouldn't be under version control at all.

share|improve this answer
    
It does seem like some extra work, but I can see the benefits in ensuring that all the wp-config settings are in sync between environments. –  jjeaton May 26 '12 at 9:25
    
Splitting wp-config.php has an extra benefit: you can include conf.php into a non WP script without loading the whole of WordPress. –  Tamlyn Aug 14 '13 at 10:48

Mark's example assumes you are working with a private repo:

if ( file_exists( dirname( __FILE__ ) . '/local-config.php' ) ) {
  include( dirname( __FILE__ ) . '/local-config.php' );
  define( 'WP_LOCAL_DEV', true ); 
} else {
  define( 'DB_NAME',     'production_db'       );
  define( 'DB_USER',     'production_user'     );
  define( 'DB_PASSWORD', 'production_password' );
  define( 'DB_HOST',     'production_db_host'  );
}

Instead of defining the credentials you could just as easily create a production-config.php file and include it within the conditional check:

if ( file_exists( dirname( __FILE__ ) . '/local-config.php' ) ) {
      include( dirname( __FILE__ ) . '/local-config.php' );
      define( 'WP_LOCAL_DEV', true ); 
    } else {
     include( dirname( __FILE__ ) . '/production-config.php' )
    }

Then in your unversioned production-config.php:

  define( 'DB_NAME',     'production_db'       );
  define( 'DB_USER',     'production_user'     );
  define( 'DB_PASSWORD', 'production_password' );
  define( 'DB_HOST',     'production_db_host'  );
share|improve this answer
    
Even if it's a private repo, I wouldn't want the passwords stored in it, and would want the flexibility to make the repo public if I desired. The production-config.php is probably a good way to go. –  jjeaton May 26 '12 at 10:28

You could commit the wp-config.php file to the repository without your secret strings, then run:

git update-index --assume-unchanged wp-config.php

This will tell git to assume that the file is, well, unchanged.

share|improve this answer
3  
Good to know, wasn't aware of assume-unchanged switch but here are my two points: (1) If you git add the file directly, it will be added to the index. So there is a risk you can accidentally add it at some point. (2) Merging a commit with this flag on will cause the merge to fail gracefully, so that you can handle it manually which makes this as not an elegant solution. It can only be used to temporarily ignore changes while something like a development session. Here read more - gitready.com/intermediate/2009/02/18/… –  Ashfame May 26 '12 at 6:21

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.