Drupal 8 information types
- Configuration (we distinguish between simple configuration and configuration entities)
The cool thing is that almost everything besides the content is configuration: module settings, module states, blocks, blocks layout, content types, fields, display modes, and so on and so. All this information gets processed on the configuration import. This makes the deployment process really simple.
Where configuration lives
Let’s take a look at the settings.php file on a fresh Drupal 8 installation.
$config_directories['active'] = 'sites/default/files/config_XXXX/active'; $config_directories['staging'] = 'sites/default/files/config_XXXX/staging';
The XXXX here is a long hash, generated to protect your configuration from any web access.
The active directory is supposed to keep currently active configuration. I said “is supposed” because by default this directory is empty, active configuration is stored in the database. It is made this way for performance and security reasons. However, you can force configuration storage to use the file system with the Configuration Tools (config_tools) module. (Don’t you remember that there is a module for that? ;))
The staging directory is the place from where the configuration is imported/synchronized. It’s also empty until configuration will be exported/imported.
The sites/default/files directory is ignored by Git, but you probably want to store your configuration files under the version control system. The recommended way is to move the configuration directory outside the Drupal installation so that it cannot be accessed from the web. The easiest way would be to move the configuration directory under the sites/default path (but leave the hash in the directory name for security reasons).
Built in user interface
The core Configuration Manager (config) module provides a basic UI for configuration administration. It can be found at the admin/config/development/configuration path. The most interesting tab there is “Full Import/Export”. The whole site configuration could be exported as a .tar.gz archive at the Export sub-tab. And you can import such an archive at the Import sub-tab on another site instance.
When using this UI, the newly imported configuration is not being used after an archive being imported. Instead, the archive contents are extracted into the “staging” folder. Then it should be synchronized at the Synchronize tab where you can view the actual changes that the new configuration brings.
That’s it! Deployment is in the core now. No additional tools required! If you don’t want to use UI, Drush for your service as usual.
drush config-export # will export active configuration to the staging directory drush config-import # will import configuration from the staging directory
Let’s take a look at an exported configuration example file.
# file: system.site.yml uuid: c78fd9aa-b327-4514-9d00-bc72a1f40f27 name: 'My cool site' mail: email@example.com slogan: 'Drupal 8 rules!' page: 403: '' 404: '' front: node admin_compact_mode: false weight_select_max: 100 langcode: en
The configuration name here is system.site, it’s a configuration unit. All configurations should be prefixed with the module or theme name, system in this case.
The file contents looks pretty much like a PHP array. And when you work with configuration from the code, you actually get/set it as arrays.
Best practice tip
If you don’t have much settings, it’s a good practice to keep them in one configuration named as your_module_name.settings.
Working with configuration from a module or theme
Drupal 8 provides really good API for working with configuration. Just take a look at the code.
$config = \Drupal::config('system.site'); // Instance of Drupal\Core\Config\Config $front_page = $config->get('page.front'); // 'node' $page_settings = $config->get('page'); // array( // '403' => '', // '404' => '', // 'front' => 'node', // ) $config->set('page.front', 'my-front-page'); $config->save();
Stay tuned for Part 2, where I will talk about: Module/theme defaults, Exporting configuration into a module, Configuration override system, Reacting on configuration changes, Configuration schmea/metadata and configuration entities.
UPD: part 2