Drupal 8 – Differences between Configuration API & State API

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 Campaignmonitor,
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.

“ I took the problem upside down. ”

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 whitout success:

Using the flags --skip-module or --partial of drush cim
Hooking the Event like ConfigEvents::DELETE and 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: