[meta] Complete Entity Field API

Added another nice to have.

Updated issue summary.

Updated issue summary.

Updated issue summary.

Updated issue summary.

Updated issue summary.

Added #2132145: Rename 'typed_data' / Drupal::typedData() to 'typed_data_manager' / Drupal::typedDataManager

bleh, added link in wrong "summary" :/

Added #2134887: move field_view_field() / field_view_value() to methods Assigned to: zwischenzug

Added #2142549: Support multi-column field types in base tables

Added #2143291: Clarify handling of field translatability

Added #2143263: Remove "Field" prefix from FieldDefinitionInterface methods

Added #2143297: setters on FieldDefinitionInterface

Added #2144263: Decouple entity field storage from configurable fields to the summary.

Added #2144327: Make all field types provide a schema()

Added #2144631: Add a revisionable key to field definitions

Opened #2144677: Add per entity type managers to improve DX

Out of 149 criticals, 20 of them (~13.4%) have Entity system, Field system, or Field UI as their component. There are likely other ones hiding in there as well. Unfortunately, this situation has basically gone unchanged since the last time I pulled these numbers (July it was 18/140, or ~12.8%), despite the fact that I know a small handful of people are working very hard on these.

I think it's worth the folks leading this effort to have a real hard discussion about what things we can push to D9 (and/or 8.1.x) so that we can get D8 out the door.

Added #2151775: EntityFormController does things that only make sense for ContentEntities

@webchick: ... really? Should we do the same count for CMI or WSCCI then?

~13.4% does not seem like a lot to me considering the impact of the entity field api on D8.

Yes, we absolutely should. Each area of core needs a firm path to beta/RC. I feel like I know what that path is for CMI and WSCCI, I'm not as sure with entity/field API. That list of issues above is ENORMOUS. :( There's gotta be stuff in there we can de-scope in order to get things into a better place sooner.

Yes, I realize that. However, by nothing in this ginormous list being explicitly de-scoped, it's all still on the table, which means we in a lot of cases end up picking away at these edges and making less progress on the beta/release blockers overall. For example, #1976158: Rename entity storage/list/form/render "controllers" to handlers which is a great DX improvement, but doesn't actually directly lead to getting D8 out the door faster (rather, it causes issues that *do* get D8 out the door faster to have to re-roll their patches, hence delaying the release overall).

Maybe I'm needlessly worrying, and there are tons of these entity/field API criticals which are mere docblock-and-whitespace-nit-picking away from getting into 8.x? Can we focus instead on cranking those out, and then turn back to refactoring once things are in a better place, assuming there are still non-Entity/Field API issues blocking the beta?

I don't know. We're 6 months past the initial API freeze now, though, and I fear if we fast-forward another 6 months and still don't have a beta out, we'll be facing widespread burnout of the core team ala D7 which I do NOT want to repeat under any circumstances. :( I'm trying to take Dries's call for focus seriously, and entity/field API takes up a non-trivial portion of what's left. I'm genuinely open to whatever ideas you have.

20 of them (~13.4%) have Entity system, Field system, or Field UI as their component. There are likely other ones hiding in there as well. Unfortunately, this situation has basically gone unchanged since the last time I pulled these numbers (July it was 18/140, or ~12.8%),

I'm not sure that indicates lack of progress. Some current field API critical issues are sub-tasks of old meta issues, which have been independently promoted to critical. An example would be #2015687: Convert field type to FieldType plugin for taxonomy module which is one of two remaining conversions from an older critical meta issue that previously covered several, and which I just promoted to critical yesterday.

The same has been happening for the last, sticky CMI conversions that were previously covered under one critical meta issue, and in other subsystems too. Basically by not swamping the critical queue with dozens/hundreds of trivial conversions, we also managed to hide some intractable, release-blocking issues in the major/normal queues until they eventually ended up individually blocking the criticals. Some like menu links (which is as much CMI/WSCCI as an entity system issue although it's been primarily entity system that's resolved it) were obvious at the time as hard issues, some like search variables not so much.

So for those kinds of issues at least, it was technical debt introduced a long time ago, where 90% of the conversions are done, and 90% of the conversions are remaining ;)

Looking through the rest of the Entity/Field stuff in the critical queue, fourthree of those critical issues are render caching-related, which is completely distinct from Entity/Field API improvements. That's using the entity/field API to cover over performance regressions introduced throughout the rendering process (some of which is within the entity/field API but a lot of it isn't - Twig, link generation, CMI - anything which can happen within entity view). And to improve (cached) rendering performance to a position that's faster compared to 7.x's uncached performance, to compensate for other performance regressions outside of entity rendering too, we hope. Neither of these are anything to do with this issue, except that it happens to be entity/fields that make up the bulk of page content in Drupal.

#2099137: Entity/field access and node grants not taken into account with core cache contexts
#2099105: Clean-up render cache when permission changes
#2099131: Use #pre_render pattern for entity render caching

#1510544: Allow to preview content in an actual live environment is also not really entity/field API (and was promoted to critical by webchick in October) - that's a usability regression/improvement.

Another is missing hook_help() for display modes.

I've also committed one critical Entity patch this morning, and downgraded a critical/beta blocker that was fixed enough by that patch to no longer be critical/beta blocker.

All of that combined, I get 16 total issues in the critical queue (as of today) that are in those three components, minus 5 issues which are not Entity/Field API changes or are performance/usability improvements, which leaves 11.

I count 124 critical issues in the queue at the moment, not 149, but those ten remaining critical bugs and API changes which properly belong to this meta issue come in at 8.8% of 124.

ad #27: I'm unsure why it's expected that the Entity & Fields system criticals have to be fixed faster than the others :-(

Anyway, @number-of-criticals:
Yes, as pointed out by catch a lot of stuff gets put into the entity-bag. If we want to look at this conversion I think it would be more reasonable to filter criticals by our tag: link

Yes, I realize that. However, by nothing in this ginormous list being explicitly de-scoped, it's all still on the table, which means we in a lot of cases end up picking away at these edges and making less progress on the beta/release blockers overall

I don't think there is a reason to de-scope anything if it can go in after beta as well. But as you know we are currently identifying beta blockers what prioritizes them and - imho - leads exactly to the discussion you'd like to see.

#1976158: Rename entity storage/list/form/render "controllers" to handlers is certainly an issue that could be discussed for d8/d9, although I think it's critical for a sane DX. However, I don't see renames like this so problematic as the amount of required rerolls is minimal when the patches can go in fast. Moreover, I see the time it takes to get an average RTBC issue in - without any IRC boost - as more problematic. After a few weeks patches always start to conflict given d8's development pace, need periodic re-rolls and consequently take away worthwhile contribution time.

Moreover, I see the time it takes to get an average RTBC issue in - without any IRC boost - as more problematic.

This! I've also said it a few times before, good to know I'm not the only one concerned by it.

Edit: I realised that this comment could be interpreted as a critique regarding core maintainers. It's definitely not. The number of core maintainers relative to the number of patches in the queue is the issue, IMO.

I realised that this comment could be interpreted as a critique regarding core maintainers. It's definitely not. The number of core maintainers relative to the number of patches in the queue is the issue, IMO.

I don't intended to blame core maintainers either. I'm not sure whether the problem is the number of maintainers though, or more the development model used for developing a project of d8's size.

Anyway, that's a discussion which doesn't belong on this meta. My apologies for bringing this up here, but it gets sometimes frustrating.

Do we really want to keep the "Completed" section here ?

Also, when adding new issues in the summary list (well, at least in the "Not completed section"), it would be more convenient for people following here to also put the issue links in the comment :-)

Closed #1798140: Agree upon terminology for configurable fields

Added a new "Widgets / formatters rendering", moved a couple existing issues into it, and added #2090509: Optimize entity_get_render_display() for the case of "multiple entity view"

Right. Moved "Completed" below.

(this "completed" section is also why just the "view diff" is not good enough, because when looking at the diff you can't really tell if a change happened in the "completed" or "not completed" section :-p)

Added #2152825: rename FieldItemBase::getFieldSetting[s]() to getSetting[s]()

Moved #2157153: Remove field_attach_preprocess() to Completed
Moved #2027795: Optimize content entity serialization to Completed
Moved #2070429: Configurable fields aren't validated against the "required" constraint except in forms to Completed

#1879200: Remove uneeded $entity_type argument from entity type callbacks is in the completed section but is currently marked Active following a status update from 'catch'. I'm not sure quite what has happened but it seems possible it should be moved back out of Completed.

Added #2192259: Remove ConfigField.. Item and List classes + interfaces.

Move these to completed:

#1696648: [META] Untie content entity validation from form validation
#2002134: Move TypedData metadata introspection from data objects to definition objects Assigned to: fago (API Change)

I re-fixed that one but added #2312093: Rename FieldInstanceConfig to FieldConfig (but I don't see the previous one in the summary).

Added #2280639: Add the FieldStorageDefinition class to define field storage definitions in hook_entity_field_storage_info().

Moving some closed issues to the completed lists.

Do we really need to keep all of the completed ones now?

Issues about improving the generic entity revision API/UI. Also bumping to 8.8.

More issues

Just seen #2316171: [meta] Improve DX of entity defining (if you want a UI) has been closed in favour of this. Could this get a better title, so it's not just about fields?

Folks, the title of this issue is "Complete...", which implies a vision of what complete looks like, but this list seems to have become simply a list of entity issues.

How about working through the list of incomplete items, bumping some to "entity issues for D9" and some to "entity issues for D10", preferably with some overarching vision guiding both sets, and then mark this list closed?

One more done #2989889: Extract DraggableListBuilderTrait from DraggableListBuilder for use with content entities