<p>I think P&amp;T changed the behavior in Craft 3.1.0 and newer. Before 3.1.0 it was necessary to have <code>'allowAdminChanges' =&gt; true</code> with updates in/to project config.</p>

<p>To be 100% safe you can always enable admin changes when you're on the command line by using this config line in production environments:</p>

<pre><code>'allowAdminChanges' =&gt; (php_sapi_name() === 'cli'),
</code></pre>

<p>In most installations we even go step further and have a second domain available, which also enables admin changes when this domain is used (for emergencies), where <em>www.yourdomain.com</em> would be the normal domain and <em>admin.yourdomain.com</em> could be the one with admin changes enabled:</p>

<pre><code>'allowAdminChanges' =&gt; (php_sapi_name() === 'cli' || strpos($_SERVER['HTTP_HOST'], 'admin.') !== false),
</code></pre>

CC BY-SA 4.0
2020-02-15T12:01:36.567Z
2020-02-15T12:01:36.567Z
Matthias Redl-Mann
<p>I've just updated a multi-environment site from Craft 3.3.5 to 3.4.5. Here's our config/general.php (irrelevant bits removed):</p>

<pre><code>return [
    '*' =&gt; [
        'allowAdminChanges' =&gt; false,
        'allowUpdates' =&gt; false,
        'devMode' =&gt; false,
        'useProjectConfigFile' =&gt; true,
    ],
    'dev' =&gt; [
        'allowAdminChanges' =&gt; true,
        'allowUpdates' =&gt; true,
        'devMode' =&gt; true,
    ],
    'production' =&gt; [],
];
</code></pre>

<p>The update succeeded in the development environment (localhost) but the production deployment failed*. Here's the post-deployment command:</p>

<p><code>/path/to/composer install --no-interaction --prefer-dist --optimize-autoloader &amp;&amp; ~/user/craft project-config/sync</code></p>

<p>When the deployment failed, I went to /admin and received the "Finish Up" button. I clicked it. I then received the "Sync" button and clicked it as well. I then received an error. Unfortunately I can't remember what the error said and didn't take a screenshot. It was a nicely-formatted error (not just a PHP dump) and there was a Troubleshoot link under it.*</p>

<p>Anyway, I SSH'd into the server and ran <code>project-config/sync</code> manually. Here's what was returned:</p>

<p><code>Applying changes from project.yaml ... error: Changes to the project config are not possible while in read-only mode.</code></p>

<p>I then edited config/general.php and made <code>allowAdminChanges</code> true on production. Reloading /admin worked and I was able to log into Craft.</p>

<p><strong>At long last, here's my question</strong>:</p>

<p>We're following the advice per the <a href="https://docs.craftcms.com/v3/config/config-settings.html#allowadminchanges" rel="nofollow noreferrer">allowAdminChanges docs</a>. Does this advice only apply to non-update changes? In other words, is it a known thing that <code>allowAdminChanges</code> must be true when pushing a change to project.yaml that will update Craft?</p>

<p>--</p>

<p>*FWIW, we do have a staging deployment but it doesn't apply to this question.</p>

<p>-- </p>

<p><strong>EDIT</strong>: I ran another test, here's the error:</p>

<pre><code>A fatal error has occurred:

Status: Internal Server Error
Response: {"error":"A server error occurred."}
</code></pre>

<craft3><multi-environment><projectconfig><project.yaml>
Trouble updating Craft when allowAdminChanges is false
# Trouble updating Craft when allowAdminChanges is false

(Asked by: username_0 on 2020-02-13)

I've just updated a multi-environment site from Craft 3.3.5 to 3.4.5. Here's our config/general.php (irrelevant bits removed):
return [
    '*' => [
        'allowAdminChanges' => false,
        'allowUpdates' => false,
        'devMode' => false,
        'useProjectConfigFile' => true,
    ],
    'dev' => [
        'allowAdminChanges' => true,
        'allowUpdates' => true,
        'devMode' => true,
    ],
    'production' => [],
];

The update succeeded in the development environment (localhost) but the production deployment failed*. Here's the post-deployment command:
/path/to/composer install --no-interaction --prefer-dist --optimize-autoloader && ~/user/craft project-config/sync
When the deployment failed, I went to /admin and received the "Finish Up" button. I clicked it. I then received the "Sync" button and clicked it as well. I then received an error. Unfortunately I can't remember what the error said and didn't take a screenshot. It was a nicely-formatted error (not just a PHP dump) and there was a Troubleshoot link under it.*
Anyway, I SSH'd into the server and ran project-config/sync manually. Here's what was returned:
Applying changes from project.yaml ... error: Changes to the project config are not possible while in read-only mode.
I then edited config/general.php and made allowAdminChanges true on production. Reloading /admin worked and I was able to log into Craft.
At long last, here's my question:
We're following the advice per the allowAdminChanges docs. Does this advice only apply to non-update changes? In other words, is it a known thing that allowAdminChanges must be true when pushing a change to project.yaml that will update Craft?
--
*FWIW, we do have a staging deployment but it doesn't apply to this question.
-- 
EDIT: I ran another test, here's the error:
A fatal error has occurred:

Status: Internal Server Error
Response: {"error":"A server error occurred."}

**Tags:** craft3, multi-environment, projectconfig, project.yaml


---

## 1 answers

### Answer by username_1 on 2020-02-15. Score: 2 | Accepted answer

I think P&T changed the behavior in Craft 3.1.0 and newer. Before 3.1.0 it was necessary to have 'allowAdminChanges' => true with updates in/to project config.
To be 100% safe you can always enable admin changes when you're on the command line by using this config line in production environments:
'allowAdminChanges' => (php_sapi_name() === 'cli'),

In most installations we even go step further and have a second domain available, which also enables admin changes when this domain is used (for emergencies), where www.yourdomain.com would be the normal domain and admin.yourdomain.com could be the one with admin changes enabled:
'allowAdminChanges' => (php_sapi_name() === 'cli' || strpos($_SERVER['HTTP_HOST'], 'admin.') !== false),


---

