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

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented
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

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented
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

xjm
she/her
Primary language English
CreditAttribution: xjm commented

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
he/him
Primary language English
Location Minnesota, USA
CreditAttribution: mtift commented

Two very similar issues:

#1398040: Detect if default configuration of a module has been changed, and allow to restore to the original

mtift’s picture

mtift
he/him
Primary language English
Location Minnesota, USA
CreditAttribution: mtift commented
Issue summary: View changes

Updated issue summary.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented
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

effulgentsia CreditAttribution: effulgentsia at Acquia commented

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

andypost
he/him
Primary language Russian
CreditAttribution: andypost as a volunteer and at Skilld commented
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.

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

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.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.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.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.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.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.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.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.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.