Drupal is the famous content management system used by a lot of organizations all over the world for developing the best website for their business. The Drupal web development company is a free and open source and has a large community of developers and tech enthusiasts who are constantly working to upgrade the features and tools of it.
The site configuration data is stored in a consistent and perfect manner by Drupal. For a Drupal web development site, it is not recommended that the configuration changes are made on the live site.
The Drupal system is designed in such a manner that the live configuration is made easy, local testing can be done, the files can be exported and the deployment is done easily. The configuration of your site is integrated with the version control and it can be stored as part of the codebase.
The database, by default stores the “active configuration”. This is for the security and the performance reasons. The export and import of the complete configuration can be done in the form of YAML files. The configuration can be done completely or it can be done in a single piece. The Drush or the Drupal Console config commands can be used for this purpose.
The changes can be made and verified at a distance from the live environment of your site by importing and exporting the configuration changes in different and varied environments such as the Staging, Development, and Production.
Theme and Module Configuration Files
At the time when the extensions are enabled, the import of the default configuration with the themes, modules, and distributions is done to the active configuration store. The config/install directory is where you will find the default configuration of the extension.
It is very easy to export, import and synchronize the configuration of the site with the core module of the Configuration Manager. It can be made possible through the Manage > Configuration > Development > Configuration Synchronization.
The review of the changes made can be done before importing them. Using the copy/paste workflow, you can either export or import a single object. You can use the above step when you are planning to just move a new view from one environment to another.
The entire site configuration can also be dumped as yml files to the tar.gz file. This will work only when you are moving the configuration between the two copies of the same website and for this reason, the UUIDs of the site must match.
Now, if you want to check the UUID of the site using the CLI, it can be done easily using the below-given command.
If you want to get it using Drush, write the following command.
drush cget system.site
Using the Drupal Console, you can get the UUID with the following command.
drupal debug:config system.site
You can enable new modules, content types or fields after the entire synchronization is completed. So now, the configuration changes that are made on the site is now live for production.
A key tip for you is that you should do a database-dump before each synchronization of the active and staging directory. This strategy of database-dump can help you to save your life when you need a roll-back strategy.
Drush archive-restore(drush arr) and archive-dump(drush ard) are the feasible methods for doing this.
The common pitfalls that arrive while doing the configuration management are as follows:
The mismatch of UUID
The method of moving the configuration between the new and the old versions of the same site is known as configuration management. There is a Universally Unique Identifier (UUID) for distinguishing one site from the other.
The UUID that is stored in the config table’s system.site row of the target database must match the UUID of the configuration for which you are importing. In case the match doesn’t take place, then the following message will arrive “Site UUID in source storage does not match the target storage.”
There are various ways for this but for the standard use cases, you should instantiate a completely new version of your site from the database dump of your old site. This will surely match the UUID.
Content Grey Areas vs Configuration
In the latest version of the Drupal web development i.e.Drupal 8, there are four wide categories of data such as the Session, State, Content, and Configuration. As per the name, the work of CS is there for managing the configuration alone.
Confusion can arise in the cases where it is not clear that what you are exporting is the mixture of content and configuration. This problem can arise when you are trying to export a custom block. The issue here is that the export that you are doing is partly content and partly configuration. The placement of the block is configuration but the block content is content and it can’t be managed through the CS.
If you are not aware of this, then you will receive the broken block handler signifying that the block is missing or broken as you are missing the content or you have to now enable the original module. This may happen after the deployment of the block placement is done from the source environment to the target environment without the block content present on the target environment.
You can change the location of the config_sync directory
The creation of the config sync directory will be done at the following path at the time of installation of Drupal.
The problem is that this directory may contain the sensitive information so one should put it in a directory that is site-specific. One another way is to place the config sync directory outside of the Webroot so that it is prevented from being served by the web server. This can be done in settings.php
$config_directories = array(CONFIG_SYNC_DIRECTORY => ‘../config/sync’);
Non-destructive configuration imports
The configuration synchronization is a nothing or all process by default. Here, the data is taken in the sync directory by you and it is placed in the config table of the database and anything already there is overwritten. The partial flag can also be used when you are importing through the drush(drush config-import —partial). This will help you to import the new items of configuration, update the ones that are existing and prevent the deletion process of the configuration items in the database that are yet not stored in the sync directory.
Environment Specific Configuration
The configuration split module has to be used when you want to store different configuration items in different environments. You will be able to set up the split directories where the environment specific configuration items can be stored. For example, if you are requiring different settings of performance locally than in production then it is also possible over here.
Configuration split will help you to do this thing in a better way rather than simply overriding the settings in a settings,php file. While you are adding the configuration items at the time of configuration split, you can add them to the grey or blacklist.
Here, the configuration items can be stored in one or more configuration split but it can’t be done in the default directory
The configuration items on the greylist remain in the default configuration directory and are not removed automatically. If the currently active split contains the configuration item, then it takes higher precedence over the copy that is stored in the default directory.
So, remain beware of the above pitfalls while you are doing configuration management with the latest version of the Drupal web development company i.e. Drupal 8.