During Drupalcon we sprinted on config contrib modules

The last two weeks the dust settled after an energetic and productive Drupalcon. Now there is a new stable release for all of the three most popular contrib modules Nuvole maintains: Config Filter, Config Split and Config Ignore.

Config Filter

This is the most stable module, its new releases just switch over to Gitlab CI and fix a small inconsistency in how config storages are expected to behave. The first iteration introduced a bug which the second release fixed. Thank you to the early adopters who spotted the bug.
Config Filter will remain supported but its relevance is probably going to decrease with the release of stable versions of the modules which used to depend on it but no longer do. For example Config Split 2.x and Config Ignore 3.x do not depend on Config FIlter and both now have a stable release. Modules are encouraged to switch to the Config Storage Transformation API added to Drupal 8.8. Both branches remain supported and recommended on drupal.org since most commits can be cherry picked between the branches. But for performance I would recommend the original 1.x branch. Both branches have exactly the same API, just the behaviour is different when importing or exporting.
Other config modules can use either branch for the test traits which facilitate writing tests that pass before and after refactoring from Config Filters API to the core API.

If your site indirectly depends on Config Filter because you use a module which depends on it, you need to explicitly require Config Filter when you upgrade the modules. Drupal can not uninstall a module that is no longer in the codebase. So explicitly require Config Filter, uninstall it and then in a subsequent deployment remove Config Filter.

Config Split

Our oldest Drupal 8 config module has a new stable 2.0.0 release. In it, bugs and edge cases discovered in last year's release were fixed. It also contains a "new" feature which brings back the functionality of the 1.x branch. This should help sites holding back on upgrading because the functionality changed.
With that out of the way the plan is to deprecate the 1.x branch and end support with the end of Drupal 10 support. There will not be any features added to 1.x.

Config Ignore

Previous releases of the 3.x branch have not been feature compatible with 2.x. But the stable 3.0 release has been re-written from previous 3.x beta versions. It is configurable so that most use cases can be catered for with enough creativity. One can configure the configuration to ignore for create, update and delete for both import and export. But one can also just keep it simple and then it will be as all the versions before. In particular, however, it can be configured easily to behave like: the last 2.x release, the last 2.x release with the popular patch to allow filtering on export and the previous 3.x release. Because of that the 2.x branch is deprecated as of now and it will be marked as unsupported by the end of the year on Drupal.org. There is a new hook replacing the one which existed in 2.x and which addresses the new capabilities (the old hook is still invoked and will be removed in 4.0.0). With the end of Drupal 9 being supported, PHP 8.1 is now the minimum required version, but 3.0 does not yet take advantage of the new PHP language features. So the plan for 4.0.0 is to switch the string constants to enums and switch to semantic versioning and remove the old hook.

How the pizza is made

Our Drupal 8 modules have always been maintained "like a php library". The development of UI Patterns was initially hosted on Github among other things for that reason. Config Split and Config Filter shipped with their docker compose files and scripts to symlink the module into the Drupal site. Later the custom scripts were replaced by drupal-spoons. Since the now generally available drupal-gitlab-ci is inspired by spoons and DDEV is likely becoming the recommended development environment for contributing to Drupal, I switched my local environment for maintaining the contrib modules to DDEV with the ddev-drupal-contrib plugin, the spiritual successor of drupal-spoons. For contributing to Drupal core I can only recommend the ddev-drupal-core-dev plugin created by justafish during Drupalcon. I helped beta test it and it works like a charm. That said my PhpStorm configuration had to be updated a bit even though I installed the ddev plugin for it. In particular I had to add a second server mapping for Xdebug to work as described in a comment on the issue. The release notes for the contrib modules were generated with drupal-mrn.dev.

Many thanks to everyone who contributed with feedback, code, ideas or even just listened to my ramblings as I discovered untested edge cases.

Tags: Drupal PlanetDrupalCon