Revaluate the concept of 'extra fields'

As said in IRC, extra fields is currently used to expose all kinds of UI elements on entity forms and displays to the manage fields pages, e.g. contact settings for users. They're not going to become a field so we still need a solution for that.

Removing sprint tag, that is only used for issues that are actively being worked on at the moment and we can't work on this before the NG conversion is done and the field modules updated to work with it.

Agreed with Berdir.

A (possibly large) part the stuff that is currently exposed as an "extra field" could stop doing so if/when widgets and formatters become applicable to entity properties, since they will appear in Field UI as being "fields" (whether EntityFields or configurable fields). But :
- I couldn't say for sure that this will cover everything that is currently an "extra field"
- the premises are still hypothetical at this point :-).

So no, I don't think we're ready to drop the concept right now :-(.

Seems this one have duplicate as feature #1818680: Eliminate hook_field_extra_fields() / Redesign field UI architecture
Probably it's enough to use the issue to implement special kind of Typed data for all extra-fields as was done in #1732730: [meta] Implement the new entity field API for all field types

I would really really miss extra_fields, but I do want them with formatters and settings: #1983398: Allow formatters & formatter settings for extra_fields (display). Currently (D7) that's not possible with clean contrib, so the Field API will have to progress a bit.

With this discussion on hold, is it worth pursuing a fix in a separate issue to the extra fields system as is to actually use the extra field weight values when building entity forms? Right now, the default extra field weights and UI configured weights are completely ignored. A simple example is to move a node type's title extra field to appear beneath the body - it will not move.

Ahh, yeah, Bojan indicated that might be the case. I'd assumed that patch was already in when I started seeing form display variables in the $form_state. That patch is ginormous! I'll apply it while I'm fiddling around to see if it brings up any problems and make sure it fixes the one I know about. : )

So, right, I think 'extra_fields' are here to stay in D8.

Strictly speaking, the handling of extra fields has nothing to do in field.module though.
The corresponding hooks and functions should move to entity.module / the entity system:

Note that storing & loading their display configuration is already taken care of by EntityDisplay / EntityFormDisplay objects.

- field_info_extra_fields() / FieldInfo::getBundleExtraFields() / FieldInfo::prepareExtraFields()
(collect and cache the list of available extra fields)
I would say this would make sense split in two (extra fields in displayed entities, extra fields in forms), and moved to
EntityRenderController / EntityFormController.
- hook_field_extra_fields() / hook_field_extra_fields_alter()
(let modules expose their extra fields)
According to the above, hook_field_extra_fields() would be split in two separate hooks, one for entity views (called by EntityRenderController), the other for entity forms (called by EntityFormController)
Would be named hook_entity_something(), and would be documented in entity.api.php

Would need sign-off from a core committer for the API changes:
- hook_field_extra_fields() / hook_field_extra_fields_alter() renamed
- field_info_extra_fields() renamed (not too likely to be used in contrib though)

Discussed this with Alex Pott, effulgentsia and xjm at the Drupal Developer Summit in Chicago and we felt the extra field stuff should no longer exist. Given that the "extra fields" concept will most likely be removed in Drupal 9, we should just leave it alone for Drupal 8. It's not worth an API change at this stage of the release cycle. I believe we're tracking the proper solution in #1818680: Eliminate hook_field_extra_fields() / Redesign field UI architecture, hence I'm marking this "won't fix".

I do think the concept of "extra fields" is here to stay... "Add an arbitrary render array to an entity_view, and let admins reorder it through the 'entity display UI" is not a need that's going away even with more flexible fields. Not everything can be reduced to "a given formatter applied to a given field".

But I can live with the status quo in D8.

Then, retitling (back) rather than won't fixing.

Not everything can be reduced to "a given formatter applied to a given field".

No, but can't it be reduced to a component once we have #1875974: Abstract 'component type' specific code out of EntityDisplay?

Well, #1875974: Abstract 'component type' specific code out of EntityDisplay introduces component types, not individual components.

The scenario you describe is:
every arbitrary piece of render array currently added in FooRenderController::buildContent() or some flavor of hook_entity_view()/_alter(), becomes its own separate 'component type' plugin class.

- If the actual rendering stays in buildContent() / hook_entity_view() and is not in the plugin classes, then those plugin classes are all the same, and it's weird to have them be separate plugins. The current D8 way of "expose your stuff in a hook somewhere & a single 'component type' plugin will take care of managing their settings" makes more sense IMO.
- If the actual rendering happens in the classes, then what we have is just Blocks :-), and this is the "merge entity display with the block system" approach that was discussed at some point.

So yes, IMO the only thing that would let us remove "extra fields" in D9 is to fully merge "components in a rendered entity (fields, field groups, extra fields, DS 'custom components'...)" with blocks. EntityDisplay then become an entity-level "populated layout", like SCOTCH provides page-level "populated layouts". It was far too big / too late for D8, notably while SCOTCH was still a moving thing up in the air, but maybe for D9...

This means hook_entity_view() & friends become much less useful, and the DX to get "some arbitrary piece of output" into an entity becomes a bit more involved - you need to declare a block.

One challenge that comes to mind (among others...), is that field_groups introduces nesting, and I don't know if SCOTCH planned to account for that.
One other challenge is performance :-). SCOTCH's mission is "display one page layout fast enough". With the above, it becomes "display one page layout + 10s of entity layouts".
[edit - oh, and another challenge was node.tpl becomes basically unworkable]

Suppose the easiest way to move extra fields to calculated and allow entity display use 'em

Extra fields are genius, I'm planning to build a distribution that uses extra fields as a complete replacement for blocks. No more hacking template files or preprocess functions to embed blocks inside nodes! Instead we shall have one simple, unified way of displaying content through view modes.

One year later I still hold the same opinion. Extra fields and field UI can potentially solve the issue of slow block rendering and more elegantly than panels since it's more native to Drupal core. Use field groups and you'll have a completely flexible layout manager without having to create panels layouts in code. What you need to do is create a module that exposes all blocks as extra fields and then create a sweet ipe-like interface to place field groups, normal fields and extra fields/blocks wherever you wish. With the power of render cache and cache tags in D8, it should be really performant. The only thing that I really miss is to be able to create field formatters for extra fields, so that you can output for example author information in different ways. Maybe I'll be able to create a contrib solution for that, we'll see how far I can get within the limits of Drupal core.

@ordermind We do need extra field formatters/settings. Contrib could do this, but it won't be well known enough unless it's provided by Drupal. Relevant: #1983398: Allow formatters & formatter settings for extra_fields (display) and many duplicates

We should see what we can do with this in minor releases.

Adding an extra field from custom code or contrib still requires hook_entity_extra_field_info and hook_entity_view_alter. Also, I couldn't get thirdPartySettings to work on the extra field itself even though it gets initialised with an empty array. If you want to add custom settings you also need a hook_form_FORM_ID_alter and a form submit callback.

Could we wrap all these hooks up into a new plugin type? @ExtraFIeld, that made it easier for developers to add extra fields without having to find all the procedural hooks?

ExtraFieldComponent is good idea

With that approach you have to have one of those dummy field item classes for each field you add? Plus, if you want to format the output differently, you need a new field formatter each time as well. I did actually contemplate this approach myself for a contrib module but ended up using an extra field to place a simple link.

@ivanjaros I think you're genius! Thank you for sharing your solution. It's not perfect but it's far better than current extra field :)
It'd be really great to have something in Core to modernize these concepts.

I think we should something similar to #23 in core as well.

#21 I couldn't get thirdPartySettings to work on the extra field

There's a new contrib module called "Extra field settings" that makes this easier, see this article.

#21 Could we wrap all these hooks up into a new plugin type? @ExtraFIeld, that made it easier for developers to add extra fields without having to find all the procedural hooks?

There's a new contrib called "Extra field" module that does just this.