Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
Currently the module can only write back configuration on ConfigEvents::SAVE and ConfigEvents::RENAME
and configuration export settings are globally defined in the config_devel settings.
Currently there is no way to write back configuration to a specific modules config install directory without changing the system permissions.
Proposed resolution
Allow the developer to specify the configuration he wants to write back to his module as part of its info file.
Add a drush command that reads the info file and writes back the configuration to the modules config/install directory
$ drush help config-writeback
Write back configuration to module's config/install directory.
List which configuration settings you want to export in the module's info file by listing them under 'config_devel', as shown below:
config_devel:
- entity.view_display.node.article.default
- entity.view_display.node.article.teaser
- field.instance.node.article.body
Examples:
drush config-writeback MODULE_NAME Write back configuration to the specified module, based on .info file.
Arguments:
module Module machine name.
Aliases: cwb
Remaining tasks
none
User interface changes
none
API changes
none
Comment | File | Size | Author |
---|---|---|---|
#34 | interdiff-2300717-27-34.txt | 538 bytes | bircher |
#34 | add_drush_command-2300717-34.patch | 1.38 KB | bircher |
#27 | config_devel-renaming_drush_command-2300717-27.patch | 1.37 KB | Iztok |
#10 | config_devel-drush-config-writeback-command-2300717-10.patch | 3.19 KB | bircher |
#10 | interdiff-2300717-8-10.txt | 836 bytes | bircher |
Comments
Comment #1
ademarco CreditAttribution: ademarco commentedPatch attached.
Comment #2
ademarco CreditAttribution: ademarco commentedComment #3
bircherComment #4
chx CreditAttribution: chx commentedcatch goes on a new line.
Also, it seems to me that there's an excellent opportunity of code reusal here. Say, change autoExportConfig to:
then you could just reuse that method
\Drupal::service('config_devel.writeback_subscriber')->writeBackConfig
. This would fix a bug in the patch which unset uuid unconditionally; it should only be unset for config entities but that is handled neatly in the code (which I have neatly stolen from beejeebus :) )Comment #5
birchercode re-use is a good idea!
Attached is the new patch.
Comment #6
bircherComment #7
chx CreditAttribution: chx commentedNifty. I will commit this later; but I will change the direct info file reading and parsing to
InfoParser::parse
but I can do that myself.Comment #8
bircherNice!
InfoParser::parse
would be used along the lines of the attached patch?There is still plenty of things to learn for me :)
Comment #9
chx CreditAttribution: chx commentedI am learning myself. I think it's
\Drupal::service('info_parser')->parse($filename)
.Comment #10
bircherYou are right!
The drush file becomes cleaner and cleaner.
Comment #11
pescetti CreditAttribution: pescetti commentedWe can avoid hardcoded values by using
system_get_info()
and constants defined inInstallStorage
. New iteration attached.Comment #12
pescetti CreditAttribution: pescetti commentedReordered files so that the patch in #11 is displayed in the table at the top.
Comment #13
chx CreditAttribution: chx commentedErm, nope. system_get_info rebuilds the whole module data. I am not shooting down a whole herd because I want a steak :D but feel free to tell me otherwise.
Comment #14
pescetti CreditAttribution: pescetti commentedRe-rolled patch by removing the improvement that looks too expensive for us (i.e.,
system_get_info()
call) and keeping the other one (constants defined inInstallStorage
). Or is this one too expensive too?Comment #15
chx CreditAttribution: chx commentedOne last question: how do I commit a patch like this; I can only put one of you as --author.
Comment #16
pescetti CreditAttribution: pescetti commentedIt's joint work (we are all colleagues) and you can consider bircher to be the main author for attribution purposes.
Comment #18
chx CreditAttribution: chx commentedSorry for the delay, I wanted to have tests in place first. I committed this as it stands but I can't guarantee this will always work :/ I would recommend some phpunit test that tests writeBackConfig(). https://www.drupal.org/node/2294439 looks useful too.
Comment #19
bircherAttached is the patch for the tests rewritten to use vfsStream.
maybe the path of the filenames could now be simplified, but the tests seem to pass on my system.
lets see what the bot thinks about it.
Comment #20
bircherah it will likely fail since I also included the patch from https://www.drupal.org/node/2315187 which is needed for the module to run at all.
Comment #21
chx CreditAttribution: chx commented+ public function setUp()
+ {
should be
+ public function setUp() {
fixed and committed. We still need that unit test though :)
Comment #23
bircheradded unit tests for writeBackConfig()
Comment #24
chx CreditAttribution: chx commentedThanks so much! That will make sure the drush command can call it happily even as we go forward.
Comment #26
chx CreditAttribution: chx commentedPlease rename the command to config_export_per_info or something. Introducing new words like 'writeback' is confusing. Let's not become features again. Please provide a config_import_per_info which does the same in the opposite direction.
Comment #27
Iztok CreditAttribution: Iztok commentedAttaching the patch that renames the command as discussed on IRC with chx.
Comment #28
chx CreditAttribution: chx commentedI like this but I will wait for bircher's feedback.
Comment #33
bircherHi,
there is no objection for a more descriptive name.
we took writeback because that name was used internally, but that alone is no justification.
Thanks for the better name
Comment #34
bircherI am using the latest drush, so the function should have the suggested name.
Comment #35
chx CreditAttribution: chx commentedThanks for catching that, committed.