Problem/Motivation

Some Configuration Development methods currently in event subscribers are useful in other config development features. Specifically, certain code in ConfigDevelAutoExportSubscriber provides functionality that will be needed as well in Configuration Packager; see #2383959: Merge generic methods into and introduce dependency on config_devel.

Examples:

  • The config scrubbing that's done in ConfigDevelAutoExportSubscriber::writeBackConfig() is already copied in Configuration Packager for the same requirement of removing data not suitable for use in module-provided configuration. Unsetting the uuid value is only one of a set of scrubbing tasks that may be needed. For example, when exporting user roles, in some cases it may be necessary to remove assigned permissions since they will include permissions for disparate functionality, not just what's appropriate for a given configuration package.
  • The writeback done in ConfigDevelAutoExportSubscriber::writeBackConfig() will be useful elsewhere, e.g., in Configuration Packager, which similarly will need to write configuration.
  • ConfigDevelSubscriberBase::getEntityId() and other methods in ConfigDevelSubscriberBase look useful outside an event subscriber.

Proposed resolution

Create a new service and pull reusable methods into it. Maybe ConfigDevelManager?

In follow-up tickets, further broadly useful methods could go here. For example, ConfigPackagerManager::getConfigTypes() and ConfigPackagerManager::getConfigByType() could be moved here (or into the Drupal core Configuration module). #2319193: Drush command for listing config dependencies is another example; rather than a Drush-only implementation, it should go into a service where it can be generally accessed (including from a Drush command).

Where appropriate, some of these methods may belong in core. See #2388833: Pull reusable routines out of configuration import/export form builders.

Remaining tasks

User interface changes

API changes

Comments

nedjo’s picture

pfrenssen’s picture

+1 to this. I just had a big WTF moment when I saw that we are instantiating the event subscriber directly and abusing it as a service.

  • joachim committed 8efcdcb on 8.x-1.x
    Issue #2388253, partial: Moved reusable config handling into new service.
joachim’s picture

  • joachim committed ce53dcf on 8.x-1.x
    Issue #2388253, partial: Moved reusable config handling into new service...
joachim’s picture

I've copied the code into a service for the benefit of the Drush 9 commands. The event subscribers need refactoring to use it too.