Spin-off from #1609760: hook_image_style_*() is not invoked for image styles upon Image module installation and #1670370: Enforce writing of config changes during import, even if the module callback handled it already

Problem

  • Module A (say, Book) can ship with default config that actually pertains to Module B (Node).
  • The current system assumes always-compatible config objects, which is known to be invalid.

Goal

  • Correctly handle API compatibility for configuration in module interdependencies.
  • Allow modules to reject incompatible configuration during installation/import.

Details

  • There happens to be an "export API version" as the base integration part of CTools' Export API, Views API, Panels API, etc.
  • The new configuration system does not have any version identifiers or compatibility checks, albeit almost fully mimicking the basic export/import concepts of Features/CTools in D7 contrib.
  • E.g., admin_views.module can provide default config (views) for views.module, but which are only compatible with views 3.x, and on top of that, they also require VBO 2.x. The views definition is only compatible with Views 3.x and incompatible with Views 2.x. The VBO plugin definition is only compatible with VBO 2.x and incompatible with VBO 1.x.
  • Thus, either all modules are forced to work with any kind of version-agnostic config at any time — which is the current situation and effectively means "backwards-compatibility for eternity."
  • Or we not only need to trust the module API, but we actually need to introduce an additional mechanism/way to allow modules to "reject" config if it is not compatible during any kind of installation/import.

Related issues

Comments

sun’s picture

Title: Configuration system does not accuont for API version compatibility between modules » Configuration system does not account for API version compatibility between modules

bleh

sun’s picture

Component: configuration system » configuration entity system
Category: bug » task
Priority: Normal » Major
Issue tags: +Entity system, +Configurables

Related: #1848998-76: Problems with update_module_enable()

Not sure whether this should be handled by the Entity system or by the Configuration system?

xjm’s picture

Well, I think even plain configuration is likely to depend on the module version, no?

Related: #1842956: [Meta] Implement event listeners to validate imports

mtift’s picture

mtift’s picture

Issue summary: View changes

Updated issue summary.

alexpott’s picture

Version: 8.0.x-dev » 8.1.x-dev
Status: Active » Postponed

It does not like we are going to do anything about this for 8.0.0 so postponing to 8.1.x where we probably have a much better idea about what is possible.

effulgentsia’s picture

Should this issue be closed? Regarding the 2 goals in the IS:

Correctly handle API compatibility for configuration in module interdependencies.

Are module dependencies not sufficient? The IS details gives the example of admin_views wanting to ship default config for Views 3.x and not Views 2.x. Is that not accomplishable with admin_views.info.yml specifying that it depends on Views 3.x?

Allow modules to reject incompatible configuration during installation/import.

Doesn't the configuration dependency system now do this? It didn't when this issue was opened, but it now does, I think.

We have #1977498: Add version tracking for configuration schema and data for other problems related to config schema versioning, so I'm wondering if there's anything about this issue that remains relevant.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

andypost’s picture

Status: Postponed » Active

Looks this could be closed, config version using module updates version

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.