Problem/Motivation
In Drupal 7, many modules did variable_get($module_name, array());
and went from there.
In Drupal 8 it is not possible to have a config file without a dot in its name. This is arguably a regression considering above. And, it is silently ignored so you have no clue why it's not getting picked up.
Proposed resolution
Make it possible to have a config object named the same as an extension. AFAIK the only requirement towards a config object is that explode('.', $name)[0]
is the module/theme name but that is kept.
To facilitate this, validateName
needs to get the list of extensions so that it can validate dotless names for this.
ConfigImporter
already reads the list of extensions., just need to expose.- Make
Config
read the list of extensions for dotless files.
Remaining tasks
- Remove delete from
onConfigImporterValidate()
. There's no point in having such because it couldn't have gotten in without first being valid. Now, with the new system if you uninstall a module with the same name config then that will fail (tricky!). - Possibly refactor the logic in
ConfigImporter
so thatgetNewExtensions()
reads the extension lists on demand. Consider doinggetExtensions($type)
where$type
is eitherbefore
orafter
. - Bump this to beta blocker. Anyone porting a contrib which used this variable convention in D7 will have a bad time.
User interface changes
Nothing.
API changes
$module.yml
becomes possible.
Comment | File | Size | Author |
---|---|---|---|
#9 | 2298445_9.patch | 10.09 KB | chx |
Comments
Comment #1
tim.plunkettNice find. This could use an inline comment and a test.
No comment on the priority/tags, I'll leave that to someone else.
Comment #2
chx CreditAttribution: chx commentedComment #3
chx CreditAttribution: chx commentedD'oh that left out the actual config file.
Comment #4
chx CreditAttribution: chx commentedComment #5
chx CreditAttribution: chx commentedComment #6
chx CreditAttribution: chx commentedComment #9
chx CreditAttribution: chx commentedComment #10
chx CreditAttribution: chx commentedComment #11
alexpottIt was a design decision to not support config file names with no dots. This is so that the configuration object says something about what is contained within. Hence core has a lot of MODULE_NAME.settings.yml.
At this point I'm pretty ambivalent to this patch - I can see the wtf but on the other hand enforcing the dot means that the moment the module has to have more than one config file it makes it obvious what it was for.
The real issue here is the lack of error reporting when a configuration file is not imported.
Comment #12
chx CreditAttribution: chx commentedYes, this could be closed down if there would be reporting on which files are not picked up.
Comment #13
xjmRe-titling, downgrading, tagging. I agree that it could make sense to report that files are being ignored, though I don't think it's critical. We should also ensure that the configuration system handbook documentation makes the naming requirements clear.
Needs an issue summary update for the new issue scope.
Comment #14
xjmAlso this issue summary update should be a straightforward enough task for a novice contributor. :)
Comment #15
alexpottIt is not possible to create and save a config object without a dot. Injecting the list of modules into Config and validating against that seems overkill. I don't think this is even a major issue and in fact the system is working as design. Config::validateName() works as expected.
The IS is correct that validating the names of the config that is going to be deleted is kinda pointless. We should open a separate issue for that.
\Drupal::configFactory()->getEditable('blah')->save();
fails. nuff said.Comment #16
xjm