<p>Yes, I've also found that in this case "dev.mywebsite.com" has to be <strong>after</strong> "mywebsite.com". </p>

<p>It's a bit counter intuitive. Lately I've been using the <a href="http://craftcookbook.net/recipes/210" rel="nofollow">"Foolproof Multi-Environment Config" from Craft Cookbook</a>, mostly because it keeps the config files more sane.</p>

CC BY-SA 3.0
2017-12-18T10:29:50.250Z
Updated Cookbook link: https://craftcookbook.net/recipes/foolproof-multi-environment-config
darylknight
CC BY-SA 3.0
2014-11-08T21:28:00.883Z
Sorry André, I've gotta move that checkmark. You won on speed, but Alex won on in-depth analysis. Thanks though!
Lindsey D
CC BY-SA 3.0
2014-11-04T09:47:55.087Z
2014-11-04T09:47:55.087Z
André Elvan
<p>In my experience, the <strong>order does matter</strong>. The array is read in order from top to bottom testing the domain for a match against each criteria (key). If there's a match, that array of settings is used and continues down the list <strong>which can possibly overwrite variables that were previously set</strong>.</p>

<p>For example, in this configuration...</p>

<pre><code>// Development
'dev.mywebsite.com' =&gt; array(
    'database' =&gt; 'dev_mywebsite',
),
// Production
'mywebsite.com' =&gt; array(
    'database' =&gt; 'prod_mywebsite',
),
</code></pre>

<p>Your development site <code>http://dev.mywebsite.com</code> will be matched <strong>twice</strong>, once with the full url dev.mywebsite.com and second as a partial match for mywebsite.com. The second match will overwrite the <code>database</code> setting and your dev site won't load properly.</p>

<p>The <a href="http://buildwithcraft.com/docs/multi-environment-configs">Craft documentation example</a> uses the domain criteria of <code>'.com'</code> and <code>'.dev'</code> with <code>'.com'</code> coming after <code>'.dev'</code>. That works fine because <code>example.com</code> will never partially match <code>example.dev</code>.</p>

<p>The <a href="http://craftcookbook.net/recipes/210">"Foolproof Multi-Environment Config" from Craft Cookbook</a> works by matching specific server name <code>local.domainname.com</code> or <code>stage.domainname.com</code> first and using a the production environment as a fallback.</p>

<p>Similarly, you could use the config order to your advantage and only change settings as they're needed. The <code>'*'</code> array can be used as a default/fallback environment.</p>

<p>For example:</p>

<pre><code>// Default environment: Production
'*' =&gt; array(
    'tablePrefix' =&gt; 'craft',
    'server'   =&gt; 'localhost',
    'user'     =&gt; 'xxxxxxxx',
    'password' =&gt; 'xxxxxxxx',
    'database' =&gt; 'prod_mywebsite',
),
// Development
'dev.' =&gt; array(
    'user'     =&gt; 'xxxxxxxx',
    'password' =&gt; 'xxxxxxxx',
    'database' =&gt; 'dev_mywebsite',
),
</code></pre>

<p>Notice this setup doesn't change the <code>server</code> setting since the dev environment also uses <code>localhost</code>.</p>

<p>Also, I've seen setups where the fallback settings are the Development or Local instead of Production. The advantage there is that your Production
site data would be protected from errors in your config file. I've actually made a mistake where the staging server domain didn't match the config file and changes from the staging server were happening to the Production database (bad!) because it was the fallback. </p>

<p>Here's an example from Focus Lab's EE Master Config for ExpressionEngine:
<a href="https://github.com/focuslabllc/ee-master-config/blob/master/config/config.env.php">https://github.com/focuslabllc/ee-master-config/blob/master/config/config.env.php</a></p>

<p>As a side note, the "Foolproof Multi-Environment Config" could probably use the strtolower() function on the 'HTTP_HOST' variable as Bjørn Børresen points out in a commit message in the EE Master Config.</p>

<pre><code>switch (strtolower($_SERVER['HTTP_HOST']))
</code></pre>

<blockquote>
  <p>HTTP_HOST should be made lowercase as one cannot guarantee that it always is (most browsers do this, but not all) - in which case the wrong config will be loaded</p>
</blockquote>

CC BY-SA 3.0
2014-11-08T21:26:33.150Z
Wow, excellent analysis Alex! Very interesting to know about the cascading nature of these settings... this is exactly the kind of information I was looking for. Thanks!
Lindsey D
CC BY-SA 3.0
2014-11-08T21:41:47.113Z
As the original author of the [Foolproof Multi-Environment Config](http://craftcookbook.net/recipes/210), I've gone ahead and added the `strtolower`. Thanks for the tip!
Lindsey D
CC BY-SA 3.0
2014-11-07T12:26:50.043Z
2014-11-07T12:26:50.043Z
Alex Roper
<p>When using a <a href="http://buildwithcraft.com/docs/multi-environment-configs" rel="noreferrer">multi-environment config</a>, Craft will select which settings to use based on a partial string match of the server name.</p>

<p>Given the following example, does "dev.mywebsite.com" need to be <strong>first</strong> or <strong>last</strong>? Clearly it contains "mywebsite.com" within it, so the order is relevant.</p>

<pre><code>return array(
    // All environments
    '*' =&gt; array(
        'tablePrefix' =&gt; 'craft',
    ),
    // Production
    'mywebsite.com' =&gt; array(
        'server'   =&gt; 'localhost',
        'user'     =&gt; 'xxxxxxxx',
        'password' =&gt; 'xxxxxxxx',
        'database' =&gt; 'prod_mywebsite',
    ),
    // Development
    'dev.mywebsite.com' =&gt; array(
        'server'   =&gt; 'localhost',
        'user'     =&gt; 'xxxxxxxx',
        'password' =&gt; 'xxxxxxxx',
        'database' =&gt; 'dev_mywebsite',
    ),
);
</code></pre>

<multi-environment>
Proper order of multi-environment config
# Proper order of multi-environment config

(Asked by: username_0 on 2014-11-03)

When using a multi-environment config, Craft will select which settings to use based on a partial string match of the server name.
Given the following example, does "dev.mywebsite.com" need to be first or last? Clearly it contains "mywebsite.com" within it, so the order is relevant.
return array(
    // All environments
    '*' => array(
        'tablePrefix' => 'craft',
    ),
    // Production
    'mywebsite.com' => array(
        'server'   => 'localhost',
        'user'     => 'xxxxxxxx',
        'password' => 'xxxxxxxx',
        'database' => 'prod_mywebsite',
    ),
    // Development
    'dev.mywebsite.com' => array(
        'server'   => 'localhost',
        'user'     => 'xxxxxxxx',
        'password' => 'xxxxxxxx',
        'database' => 'dev_mywebsite',
    ),
);

**Tags:** multi-environment


---

## 2 answers

### Answer by username_3 on 2014-11-07. Score: 13 | Accepted answer

In my experience, the order does matter. The array is read in order from top to bottom testing the domain for a match against each criteria (key). If there's a match, that array of settings is used and continues down the list which can possibly overwrite variables that were previously set.
For example, in this configuration...
// Development
'dev.mywebsite.com' => array(
    'database' => 'dev_mywebsite',
),
// Production
'mywebsite.com' => array(
    'database' => 'prod_mywebsite',
),

Your development site http://dev.mywebsite.com will be matched twice, once with the full url dev.mywebsite.com and second as a partial match for mywebsite.com. The second match will overwrite the database setting and your dev site won't load properly.
The Craft documentation example uses the domain criteria of '.com' and '.dev' with '.com' coming after '.dev'. That works fine because example.com will never partially match example.dev.
The "Foolproof Multi-Environment Config" from Craft Cookbook works by matching specific server name local.domainname.com or stage.domainname.com first and using a the production environment as a fallback.
Similarly, you could use the config order to your advantage and only change settings as they're needed. The '*' array can be used as a default/fallback environment.
For example:
// Default environment: Production
'*' => array(
    'tablePrefix' => 'craft',
    'server'   => 'localhost',
    'user'     => 'xxxxxxxx',
    'password' => 'xxxxxxxx',
    'database' => 'prod_mywebsite',
),
// Development
'dev.' => array(
    'user'     => 'xxxxxxxx',
    'password' => 'xxxxxxxx',
    'database' => 'dev_mywebsite',
),

Notice this setup doesn't change the server setting since the dev environment also uses localhost.
Also, I've seen setups where the fallback settings are the Development or Local instead of Production. The advantage there is that your Production
site data would be protected from errors in your config file. I've actually made a mistake where the staging server domain didn't match the config file and changes from the staging server were happening to the Production database (bad!) because it was the fallback. 
Here's an example from Focus Lab's EE Master Config for ExpressionEngine:
https://github.com/focuslabllc/ee-master-config/blob/master/config/config.env.php
As a side note, the "Foolproof Multi-Environment Config" could probably use the strtolower() function on the 'HTTP_HOST' variable as Bjørn Børresen points out in a commit message in the EE Master Config.
switch (strtolower($_SERVER['HTTP_HOST']))


HTTP_HOST should be made lowercase as one cannot guarantee that it always is (most browsers do this, but not all) - in which case the wrong config will be loaded

> **Comments:**
> **username_0**: Wow, excellent analysis Alex! Very interesting to know about the cascading nature of these settings... this is exactly the kind of information I was looking for. Thanks!  
> **username_0**: As the original author of the [Foolproof Multi-Environment Config](http://craftcookbook.net/recipes/210), I've gone ahead and added the `strtolower`. Thanks for the tip!  

---

### Answer by username_1 on 2014-11-04. Score: 3

Yes, I've also found that in this case "dev.mywebsite.com" has to be **after** "mywebsite.com".

It's a bit counter intuitive. Lately I've been using the ["Foolproof Multi-Environment Config" from Craft Cookbook](http://craftcookbook.net/recipes/210), mostly because it keeps the config files more sane.

> **Comments:**
> **username_0**: Sorry André, I've gotta move that checkmark. You won on speed, but Alex won on in-depth analysis. Thanks though!  
> **username_2**: Updated Cookbook link: https://craftcookbook.net/recipes/foolproof-multi-environment-config  

---

