Add a meta-data API

Updated: Comment #N

Problem/Motivation

From #731724: Convert comment settings into a field to make them work with CMI and non-node entities

Disregarding the concrete use-case: Architecturally, this concept is badly needed in Drupal.

This concrete sample implementation will be copied + resembled by 1,000+ contributed and custom modules.

All major concerns and objections that have been raised are 100% valid. It would be a huge mistake to ignore them.

Some of the concerns are about fundamental concepts (content vs. configuration-ish meta data).

The current/previous implementation is only acceptable, because the meta data is, in fact, not part of the actual content entity that is being processed in various ways. Instead, the additional meta data is pulled in and used where needed and where appropriate only.

The proposed change turns the formerly separate meta data into data of the content itself — implicitly participating in all possible content entity interactions, even though the data is not content.

We're seeing this anti-pattern and inappropriate (ab)use of architecture in plenty of contributed modules already.

A prime example might be the Media module (adding internal meta data fields to all entity types/bundles that it is operating with). That inappropriate usage is the topmost reason for why a proper architectural solution in Drupal core is required.

Ultimately, the conflict stems from the fact that we happen to have an architecture in core that happens to fully resolve the needs of affected modules.

From a technical standpoint, it delivers a 99% solution. But from a conceptual and business logic perspective, the solution is 100% incompatible and inappropriate to use.

Business logic matters.

The good news: All of the code exists already. Including tests.

Consequently, what you want to do is this:

$ cp -R core/modules/field core/modules/metadata
$ find core/modules/metadata -type f -exec sed -i "s/field_/metadata_/g;s/Field/Metadata/g" '{}' ';'
In words: Literally copy the whole shebang. Apparently, it solves plenty of hard problems for contrib. You have the solution right in your hands, you can provide it.

You want to diverge from the Field API mainline, because of the very valid concerns that have been raised with regard to differences in business logic. These fields != fields, but yet, == fields.

You can further consider to simplify the Meta Data API afterwards; e.g., by restricting storage to SQL (debatable; separate discussion), and/or possibly removing any other complexities of Field API that are irrelevant (e.g., multiple values).

Regardless of these major conceptual and architectural concerns, I do support this change. It is required, and it attacks one of the most critical bottlenecks in Drupal's architecture.

Unless core provides a proper solution, the world will continue to abuse existing APIs in utterly inappropriate ways, further disrupting a clear and common understanding of what exactly "content" constitutes.

Drupal has to have a solid architectural concept for this data. Core consumers badly need a solution, yesterday.

Proposed resolution

$ cp -R core/modules/field core/modules/metadata
$ find core/modules/metadata -type f -exec sed -i "s/field_/metadata_/g;s/Field/Metadata/g" '{}' ';'

Remaining tasks

Talk this through
Discuss
Etc
Fix stuff the automated generation didn't fix
Make it the first commit to Drupal 9?
Refactor comment form a field to this.

User interface changes

None

API changes

A whole new metadata sub-system that resembles the FieldAPI but can't be configured from the UI.

Related Issues

Follow-up from #731724: Convert comment settings into a field to make them work with CMI and non-node entities.