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

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

Issue summary: View changes
alexpott’s picture

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

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

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

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

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.