The config system hardcodes a number of required "config system housekeeping" properties in ConfigEntities and their YAML representation - id, uuid, language, dependencies, status, maybe soon third_party_settings...

But since those "system" properties live in the same namespace than the set of "domain" properties of each ConfigEntity type, there's always a risk of name clashes. As long as D8 is in developpement, the config system simply claims some property names, and contrib ConfigEntities need to adapt by not using a domain property with the same name.

Once 8.0 is out, though, it will be very hard to add/rename "system" properties in ConfigEntityBase if the need arises in 8.1 or even in 9, because there is no way to be sure that this new property will not clash with an existing "domain" property in some config entity type somewhere. De facto, we're locked.

The fact that we are still adjusting some of those "system" properties at this point in the cycle (rename some, add others...) - because, well, CMI is complex and takes a long time to be done right - is IMO a clear sign that we can't really say for sure we won't need to adjust more stuff later on.

I feel stupid for not spotting that earlier :-/, since this is exactly the reason why Field API separates "Field API system" properties ($field->label, $field->required) and "field-type specific" settings ($field->settings['foo']) - so we can add new top level "system" properties at any point without fearing that some contrib / custom field type somewhere might have a "domain" setting with the same name.

Ideally, ConfigEntities should have separate spaces for "system" and "domain" properties - something like "header" & "payload", in a way...

Comments

yched’s picture

yched commented

Leaving the priority/criticalness up for discussion :-)

In a way, this could be seen as just an instance of the much more general "yeah, adding new properties in any class that's intended to be a base class, can be problematic for BC, because you don't know what properties exist in child classes". Which would probably make this issue a "that's life, won't fix".

The specific thing about ConfigEntityBase is that it's the ubiquitous container for 95% of our yaml config records...

yched’s picture

yched commented
Issue summary: View changes
alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
commented

Discussed this with @catch in IRC when I first read the comment in the other issue.

I think we could document that any root properties starting with _ are reserved for API additions in the 8.x cycle. When we add one of these we should automatically deprecate for 9.x and create an issue to remove the _ against 9.x

So I think we should do a documented version of

that's life, won't fix

yched’s picture

yched commented

Not nice, but yeah, that's probably our best option for the D8 cycle at this point.
Hopefully in D9 we can move to a clustered approach (putting system properties in a separate top-level entries or something).

So, actianable steps here would be - what ? Add some doc about "don't define properties starting with _" in ConfigEntityBase ?

fabianx’s picture

fabianx commented
Priority: Normal » Major

I still like my proposal to use actual namespaces, like:

drupal.core.uuid instead as I cannot see the difference to class namespaces ...

drupal.yourmodule.yourproperty: 42

etc.

xjm’s picture

xjm
she/her
Primary language English
commented
Version: 8.0.x-dev » 9.x-dev
Category: Bug report » Task
Status: Active » Postponed
Issue tags: +Needs followup

Discussed with @alexpott this morning. This is unfortunately far too disruptive for 8.0.x at this point for an edgecase problem. We can document the workaround with the underscore explained in #3. There's also no way to sanely fix this with BC, so postponing to 9.x.

Tagging for a followup for the docs.

catch’s picture

catch
he/him
Primary language English
commented
Version: 9.x-dev » 8.1.x-dev

I think we could add an ugly bc layer for this in a late minor release of 8.x - that would allow for forward compatibility of default config YAML between versions if it was using the new property names. Moving back to 8.1.x for now.

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.

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.

smustgrave’s picture

smustgrave commented
Status: Postponed » Postponed (maintainer needs more info)
Issue tags: +stale-issue-cleanup

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

smustgrave’s picture

smustgrave commented

Wanted to bump this 1 more time before closing.

geek-merlin’s picture

geek-merlin
Primary language German
Location Freiburg, Germany
commented
Title: No namespacing of "system" properties in ConfigEntities / yaml files means lockdown after 8.0 is out » No namespacing of "system" config types
Component: configuration entity system » configuration system
Status: Postponed (maintainer needs more info) » Active

Yes, i still see this as a valid issue with no solution.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.