Provide a way to handle simple objects in Configuration System [#1782424]

Problem/Motivation

There are some Drupal objects, like languages, text formats, contact categories, that should be converted into the new Configuration System.

At this moment, the approach is use the entity system to handle those configurations. However, things like languages shouldn't use entity as base system due entities require a language. Also, text formats are not related to languages and they don't have revisions support, and the same applies for contact categories.

This type of configurations share some characteristics.

In Drupal 7, they are stored in a single table. Or at least in two tables.
This objects are not fieldable.
This objects are usually required in by other components but doesn't have other dependencies than modules.
It is the same object for all the languages. Different languages of the site share the same configuration object.

Proposed resolution

Discuss. Find one.

Remaining tasks

After agree in a solution, implement:

#1754246: Languages should be configuration entities
#1588422: Convert contact categories to configuration system
#1779026: Convert Text Formats to Configuration System

Comments

Comment #1

tim.plunkett

he/him

English

Philadelphia

CreditAttribution: tim.plunkett commented 12 September 2012 at 15:55

This comes back to my original idea of moving the following out of EntityInterface:

language()
translations()
getRevisionId()
isDefaultRevision()

ConfigEntity objects don't need those things.

Comment #2

Jose Reyero CreditAttribution: Jose Reyero commented 12 September 2012 at 16:14

Then my thoughts about the ideas here #1 and on the original (Language) thread:

- It sounds like we are talking about redefining entities and that can put half of Drupal (that relies on things being entities and entities having some properties) upside down.
- Wouldn't it be easier creating a lower level class that entity extends and keep entities as they are? It is just a question of naming, only (though I've seen in the past purely naming issues causing tsunamis of comments here :-( )

Example (hypothetical):
1. We take language out of Entity
2. Then generic entities are not translatable anymore (just some kind of entities)
3. Then what...?

Comment #3

sun

German

Karlsruhe

CreditAttribution: sun commented 12 September 2012 at 16:45

The entity system is that low-level data management system already. Our main problem is that it is being misunderstood as a "content" entity system. However, it was architecturally designed to handle just entities of whatever kind.

My main objection to removing language() and translations() is that it would be very wrong to remove them per se:
#1782472-3: Hard-coded and enforced language support for entities conflicts with Language as a ConfigEntity

Likewise, revision support is perfectly possible, too. (e.g., via GitStorage)

The actual and only problem we're facing in #1754246: Languages should be configuration entities is that the entity system currently relies on the module system to provide the entity type information. It's very important to distill the actual problem. Because that means we can easily work around it by simply not using the Language entity type in early bootstrap situations, but only for the administrative management of languages. Anywhere else, we very simply resort to the raw config data.

Comment #4

Jose Reyero CreditAttribution: Jose Reyero commented 12 September 2012 at 17:13

@sun, quote summary.

The entity system ... was architecturally designed to handle just entities of whatever kind.

Really, it sounds to me like we either rethink the whole entity / fields / properties / etc thing or we simply not use entities for this config storage.