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.

  1. ConfigImporter already reads the list of extensions., just need to expose.
  2. Make Config read the list of extensions for dotless files.

Remaining tasks

  1. 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!).
  2. Possibly refactor the logic in ConfigImporter so that getNewExtensions() reads the extension lists on demand. Consider doing getExtensions($type) where $type is either before or after.
  3. 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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tim.plunkett’s picture

Issue tags: +Needs tests

Nice find. This could use an inline comment and a test.

No comment on the priority/tags, I'll leave that to someone else.

chx’s picture

Issue summary: View changes
Issue tags: -Needs tests
FileSize
5.2 KB
chx’s picture

FileSize
5.51 KB

D'oh that left out the actual config file.

chx’s picture

Issue summary: View changes
chx’s picture

Issue summary: View changes
chx’s picture

Issue summary: View changes

The last submitted patch, 2: 2298445_2.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 3: 2298445_2.patch, failed testing.

chx’s picture

Issue summary: View changes
Status: Needs work » Needs review
FileSize
10.09 KB
chx’s picture

Issue summary: View changes
Issue tags: -beta blocker
alexpott’s picture

It 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.

chx’s picture

Yes, this could be closed down if there would be reporting on which files are not picked up.

xjm’s picture

Title: Configuration named the same as module is not picked up » Report invalid configuration ignored during import
Priority: Critical » Major
Status: Needs review » Active
Issue tags: +Needs issue summary update, +Configuration system

Re-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.

xjm’s picture

Issue tags: +Novice, +TCDrupal 2014

Also this issue summary update should be a straightforward enough task for a novice contributor. :)

alexpott’s picture

Status: Active » Closed (works as designed)

It 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.

exception 'Drupal\Core\Config\ConfigNameException' with message 'Missing namespace in Config object name blah.' in                                                [error]
/Volumes/devdisk/dev/sites/drupal8alt.dev/core/lib/Drupal/Core/Config/ConfigBase.php:98
xjm’s picture

Issue tags: -Novice