Should be usable via Drush.

Proposed resolution

Draft commands:

 * Implements hook_drush_command().
function config_sync_drush_command() {
  $items = array();

  $items['config-sync-list-updates'] = array(
    'description' => 'Display a list of all extensions with available configuration updates. If an extension name is provided as an argument, then all of the configuration updates for that extension will be listed.',
    'examples' => array(
      "drush config-sync-list-updates" => 'Display a list of all extensions with available configuration updates.',
      "drush config-sync-list-updates 'example'" => "Display a list of all configuration updates available for the 'example' extension.",
    'arguments' => array(
      'extension' => 'The extension to list. Optional; if specified, lists all configuration updates available for the extension. If no extension is specified, lists all of the extensions with available updates.',
    'outputformat' => array(
      'default' => 'table',
      'pipe-format' => 'list',
      'field-labels' => array(
        'machine_name' => 'Machine name',
        'name' => 'Name',
        'object' => 'Configuration object',
      'output-data-type' => 'format-table',
    'aliases' => array('cs-list'),

  $items['config-sync-update'] = array(
    'description' => 'Apply configuration updates. If a comma-separated list of extension names is passed as an argument, only those extensions will be updated.',
    'examples' => array(
      "drush config-sync-update" => 'Apply updates to all extensions.',
      "drush config-sync-update 'example_one,example_two'" => "Update the example_one and example_two extensions.",
      "drush config-sync-update --unsafe" => "Generate all available extensions and add them to an install profile.",
    'arguments' => array(
      'extensions' => 'Comma-separated list of names of the extensions to be updated.',
    'options' => array(
      'unsafe' => 'Apply updates considered to be unsafe. These are updates that could overwrite customizations on the site.',
    'aliases' => array('cs-update'),

  return $items;

Remaining tasks

User interface changes

API changes



flocondetoile’s picture

Version: » 8.x-1.x-dev
Status: Active » Needs review
6.14 KB


Attached a patch which add support for Drush. Adding this support permit me to find some little bugs for unsafe configuration changes. See #2703277: Unsafe configuration never listed and/or updated
Thanks for your review

nedjo’s picture

Looks great, thanks!

I'm trying to find time for major refactoring in #2615146: Analyze diffs to do safe synchronization of customized configuration and #2678946: Repurpose core's config synchronization, so I'm slightly unsure of how that would affect these commands, but I'm comfortable meantime adding these.

james.williams’s picture

6.16 KB

The previous patch didn't apply well -- here's a fixed version that creates the drush file afresh.

nedjo’s picture

Status: Needs review » Needs work

Didn't get this applied before major refactoring in #2793027: Refactor to use Configuration Provider and #2678946: Repurpose core's config synchronization. Will now need to be reworked to use new approaches

james.williams’s picture

Exciting stuff, thanks for doing that work! Is there any other related work likely to come in the next few days/weeks that is worth holding out for first? I wouldn't want to go through refactoring this twice within a short space of time.

Just to document it somewhere too whilst I'm here, since my last patch, I've also been thinking that it would be good to have an option to the drush command like --module-dir, to allow 'reverting' all modules within/below a certain directory (e.g. within an install profile's modules/custom directory, which is my use case), to replace what we used to do with 'drush fra'.

nedjo’s picture

Is there any other related work likely to come in the next few days/weeks that is worth holding out for first?

I think the major refactoring is done.

I've also been thinking that it would be good to have an option to the drush command like --module-dir, to allow 'reverting' all modules within/below a certain directory

Two relevant changes in the recent refactoring.

First, I've removed the code that was specific to a particular extension. Instead, all changes from all extensionns are merged all at once.

The main reason for this change is dependency handling. Often, particularly with features, a given module's configuration may depend on that provided by other modules, so updates are best done as a set.

Also, for directories other than config/install, changes in a particular module may trigger changes in other modules. For example, configuration provided by Module A may satisfy config dependencies of Module B's config/optional items, meaning, again, that updates are best done as a set.

Second, this module can no longer be used for reverting in the sense we used the term in D7. Instead, all changes are merged into the active configuration, retaining any overrides that have been made.

The initial Drush work seems to be two commands, one to initialize the merged configuration storage and one to run imports. Because we're reusing core's config sync importing, the second should be very similar to what's already in drush config-import.

james.williams’s picture

Ah. Ok - thanks for the update. Unfortunately I was using config_sync for the very use case of 'reverting' individual modules, or groups of modules. I do understand that dependencies can be an issue with that kind of workflow, but we're working to keep on top of those to ensure our config declares its dependencies appropriately. At least in our workflow with config_sync before the refactor, dependencies were recognised & processed, so issues could be avoided if they were at least declared accurately enough. So I'll look at what options we have for our intended workflow - it's likely that our focus will shift to other projects since you have a clear intention for config_sync now, that looks great, but just doesn't match what we were trying to achieve.

nedjo’s picture

@james.williams: I think it's worth at least exploring if/how config_sync could continue to meet your use case. I've just posted two issues to try to capture at least most of what would be needed:

I'm definitely open to doing this and at first glance it doesn't look prohibitively difficult. Could you look over the two issues and see if they capture what you'd need?

james.williams’s picture

@nedjo thanks for your understanding. In reality, I'm waiting to see where #2388833: Pull reusable routines out of configuration import/export form builders (core) and #2388253: Pull reusable config handling into new service (config_devel) end up going, as it looks to me as those will direct any workflow I'm aiming to use. Nothing against your module(s) or the direction they're heading, they just don't quite fit and I'd rather stay closer to core + config_devel (since that's virtually core for most of us, I expect!) where possible.

So for now, rather than adjust to using config_provider/config_sync, which never quite fit our usage/intention correctly anyway, I've rolled my own drush command to cover the 'features revert' / 'revert all' style workflow that we used to use: - this also incorporates ideas taken from elsewhere like and leverages common functionality in config_update too.

Sorry to not take this any further!

nedjo’s picture

@james.williams: thanks for the update. Even if it doesn't end up meeting your own requirements, this conversation's been a useful spur to improvements here in config_sync, so it's all good.

james.williams’s picture

yay :-)

I'll certainly continue to keep an eye on developments in config_sync!