In light of the work being done on the unified Entity Field API, is Field API's concept of 'extra fields' still relevant? I don't think I was around Drupal when this was introduced, but it seems to me that it only serves the purpose off adding 'stuff' to entity displays and forms that are *not* configurable fields. Given that we now have a new API for entity fields (formerly known as properties), and we want to move in a direction that allows existing field formatters and widget to be used by them, I think that a lot of special-casing code can be dropped and cleaned up.

It would be great if pseudo fields added via hook_field_extra_fields() could have their label actually displayed within the context of the node (or entity) being viewed in the same way "normal" fields have their label displayed. Currently, the simplest way that I have found to display an inline label for an extra field that fits in with the rest of my fields is to do something like:

Extra fields can't have formatters, formatter settings or a formatter summary. field.module and field_ui.module could provide this, so that other modules (that define extra fields) can use those settings. A use case: A module that provides registrations on nodes also provides a link to the register page. That link is an extra field. It would be excellent if the developer could enter a link text (to be used by the registration module in MODULE_view() eg). Another module could then create another formatter for that link to make it open in an overlay (and then alter the entity display).

This module provides a "Plugin reference" field that allows to create soft references to plugins. This module was created to allow to create relationships between entities and plugins in a simple way. The aim of these relationships is usually to perform background actions against the entity using the selected plugin. Usage This module provides a new field type that can reference a plugin. Usage is straightforward. You only need to create a new field of type "Plugin reference" for your entity and configure it in the same way you do for other field types.

Issue #1875974 by swentel, andypost, yched, amateescu aspilicious: Abstract 'component type' specific code out of EntityDisplay. The EntityDisplay class introduced in [#1852966] includes hardcoded logic to handle "field" and "extra field" components. Problem: - It currently only deals with "Field API field" & "extra field" (aka arbitrary render array snippet) components. There is hardcoded logic to determine which is which and how to handle each. --> Contrib "component types" are currently not possible, and it's very much needed for Display Suite / Field groups.