Before getting into the main subject, be aware that this article has been first write for the Blog of Antistatique — Web Agency in Lausanne, Switzerland. A place where I work as Full Stack Web Developer.
Feel free to read it here or check it out there: https://antistatique.net/en/we/blog/2016/06/14/drupal-8-differences-between-configuration-api-state-api
Retrieve all the code on my Gist: https://gist.github.com/Sudei/822510d2a069331a4bbe84ef55570705
Happy reading.
The other day, I faced a serious problem. On importing the configuration on my production environment. all the configurations files saved for my module were overridden by the configuration on my development environments.
What I did was very simple to understand:
- The customer change his configuration on the website, such as API Key of Campaign Monitor,
- I create a new feature, push it on production and I use the drush cex command to export all the configuration on development env,
- I use the drush cim command to import the configuration on my production env,
- The web site contain now the configuration of my development environments because every configuration is exported/imported on the Configuration API.
A solution could be to use the same configuration on the production & development environments.
But it’s not possible in our case, we should sync the local database with the production one — it’s against productivity.
On my old days with Drupal 7 I used to use:
$data = variable_set(‘test.content_types’. ‘value’);
and port this to Drupal 8 using:
\Drupal::config(‘test’)->set(‘content_types’, ‘value’);
That’s fine and it works but later when I run a drush config-import drush cim on my production server, it erase (reset) the specific configuration of my production server.
Configuration is a place to store information that you want to synchronize from development to production. This information is often created during site building and is not typically generated by regular users during normal site operation.
You should use the State API, not Configuration API, for storing local variables that shouldn’t travel between instances.
Typical usage of State API
Get a value:
$val = \Drupal::state()->get('key');
Get multiple key/value pairs:
$pairs = \Drupal::state()->getMultiple($keys);
Set a value:
\Drupal::state()->set('key','value');
Set multiple values:
\Drupal::state()->setMultiple($keyvalues);
Delete a value:
\Drupal::state()->delete('key');
Typical usage of Configuration API
Retrieve configuration as readonly:
$config = \Drupal::config('mymodule.foo');
Get a value:
$val = $config->get('key');
The configuration object that was obtained and used in the previous examples does not allow you to change configuration. If you want to change configuration, you will instead need to get the configuration object by making a call to getEditable() on the configuration factory:
$config =\Drupal::service('config.factory')->getEditable('mymodule.foo');
Set a value:
$config->set('enabled', 1);
// Save the configuration
$config->save();
Delete a value:
$config->clear('bar.boo')->save();
The State API provides a place for developers to store information about the system's state.
State information differs from configuration in the following ways:
- It is specific to an individual environment.
- You will never deploy to deploy it between environments.
- You can reset a system, losing all state. Its configuration remains.
We try out a lot of other solution wihtout success:
- Using the flags
--skip-moduleor--partialofdrush cim - Hooking the Event like
ConfigEvents::DELETEand the$event->stopPropagation();
Currently it is the most elegant solution we found to solve our problem.
However, opinions differ greatly within the community about this use case of State API.
And you what do you think ?
More information about:
Top comments (0)