Voting starts in March for the Drupal Association Board election.
Right now, with two field info systems: The one for entity fields maintained by the EntityManager and the one for configurable fields (FieldInfo).
Almost everything in FieldInfo now has corresponding methods in the entity manager, with the exception of the field map.
Additionally, there are a lot of calls left to the old functions/methods that need to be updated.
The patch does a number of different things
- Add a new getFIeldMap() method to the EntityManager to replace FieldInfo::getFieldMap(). The new field map has the same structure but also contains non-configurable fields. That makes it slower to build as we need to loop over all content entity types and their bundles and collect the field definitions of those. @todo: Profile cpu/memory usage, try to optimize and open a follow-up to add locking if necessary.
- Most remaining usages of field info functions can be classified into two groups. The first use them to directly interact with specific configurable fields, like the helper methods that add default body fields, tests and so on. For those, the patch adds FieldConfig::loadByName($entity_type, $field_name) (replaces field_info_field()) and FieldInstanceConfig::loadByName($entity_type, $bundle, $field_name) (replaced field_info_instance()) that directly load the entity. Two special cases (in FieldInstanceConfig::__construct() and Tables.php) need to load deleted fields, there we need to go through loadByProperties() as those fields don't really exist anymore and can only be loaded with that strange API. This is an existing problem that used to be internal to FieldInfo and now becomes a bit more visible. But only very few places need that.
- Most other usages can be replaced with getFieldDefinitions()/getFieldStorageDefinitions() on the entity manager. This also involves replacing the injected field info service with the entity manager if not already present.
How that is done exactly often looks a bit different, a few notable special cases:
- Entity Query Tables.php: This has a lot of hacks that go back to times when we didn't have the API's that we have now, so a lot of code that be simplified there. This patch does as much as necessary, further improvements are certainly possible but go beyond what we need to do achieve the goals of this issue.
- In ContentEntityDatabaseStorage, we still need to check for configurable field objects as those methods only care about those, will address that further.
- comment_entity_bundle_info() can not call getFieldMap() on the entity manager as that results in a loop. This means that for the time being, comments will only support configurable fields, this is not a regression as this is already the case in HEAD, *might* address this.
- In field_entity_bundle_field_info() we now use an entity query to load all matching field instances
- The content entity migration destination has also been simplified a bit for the entity bundle handling and as a side effect, the (currently unused field-type specific handling) would now also work for base fields.
- The same is true for the Term autocomplete controller, it is now possible to define a term reference field as a base field in your entity type and use the autocomplete widget for it.
1. Get reviews.
2. Implement reviews (including existing reviews from @fago and @yched)
3. Some non-beta blocking follow-ups need to be opened as mentioned above.
4. Profile the new getFieldMap() implementation on a site with a large number of bundles and fields.
User interface changes
FieldInfo::getFieldMap() -> EntityManager::getFieldMap()
field_info_field() -> FieldConfig::loadByName() (only for cases where the code is explicitly working with configurable fields, see node_add_body_field() as an example)
field_info_instance() -> FieldInstanceConfig::loadByName() (same as above)
Everything else is just converting to existing API's. Only exception are changed constructor arguments for things like entity storage implementations, in case subclasses extend those, they would need to be updated (like user and comment in core), but so far, we never made change records for such changes AFAIK.
Original report by @fago
Right now, with two field info systems: The one for entity fields maintained by the EntityManager and the one for configurable fields. Ideally, we've only one and avoid duplicated field definitions in memory for the same thing (as we have it now).
As discussed in Prague the plan is to move all over to an entity field definition service (wherever that will resides). However, for that being possible we need to complete the following issues first:
Once we've that issue fixed, I think we've finally managed to unify both field APIs nicely.
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 71,187 pass(es). View
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 71,225 pass(es). View