Voting starts in March for the Drupal Association Board election.
The Content Translation module implements most of its business logic based on translation metadata such as the source language, the translation publication status, the translation authoring information and so on. Currently these metadata items are stored in a table holding values for any entity type and they are not exposed through regular field definitions.
This has several drawbacks:
- Metadata storage is not swappable, as SQL storage is hard-coded.
- Metadata items do not have access to all the benefits of being fields, such as automatic REST or Rules integration.
- Some information is duplicated because there's currently no way to have entity-type-specific customizations.
- The current implementation is deprecated and is an example of how things should NOT be done in Drupal 8.
Introduce a wrapper class dealing with metadata and use the Content Translation handler to expose field definitions for each metadata item. This entity translation wrapper provides methods to access the various metadata values. This integrates pretty well with our regular entity-type-specific interfaces and could even serve as a pattern for modules adding new base fields. This approach allows to provide an alternative set of field definitions for each entity type and retrieve field values accordingly or even implement more complex logic on top of those. For instance node translation metadata is mapped this way:
- Translation source -> New node base (translatable) field
- Translation outdated status -> New node base (translatable) field
- Translation published status -> Node published status (translatable field)
- Translation author -> Node author (translatable field)
- Translation creation time -> Node creation time (translatable field)
- Translation modification time -> Node modification time (translatable field)
The current custom storage is replaced by our regular entity storage.
User interface changes
Like we already do for nodes, widgets for the translation name, status and created on the comment form were hidden, as the native ones are used.
Data access for metadata items has changed from a custom entity property to regular field access. Actual access is performed by the translation metadata wrapper.
Beta phase evaluation
|Issue category||Task because the functionality already exists and is not broken, although implemented through D7-style code.|
|Issue priority||Major because this provides the first actual usage in core of new the Entity Storage Update API. Not critical because we could release Drupal 8 with the current code without introducing functional problems.|
|Prioritized changes||The main goal of this issue is reducing fragility by providing the first core implementation of a new core API and serving as an example for contrib module authors. This was specifically approved by a branch maintainer in #98.|
|Disruption||Disruptive for contributed and custom modules doing very specific things with content translation metadata, which should be a fairly small number.|
|#152||interdiff.txt||3.45 KB||Gábor Hojtsy|
|#152||ct-metadata_fields-1916790-152.patch||77.74 KB||Gábor Hojtsy|
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 84,526 pass(es). View
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 84,461 pass(es). View
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch ct-metadata_fields-1916790-146.patch. Unable to apply patch. See the log in the details link for more information. View