The Configuration Management module has been integrated into the Drupal 8 Core which lets you make and verify site configuration changes in the development, staging and production environments respectively. Configuration Management is gradually turning out to be an effective replacement for Features as it lets you create and modify configuration entities with great ease.
Here I am sharing my first hand experience with the Drupal 8 Configuration Management System with the help of a few case scenarios.This is what the Development Menu of Drupal 8 looks like with a Configuration Management link that leads you to the Configuration Page.
Configuration Management Workflow : Importing, Exporting & Synchronizing Configuration
As you know the file-based Configuration management system in Drupal 8 lets you use version control for configuration and to track changes as well. The configuration on your site can be imported, exported and synchronized via Manage> Configuration > Development > Configuration management (admin/config/development/configuration).
# Creating a Content Type
I created a Blog Content Type titled “Blog Content” while configuring multiple fields like Blog title, blog description, Author Name, Publishing Date and Author Image. Then I exported this single configuration file and imported it in the production environment.
This resulted in adding new content type “Blog Content” in production. This was cool.
# Creating a Menu
I created a Menu titled “Footer Menu” with Menu Links like Home, About Us and Contact Us. But when the changes were exported only the menu was created while the menu links failed to reflect in the production version.That's because even though I have created menu links with external URL, this might have created a conflict if menus were created while creating a page. Drupal will not allow adding menu without the page if is an internal URL.
# Enabling a Core Module
I enabled a few Core Modules like Aggregator, Serialization, Ban, Actions in the Development Version. The modules got enabled in the production version when the changes were imported from development.
# Installing a Contributed Module
I installed a few contributed modules and enabled them in the Development Version. I could not export the changes to the production version as the Configuration management system failed to support it.
# Creating a Taxonomy Vocabulary
I created a Taxonomy Vocabulary titled “Programming Languages” with Taxonomy Terms like PHP, Java, .Net, C++ and C. Although the Taxonomy vocabulary got reflected in the production version, the Taxonomy terms failed to show up.
# Creating a Basic Block
I created a Basic Block with fields like a block description and a body. The changes when exported showed up in the production version as well.
# Making Permission Changes
I made some Permission Changes for the authenticated and anonymous users that extended certain privileges like posting comments on a blog post. The changes when exported showed up in the production version as well.
# Creating a Custom Block Type
I created a Custom Block Type titled “Recent Content” with fields like title, description and Image. The changes reflected perfectly well in the production version after they were exported.
# Enabling Core Themes
I enabled some Drupal 8 core themes like Classy, Bartik and Seven which got enabled on the production version as well once the changes were exported.
# Installing a Contributed Theme
I installed some contributed themes like Acquia Marina, Bootstrap and Bear Skin in the development version. Like in the case of Contributed Modules I could not export the changes to the production version.
# Creating a User Role
I created a User role titled “Blog Author”and allowed in some permissions to moderate content. The permissions got reflected along with all the other changes once the changes were exported to the production version.
#Creating an Image Style
I created an image Style titled “Author Image” with dimensions measuring 120x140 pixels. The changes showed up successfully once they were exported to the production version.
Full Import/Export
The full export feature lets you download an archive of all the active configuration files. It also lets you import on a development site, synchronize, make changes, package up again and import and synchronize back on the live site as well.
The changes made on the development site will be saved into the active storage on the development site. These changes can be exported and imported on the live site, the import copies the YAML files into the staging directory. The full development site configuration can be exported at admin/config/development/configuration/full/export. This will create a compressed file called config.tar.gz .
On the live site when you navigate to admin/config/development/configuration/full/import and upload the compressed file, you can review the changes before finalizing the content that needs to be imported. When the changes are imported, the development site gets updated with the live changes. Further changes are made on the Development version before they are imported back to the live version.
Once the import is complete the changes need to be synchronized. The synchronization process leads to the elevation of the staging directory contents to the live configuration wherein new fields and content types get added while new modules get enabled.
All the changes made on the development version are then deployed to the live version. In case there are direct changes made in the live version, the changes have to be exported from the production version to the development version.
We are Valuebound are committed to creating exceptional web experiences and solutions based on your unique business needs. For further information on our service offerings, please Contact Us.
