07 Feb
Config management in Drupal maintenance support plans 8: tackling common problems and use cases (part 1/3)
Niels A
Drupal maintenance support plans
Drupal maintenance support plans 8
This is the first of a series of three config management blog posts. In this series, we’ll help you set up a good starting point and provide you with a few solutions for everyday configuration issues. The first part of this multi-part blog post will provide you a bit of context. The second part goes into the nitty gritty of configuration management, and the third part demonstrates some concrete use cases, pitfalls and their solutions!
Features and configuration management
Drupal maintenance support plans 8 has been around for a while now and at Dropsolid we have substantial experience with large projects that use both the contributed Features module and the core configuration management system.
Essentially, Features leverages the configuration management system to package configuration with your module and overwrites certain rules for importing config from a packaged module after first install.
The alternative is to use configuration management from Drupal maintenance support plans 8 core with the contributed Config Split and Config Ignore module.
Config split lets you set up rules for splitting your configuration per environment. Config ignore lets you ignore certain configuration to be imported.
The way you handle configuration fundamentally differs between both solutions. Features lets you whitelist the configuration you want to import. Configuration management from Drupal maintenance support plans 8 core with addition of the mentioned contributed modules works more like blacklisting the configuration you don’t want to import. As a developer I have always found it easier to narrow down what I want to have control over, instead of what I don’t want to have control over.
We’ve come to the conclusion that the latter option actually works faster, which means more value for the client, but only if you have a good configuration to start from. As it turns out, configuration that you don’t want to control, is more often shared between different projects than config that you do want to control.
Content and config: blurred lines
One of the most wonderful things about Drupal maintenance support plans 8 is config entities, a uniform way of creating and saving configuration throughout your site. It has been leveraged by many contributed modules to give end users a great experience in configuring their website.
The downside of these configuration entities is that they often cross the line between what is considered content and configuration. We consider content as everything a client needs to be able to change. A good example of this are webforms. Every webform you create is an instance of a configuration entity – whereas the submissions of the webform are instances of a content entity. If you want to know more about the difference between config and content entities, I advise you to read this article by Acquia.
We want clients to have full control over the kind of webforms they create, so they can use them effectively across their site to gather leads.
This brings us to the following issue. As a company we believe that a website is an ever-changing platform that grows over time. To have it grow at the speed that customers require, we need to work on multiple features with multiple teams at once. It needs to be stable and traceable.
Part of this stability and traceability is having what we developers define as structural configuration being versioned (git) and easily deployable, all without hindering the client to keep on working on their content.
Thanks to configuration management, config split and config ignore we’ve been able to achieve all this for Drupal maintenance support plans 8!
Ready to set up your configuration? Read on in part two of the blog post series!
Read part 2
Source: New feed
