Updated: Comment #0
Problem/Motivation
The Taxonomy Term entity type's name
and description
fields are still handled through custom code in entity forms and entity views.
Proposed resolution
Move to widgets and formatters.
AFAICT the following base fields cannot yet do the switch:
langcode
, because its visibility depends upon very specific settings, that I don't think can easily be generalizedparent
&weight
, because they must be inside the "Relations"<details>
, which is pretty much a field group, which we don't have in core
That only leaves the Taxonomy Term entity type's name
and description
fields.
Remaining tasks
Fix test failures.
User interface changes
None.
API changes
None. The taxonomy_term.name
and taxonomy_term.description
base fields are rendered using widgets and formatters, and are no longer exposed as "extra fields".
Comment | File | Size | Author |
---|---|---|---|
#21 | 2225431-21-taxonomy-term-base-fields.patch | 23.76 KB | mr.baileys |
#20 | 2225431-20-taxonomy-term-base-fields.patch | 22.37 KB | mr.baileys |
#15 | interdiff.txt | 1.68 KB | Wim Leers |
#15 | 2225431-15.patch | 24.77 KB | Wim Leers |
#12 | 2225431-9-12-interdiff.txt | 710 bytes | mr.baileys |
Comments
Comment #1
Wim LeersNote: this patch was split off from Berdir's patch in #2010930: [META] Apply formatters and widgets to rendered entity base fields (all besides node.title).
Changes I made:
.taxonomy-term-description
class was no longer being added; upgraded test coverage..taxonomy-term-description
did not make sense: its utility was highly questionable anyway. I've asked Lewis Nyman to check in/confirm that.template_preprocess_taxonomy_term()
used to break thetaxonomy-term.html.twig
template.Comment #3
Wim LeersComment #4
yched CreditAttribution: yched commentedYay !
Adjusted issue summary, this does not turn the base fields into configurable fields, only makes them use widgets / formatters.
Comment #5
yched CreditAttribution: yched commentedside note: I'd happily leave it to someone to update the summaries on #2225371: Apply formatters and widgets to Custom Block base fields and #2225399: Apply formatters and widgets to Feed base fields similarly ;-)
Comment #6
mr.baileysAssigning to myself to work on this during the Drupal Developer Days Szeged sprint.
Comment #7
mr.baileysFixed the test failures.
Comment #8
yched CreditAttribution: yched commentedHm, we still want to provide a 'content' section with 'name' and 'description' entries in the display shipped in default config.
We just want to extend each of those entries with properties for "being displayed by a widget / formatter" - see how it appears in a real-life entity.form_display.taxonomy_term.forums.default.yml file after the patch (and after submiting the corresponding "Manage Form" screen)
Unrelated / not needed ?
(I know we put those more and more, still hate them ;-)
Comment #9
mr.baileysThanks for the review @yched!
Regarding your first point, this might be indicative of another bug, but we had to remove this to prevent ContainerFormController from breaking:
Widget instantiation in EntityFormDisplay::getRenderer():
EntityDisplayBase::getComponent():
If we left the content section in, then $this->content['name'|'description'] would no longer be empty but contain weight. This caused the widget for the fields to fail initialization, since getComponent() returned a configuration array with just weight, none of the other properties like type, and the widgets for name and description ended up being NULL.
I have removed the @var type hinting mentioned in your second point.
Comment #10
mr.baileysForgot to attach interdiff in previous comment.
Comment #11
yched CreditAttribution: yched commented@mr.baileys : that's because the entries should turn from "entries for an 'extra field'" to "entries for a field rendered by a widget" - i.e, they should now have a 'type' property, which is the name of the widget (and optionnally, not needed in our case here, a 'settings' property).
Something like :
core/modules/forum/config/entity.form_display.taxonomy_term.forums.default.yml
#1875974: Abstract 'component type' specific code out of EntityDisplay will make the difference between the two kind of entries (extra fields / fields using a widget) more explicit, but for now that's how it works.
Comment #12
mr.baileysThanks @yched! Fixed with help from Wim Leers and swentel.
Comment #14
swentel CreditAttribution: swentel commentedOh wow, this was fun to debug
Comment #15
Wim LeersTalked to swentel and we agreed that the addition to
text.schema.yml
in #14 belongs inentity.schema.yml
.Comment #16
yanniboi CreditAttribution: yanniboi commentedHey, so this is a review of @swentel's patch in #14 (because @Wim is too fast for me... ;) ) Will reapply patch and double check for #15.
Patch applies fine and form display and rendering of taxonomy term look identical to pre-patch.
Here are screenshots of working formatters:
Comment #17
yanniboi CreditAttribution: yanniboi commentedConfirmation: Patch #15 works just as well.
RTBC pending test result.
Comment #18
alexpottNeeds a reroll
Comment #19
mr.baileysComment #20
mr.baileysComment #21
mr.baileysPrevious patch was missing changes from #14/#15. Here is the correct re-roll.
Comment #22
yanniboi CreditAttribution: yanniboi commentedTest is green, since it is just a reroll (and currently applies), I'm moving it to RTBC.
Comment #23
catchCommitted/pushed to 8.x, thanks!
Comment #25
Wim Leers