Hey friends,

just wanted to leave a note that I feel I'm increasingly battling with more limitations of Field API in D8 that did not exist recently:

All of these are "hardcore edge-cases", but alas, the fact that they are edge-cases should not matter at all if everything is properly decoupled and no assumptions exist. ;)

An entity that is not stored (and will not be stored)

#1825044: Turn contact form submissions into full-blown Contact Message entities, without storage

Fields are attached to an entity that does not have a base table, and thus, does not have an entity ID, and thus, any attempt to query the entity will inherently fail. (Field data tables, could, however, be queried, if they are/can be set up independently from the entity's storage.)

The module/implementation leverages the followings facts:

  1. Entity bundles are sufficiently detached from entities.
  2. Entities do not necessarily have to be stored locally, nor do they necessarily have to have an ID.
  3. Field widgets are able to fully operate within an entity form context only.
  4. An entity and attached field values can be formatted based on an in-memory entity only (submitted form values).
A widget-only field type

#1751210: Convert URL alias form element into a field and field widget

The field that is attached is only involved in the form/user-input processing part of an entity. It has no formatters, no default formatter, and it won't ever be formatted.

The module/implementation leverages the followings facts:

  1. Not all fields are necessarily rendered/formatted.
  2. Field values are only saved for historical/revisions purposes, but always overridden by the field widget when it is loaded/processed.

Comments

sun’s picture

Hm. I'm battling with the second case right now... Drupal\field_ui\DisplayOverview seems to make the unconditional assumption that all attached fields can be formatted and should appear on the field display listing page, so I get:

Undefined index: default_formatter	Notice	DisplayOverview.php	111

Obviously, I can hide that PHP notice very easily... but that will still expose the field (for which no formatter exists) on the field display overview form. ;)

swentel’s picture

Regarding the second use case: I see this happening in D7 contrib as well, Metatags, redirect fields, potentially others. Users are confused that those fields are actually on the Manage display screens but don't render anything at all - and worse, if they are moved to hidden don't even work sometimes (that used to be the case for Meta tags in the beginning). I had an earlier discussion today with yched regarding the placeholders which could possible be a property on the widgetInterface - see #29. I guess this could easily be one as well and would open up a lot of possibilities I guess.

I need to think about the first one, but I need to go to sleep now first :)

sun’s picture

I think I'll actually go with the trivial/bogus fix for my second core patch for now, but regardless of that, I think I see two options:

A) 'default_formatter' on its own is interesting — is it... perhaps... a sufficient measure that allows to say:

Every field type needs to have a default formatter. If there is none, the field cannot be formatted.

B) DisplayOverview::form() does actually retrieve all available formatters for a field type (so as to show the select that allows the user to choose). So... just move this retrieval earlier in the function and skip over all fields that don't have any formatters?

sun’s picture

Issue summary: View changes

Updated issue summary.

sun’s picture

sun’s picture

In #1751210-109: Convert URL alias form element into a field and field widget (see interdiff), this time around, I had to take very concrete measures in order to make Field API cope with a field type that does not have any formatter associated to it.

It looks like the recent EntityDisplay changes made that situation considerably worse. I.e., where Field API was able to deal with fields/instances without a formatter before, it now unconditionally tries to instantiate a formatter plugin for a field that simply does not have a formatter (and won't ever have; at least in core).

I first assumed that the problem was limited to Field UI only, but further investigation showed that the regular entity rendering blows up with the identical exception / fatal error.

Therefore, I adjusted the FormatterPluginManager (which is the central spot for all possible calls throughout core) to properly account for the possibility of a field type that does not have a formatter or default_formatter assigned to it. The fix is relatively straightforward, but obviously I'm not as neck-deep into Field API as you guys are, so feedback and reviews are highly appreciated :-)

Further discussion on this essentially concluded that this is essentially very similar to #1465774: Provide a 'Hidden' field widget — but that is about widgets only. The problem space here is not about widgets, but about formatters instead. Perhaps it would make sense to create a sister issue to "Provide a 'hidden' formatter"...? :)

What do you think?

sun’s picture

Oh, and to clarify the problem space with the 'hidden' formatter:

Alas, yes, you are of course right - why would we need a hidden formatter if you can "disable" fields in the field display UI already?

1) The issue is that field types (which do not have a formatter), have to specify something as the default_formatter.

2) If they do not, then the EntityDisplay effectively saves an empty string for the formatter type to use for a field.

3) AND, FormatterPluginManager first checks the display settings (empty string ""), then tries to fall back to the field type's default formatter (not set [but expected to always be set]). This is where it blows up.

4) However, the field type cannot specify 'hidden' as default_formatter in its definition, because that is inherently interpreted as an actual plugin ID, and thus, FormatterPluginManager actually tries to discover + find + configure + instantiate an actual "hidden" plugin. :)

...which, in turn, equally blows up, since, alas, there is no "hidden" formatter plugin ID. :)

andypost’s picture

Another edge-case is comment as field - the field could have 2 formatters the same time: commentList and commentForm

andypost’s picture

Issue summary: View changes

Updated issue summary.