Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-02-15T12:01:36.567Z
Answers.LastActivityDate: 2020-02-15T12:01:36.567Z
Answers.UserDisplayName: Matthias Redl-Mann
Body: <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>
  
Tags: <craft3><multi-environment><projectconfig><project.yaml>
Title: Trouble updating Craft when allowAdminChanges is false
ThreadText: # 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](https://docs.craftcms.com/v3/config/config-settings.html#allowadminchanges). 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),
  
  ```
  
  
  ---
  
  