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 cexcommand to export all the configuration on development env, - I use the
drush cimcommand 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();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-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:
More articles
Author(s)
Making of : “La nuit des Losers”
lanuitdeslosers.ch, built fast: paper wireframes, a bold hand-drawn identity, then Claude Code to prototype and ship. A mouse-tracking hero animation, a bowling game made of sponsor logos, and a few bugs we’re keeping.
lanuitdeslosers.ch, built fast: paper wireframes, a bold hand-drawn identity, then Claude Code to prototype and ship. A mouse-tracking hero animation, a bowling game made of sponsor logos, and a few bugs we’re keeping.
Author(s)
Dark mode: necessity or trend
Nous faisons le tri entre idées reçues, réalités techniques et bonnes pratiques de design.
Nous faisons le tri entre idées reçues, réalités techniques et bonnes pratiques de design.
Experiment #2 – Surway, a social experiments game
Pour notre deuxième expérimentation, nous avons relevé le défi de sortir de notre zone de confort en développant Surway, un jeu vidéo jouable directement dans le navigateur, où les actions de chaque joueur restent inscrites pour tous ceux qui suivront.
Pour notre deuxième expérimentation, nous avons relevé le défi de sortir de notre zone de confort en développant Surway, un jeu vidéo jouable directement dans le navigateur, où les actions de chaque joueur restent inscrites pour tous ceux qui suivront.
