Best practice for versioning wp-config.php?

2 Views

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):

Read More
/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?

Post Views: 2

Related posts

Leave a Reply

4 comments

  1. 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!

  2. 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.

  3. 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'  );

  4. 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.