How State is specific to the specific environment, when its actually pushed to all environments with DB sync?

Question

I am working with a Drupal 8 setup when production, test and development environments which periodically sync database. In Drupal 7 it was easy to override the $conf variables in settings.php to force a site in maintenance mode. However, in Drupal 8, the maintenance_mode is not a configuration anymore, but a state that is not possible to override from settings.php, so we have to use additional drush command after each sync to put one of the environments to maintenance mode.

And I am confused how come State API documentation asserts it's environment-specific, when in fact, it gets synced together with database and it is not easy to keep environment-specific settings using State API.

On the contrary, $config is easy to override in settings.php (which is excluded during sync), so it does provide easy way of setting environment-specific configurations.

Answer 1

When you copy your development/testing database to your production database, you're effectively replacing your production site's state with your development site's state. Therefore if you put your production site in maintenance mode, then import a database that says the site is not in maintenance mode, then your site will stop being in maintenance mode.

Conceptually, state is specific to an environment, so long as you aren't copying your database when you push changes from development to production.

Your solution may be to avoid doing these database imports altogether. If you are just making configuration changes on your local development site and just need to push those, you can export the site's configuration to code, commit it to version control, push that config to production and then import it. (See https://www.drupal.org/docs/configuration-management for info.)

If you are creating content in the local development environment that you need to push to production, then you may want to look at using the Migrate API.

If you absolutely must push these database updates but want the production site to remain in maintenance mode when you do it, then you'll need to put your development site into maintenance mode before copying its database to production.