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.First of all, thank you for this module. This really got me out of a bind where I wanted to save a node ID in a config form but didn't want that value put into version control.
I got the module to do what I needed, but I was/still am confused as to what exactly the differences between greylisting and blacklisting. Also, it seems that not entering a path for the split "Folder" causes the configuration to simply not be exported, which is what I wanted, but was confused that I needed to leave a field blank to accomplish it. I thought adding something to the config blacklist would do this. I'll create a patch and would love to help out more on this module, but I feel as though I shouldn't be the one to write the form field help text since I'm don't understand how it works. So if someone could provide me with the help text and/or code changes to make the form more usable, I can put a patch together.
Thanks!
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | config_split-2822974-document_admin_form-4.patch | 7.69 KB | nerdstein |
| |||
Comments
Comment #2
nerdsteinI second that clarity as to blacklist/graylist functionality would be useful on the module homepage
Comment #3
nerdsteinI think it would also be useful to document the specific behaviors that happen during import/export with respect to black and gray lists.
Comment #4
nerdsteinWould there be any consideration to renaming this to be more relevant to the actual behaviors?
The "blacklist" could be "Included Configuration" and the "graylist" could be "Excluded Config" with an explanation of this behavior for the config target directory.
We could cleanup the user interface some as well.
I've made a stab in the patch below. Feedback completely welcomed.
Please consider merging this issue first: https://www.drupal.org/node/2863849#comment-12005374
Comment #5
ChrisSnyderI really like these changes to the graylist and blacklist descriptions!
Comment #6
bircherThank you very much for your contribution.
I don't think included and excluded is a much better description. First because it depends on the perspective and second because the blacklist and graylist do not do oposite things (otherwise I would have called it whitelist).
What happens is that when a listed configuration is not already part of the sync directory both black and gray lists have the exact same effect both for exporting and importing.
However, if the configuration is already part of the sync directory then when exporting the blacklist will remove it from the sync directory and save it in the split folder only while the graylist leaves the original config in the sync directory and writes an updated copy in the split folder.
I will include the fieldset option and put the text above in the form and in the readme.
A better name for graylist is still very much welcome.
Comment #8
bircherPlease check out the commit mentioned above (or the dev version) and give feedback on whether the form has improved or suggest further improvements via a patch.
Comment #9
adamzimmermann CreditAttribution: adamzimmermann at Chromatic commentedThe update field descriptions are great. I think I fully understand blacklist vs greylist now!
What about this terminology?
Greylist: Branched Configuration
Alludes to still being connected to synced configuration and uses git terminology (for those familiar with git).
Blacklist: Split Configuration
Alludes to the module name and indicates a clean split/separation from synced configuration
It's hard to fine terms to describe the difference succinctly. The important thing is that there is a good description below each field, which I think we now have.
Comment #10
bircherThanks!
I like split and branched configuration. Other suggestions are still welcome too of course.
See also #2865280: Find a better name for Graylist.
Then we need to update the project page, readme, documentation on d.o the hook_help. And then release 1.0.0 and party!
Comment #11
eelkeblokIt's a bit strange reviewing a change already in Git, but I think the description is much clearer. Had I seen this the first time I encountered the gray list, I don't think I would have had as much trouble wrapping my head around it. RTBC seems like a good idea :)
Comment #12
bircherHaha yes reviewing an issue that is already committed is quite rare.
But I thought it was already a good improvement as such and we were already using it, so I might as well commit it.
Thanks for the positive feedback.