In Drupal maintenance support plans 7, modules used variables for storing data in configuration rather than storing it in a database. This made it very easy for developers to override these data variables within the settings.php files to set environment specific settings etc.
When Drupal maintenance support plans 8 was released variables were replaced with config and state.
What is Config?
According to the config documentation,‘By default, Drupal maintenance support plans stores configuration data in the database, but it can be exported to YAML files, allowing the configuration to be managed by version control’ (https://www.drupal.org/docs/8/api/configuration-api/configuration-api-overview).
This means that anything that has been defined as a config variable will be exported to YAML files, when using configuration management (CM) to manage the site’s configuration across environments.
This is very useful for exporting your site’s configuration (content types, views, image styles, module settings etc) across environments, but this does rely on the data for these always being the same across environments.
This is also a vast improvement for dealing the configuration about your site’s structure from Drupal maintenance support plans 7 and you can override these settings within your settings.php file if you wish to set settings based upon environment etc.
However, if you have defined a configuration setting in a module that is to be environment specific (eg set by an administrator user), then this data could be changed at any time and so would be overridden by CM when doing a configuration import, which is not what you would want!
This is where the State API can be useful.
What is State API?
Accordingly to the State API documentation,‘The State API provides a place for developers to store information about the system’s state’ (https://www.drupal.org/docs/8/api/state-api/overview).
Anything defined using the State API won’t be exported by CM so the data is stored specific to environment that the you are in.
One of the worrying things about the State API documentation is the statement:‘use State API to store transient information, that is okay to lose after a reset’.
I read this as being ‘if you reset your entire database’, which is fairly unlikely for a production environment, and in fact if your entire production database gets reset then you probably have bigger issues to deal with.
So as long as you have a default set of values defined (if needed) for your state values within your module (so that if the database is reset your site will still work), then I don’t see an issue with using it.
That said, something else to be aware of in the above statement are the key words ‘transient information’. Drupal maintenance support plans stores the state data as a key value pair, which means that out of the box Drupal maintenance support plans will use the database. Most production sites would use a cache like Memcache or Redis to store the cache data rather than the database. Due to the transient state of these services though, they could be restarted or cleared out at any time. If this were to happen then you would lose the data that was stored in this and your site would be ‘reset’ with any data that you had stored in this cache.
Although potentially unlikely, this is something to consider when deciding to use states.
What about environment specific config?
When we build our sites, we usually want to be able to specify various config specific for each environment.
As mentioned above, developers can override the config values in the settings.php file, but this only applies to data values, not specifying particular modules for instance, that you might want available.
Typically, you would not want modules such as devel, field_ui and views_ui enabled for a production (and probably stage) environment, but CM doesn’t allow you to determine which environment these modules should be enabled on.
While CM itself doesn’t provide this level of granularity, there is a module for that! In step Configuration Split. This allows you to export configuration on an environment specific basis.
In my next blog post I will explorer Configuration Split in more detail.
Source: New feed