I already searched here and there but couldn't find anything definitive.

I have WordPress multisite and I have a plugin (activated on each site) which requires to set a slug parameter in wp-config.php.

Unfortunately each site of the network requires a different slug parameter.

I'd like to know if it is possible to put an if statement in wp-config.php in order to define these parameters based on $_SERVER['HTTP_HOST'] variable.

Code is the following:

if ( stristr( $_SERVER['HTTP_HOST'], 'site.com' ) ) {

    define('ABC_PRODUCT_SLUG', 'slug-for-en');

elseif ( stristr( $_SERVER['HTTP_HOST'], 'de.site.com' ) )
    define('ABC_PRODUCT_SLUG', 'slug-for-de');

Is that possible and reliable? Are there any possible drawbacks?


| improve this question | | | | |
  • Yes, this is possible and reliable – kero Jan 29 '18 at 17:18
  • 3
    a plugin that requires wp-config changes? just don't use it. Maybe you should actually ask a question about your problem instead of about the only solution you see ;) In theory you should do this can of code in a "must use" plugin. The config file is not something you should modify if you have any alternative as the impact of breaking it during modification is just too big – Mark Kaplun Jan 29 '18 at 17:21
  • Yes, this is possible and perfectly reliable. I have done this for a long time as part of my standard WP install by defining a SITE_ENVIRONMENT constant for local | staging | live and have variable settings dependent on the environment. Ideally you would define the constant elsewhere (and then include/fetch it) so that you can still push your wp-config between environments without overwriting the environment value. Note: Some hosts - especially dedicated Wordpress managed hosts - don't let you manage wp-config. They always supply workarounds though. – onebc Jan 29 '18 at 17:28
  • Note that ` $_SERVER['HTTP_HOST']` is not defined on the command line, e.g. when using WP-CLI. – swissspidy Jan 29 '18 at 17:33
  • Though it's possible and reliable, but just don't do it. Instead, you can create site specific plugins (or for the whole network) and define those constants there. – Abhik Jan 29 '18 at 17:59

Following on from the comments thread...

Here's a method I've used for a long time for handling the 'not ideal' scenario of different configurations between environments. The following is a heavily cut-down representation of wp-config.php but it demonstrates the idea...

  * 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

/** Environment: LOCAL || STAGING || LIVE **/
define('BCUK_SITE_ENV', 'LOCAL');

/** System/CMS defaults **/
e.g. settings that are common across all environments

e.g. different db settings, memory limits, paths, etc.

elseif (BCUK_SITE_ENV == "STAGING"):
e.g. different db settings, memory limits, paths, etc.

e.g. different db settings, memory limits, paths, etc.


// Remaining wp-config bits go here e.g. salts, lang settings, etc

As you can see I prefer to assume that 'else' means the live settings, just for safety's sake.

I have also used versions of this method where the definition of the environment is actually in a separate file that is included e.g. replacing define('BCUK_SITE_ENV', 'LOCAL'); with an include statement that pulls in a file (something like 'environment_config.inc.php') in which there is just one line that is used to change the environment constant. That way you can always push your wp-config.php between environments without actually affecting which environment is currently configured.

In all the above, you could easily adapt it to either base your logic directly on the value of $_SERVER['HTTP_HOST'] or to configure your environment variable/constant on the value of $_SERVER['HTTP_HOST'].

Hope that all makes sense. It's definitely not the only way, but hopefully it demonstrates that it is definitely a robust and workable method. Whether it works for your particular plugin development scenario only you will know.

| improve this answer | | | | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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