Important related issues

Problem

  • Executing config_install_default_config('profile', 'standard') imports default configuration objects in no particular order.
  • This means that e.g. filter.format.X is imported before user.role.Y — the user role IDs specified in the filter format config do not exist (yet).

Goal

  • Respect at least a basic/minimum order of module dependencies in the config import process.

Proposed solution

  1. Introduce a ModuleHandler::getModuleListByDependencies() (or similar).
  2. Change config_sync_get_changes() to sort the three lists of created, changed, deleted config objects by the ordered module list.
CommentFileSizeAuthor
#4 1918926-screenshot.png56.27 KBmtift
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tim.plunkett’s picture

Issue tags: +Needs tests

If this is truly a major bug, why is nothing breaking?

sun’s picture

Things will start to break when the most important Configurables are finally converted; e.g., node types, fields, comment node type settings, etc.

This issue is borderline critical. The only reason for why the concrete problem outlined in the OP about filter formats currently works is pure coincidence.

tayzlor’s picture

Some of these issues are surfacing in #1808248: Add a separate module install/uninstall step to the config import process. A specific example of this can be recreated by trying to do a config import of the standard profiles YAML files over the top of a minimal installation.

One example of this is -
The minimal profile does not ship with a 'administrator' role, but standard does.

the config export from standard includes the following files -

action.action.user_remove_role_action.administrator.yml
action.action.user_add_role_action.administrator.yml
user.role.administrator.yml

The config will also be imported in the above order. When we come to import the administrator role, an insert hook is fired on role creation - user_user_role_insert(), which goes and again creates the 2 actions (which have already just been imported).

Additionally, after the full config import has run, action.action.user_remove_role_action.administrator and action.action.user_add_role_action.administrator still show up on the config import UI as having changes that need to be synced, because the UUIDs still differ between the staging and active directories.

mtift’s picture

FileSize
56.27 KB

When I try to import standard profiles YAML files over the top of a minimal installation, I get the following error message: "Drupal\Component\Plugin\Exception\PluginException: The plugin (comment_publish_action) did not specify an instance class. in Drupal\Component\Plugin\Factory\DefaultFactory::getPluginClass() (line 62 of /Users/mtift/Sites/d83/core/lib/Drupal/Component/Plugin/Factory/DefaultFactory.php)"

1918926-screenshot.png

tim.plunkett’s picture

That's not a supported operation though, you could never reuse parts of an install profile over another installation.

Now that we require full config imports, isn't this won't fix? Because the full config would have the modules required.

mtift’s picture

This this issue is about module dependencies, I posted a follow-up comment regarding install profiles in #2029771-1: Having installation profiles in system.module.yml causes config import to fail

It would seem that the OP regarding order of module dependencies is still up for debate, and that we need a better alternative to importing alphabetically. Or is this issue solved by full config imports?

Related: #1944368: React to / force order of imports

mtift’s picture

Issue summary: View changes

Add related issue

alexpott’s picture

Issue summary: View changes
Status: Active » Closed (duplicate)