Problem/Motivation

I suspect this is a drush request rather than a CS request; but don't know drush code too well; are other modules able to hook into drush commands?

I think when i do drush cex; some files re created in sync and some are created in other folders based on config splits? But the pre-execute message that is spit out doesn't say what is going where. Is it just me that thinks that would be super helpful?

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Comments

liquidcms created an issue. See original summary.

liquidcms’s picture

liquidcms commented

After thinking about this i am guessing it isn't possible to override/hook into existing drush commands; and CS likely just needs to have it's own cex command.

Another issue i see with existing cex command is that, too my surprise and delight, i see that if i select a module in the Complete section of split; what i thought it was doing was simply including all the configs associated with that module; but it also enables that module for that environment and then removes it from the global "enabled modules" config: core.extensions.

After doing this and then doing a cex, it lists the only config file to be written as the config.split for that environment; but although it will also write out the new core.ext config into global sync folder; that is not listed as being written (of course when i go to commit the file; i see it has been changed).

liquidcms’s picture

liquidcms commented
Title: cex should specify where config files are going. » Need to have a "split aware" version of drush cex.
bircher’s picture

bircher
Location 🇨🇿
commented
Title: Need to have a "split aware" version of drush cex. » Add drush command to see the status of a split.

Yes modules can hook into drush command invocations in several places.
Notably before or after the method of the drush command is invoked.
So we could add some message before the normal drush config-export.
Note though that the output of the drush command depends on the arguments and options that are passed to it, so we would have to check those and update our code when drush does.
In addition it is worth of note that the core drush command will print what goes in the sync directory.
So maybe instead of hooking into the drush command and force all users of config split to get that message, we could add a new drush command that lists what is different in all active splits. Then those who want to know can run this drush command and we can use the same code also in the config-split:export command to emulate the core export including adding a diff preview etc.

liquidcms’s picture

liquidcms commented

sure, i have no issue with a separate drush command (I think that was my original or 2nd title). Not sure anyone specifically doesnt want to know that changes they just made aren't going to be exported to sync when they thought they were; but if separate command for showing both what is going to sync and what is going elsewhere is good... as long as not 2 commands... one to go to sync and one to go to local.

I guess hand in hand with this might be a the ability to force as if you were in a different environment; but that might be dangerous... as you really should swith to that environment, import for that environment first.. before exporting.

but if hooking is allowed; not sure why modification of this table:

$ vendor/bin/drush @sia8 cex
 [notice] Differences of the active config to the export directory:
+------------+---------------------------------+-----------+
| Collection  | Config                                  | Operation |
+------------+---------------------------------+-----------+
|                 | message.template.poi_sia        | Update    |
|                 | views.view.certificate_requests | Update    |
|                 | views.view.policies_by_user     | Update    |
+------------+---------------------------------+-----------+

to simply add another column, wouldnt be the easiest and more clear way to go.

bircher’s picture

bircher
Location 🇨🇿
commented

Well, the drush command with drush 10 and config_split 2.x or with config_filter 2.x only shows what goes in the sync directory. So if you made a change to a config which is going to a split then you wouldn't see that in the normal drush command.
And about the hook, I don't know if we can edit the table. we can print stuff before it for sure and maybe after it.

But in any case I would rather have our own.
We are going to have a command to enable and disable splits too and they could also display a diff with a similar table etc.

And if you want the split to be included in the normal drush command (under the collection column) then you can just switch to using the collection storage which will be added in #3167216: Allow split in collection

pfructuoso’s picture

pfructuoso commented

This suggestion from @niteman can be useful here

drush ev 'foreach (\Drupal::configFactory()->listAll("config_split.config_split") as $name) { print_r($name . ": " . \Drupal::configFactory()->get($name)->get("status") . "\n");};'