Add support for backdrop-config-export (bcex)

[serundeputy]

Determine workflow and write command for backdrop-config-export

This command is also suffering from the namepsace conflicts that en, dis, and si are suffering from. So, for the time being I'm going to move forward with the backdrop-config-export implementation.

[serundeputy]

This approach requires you version control the $config_dirctories['staging'] directory and not the $config_directories['active'].

The workflow is as follows:

• Make config change on your site sitename is an easy use case.
• Save the change.
• execute the command drush bcex
  • This removes the config from the $config_directories['staging'] directory and copies in the config from the $config_directories['active'] directory.
• Since the $config_directories['staging'] is under version control you can see the changes.
• Issue git status; in this example only the system.core.json file should list as changed as it contains the sitename config.
• Add, commit and push your changes.
• Go to your staging server and issue git pull origin master
  • this will bring down the git versioned $config_directories['staging'] changes.
• Visit /admin/config/development/configuration in your browser on your staging site and the UI will pick up the changes that are available for import (the sitename in this case).

---

• TODO: write drush bcim, Add support for backdrop-config-import (bcim) #75, to complete the cli configuration workflow.

Gotchyas

• make sure the config directories are writable by the drush user (usually the user you operate the computer/server as)
• make sure the config directories and files are writable by the webserver user (mac usually _www, ubuntu www-data ... )

---

PR is up at: https://patch-diff.githubusercontent.com/raw/backdrop-contrib/drush/pull/76
Here is the patch link: https://patch-diff.githubusercontent.com/raw/backdrop-contrib/drush/pull/76.patch

@jenlampton @wesruv up for a review?

[herbdool]

@serundeputy I gave it a spin. Simple enough and works.

One change I'd suggest, because it was unexpected, is to only copy the files in /active and not the directory itself. The command dumps the files so it looks like: ./config/staging/active/

[serundeputy]

thanks @herbdool

Oh; sorry about that structure; I don't think I can copy just the files since we need deletions too. For example if one deletes a content type that will delete the corresponding config file in active, but if we just copy the files that deletion doesn't exist (it was deleted) in active. So copying just the files will copy the existing files from active to staging and overwrite the ones that were there, but the deletions don't exist and just leaves the old config file in staging.

So, correct me if I'm wrong, think we need to move the entire active directory (deletions too), but I will look into reproducing that sub directory behaviour (./config/staging/active) I don't recall that happening to me, but we should make sure it just goes to ./config/staging.

My ultimate plan is to take a backup of of the staging dir and put it somewhere in ~/.drush then move in the export of active to ./config/staging does that make sense?

thanks again for testing!

[herbdool]

thanks @serundeputy

I had assumed the script was deleting the files in staging first, no? Wouldn't that ensure removed config stays removed?

[serundeputy]

bcex merged into 1.x-0.x released in 0.0.4.
#88

[herbdool]

@serundeputy thanks for your work on this.

How much work is it to add a flag so the user can specify what directory to export to? I think that could be quite useful for people using a different workflow. I saw it in the Drupal version of the command.

[serundeputy]

I think I can get that going.

• Add --destination=path/to/export option

[serundeputy]

Added --destination option in 1d24fe1

@herbdool give it a whirl at your leisure :)