1

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."}

1 Answer 1

2

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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