Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
field_behaviors_widget() is a thing from CCK D6, it is mostly stale now.
Code currently calling it to check the 'default_value' or 'multiple_values' properties of the widgets need to
- call $options = entity_get_form_display()->getComponent($field_name)
- then call WidgetPluginManager::getDefinition($options['type'])
This should probably move to a getRendererDefinition() method on the EntityDisplay class ?
Comment | File | Size | Author |
---|---|---|---|
#23 | constants-2047997.patch | 1.06 KB | asimmonds |
#19 | 2047997-19.patch | 1.97 KB | swentel |
#19 | interdiff.txt | 670 bytes | swentel |
#17 | 2047997-17.patch | 1.92 KB | swentel |
#14 | field-behaviors-widget-2047997-14.patch | 4.2 KB | jlindsey15 |
Comments
Comment #1
yched CreditAttribution: yched commentedtagging
Comment #2
yched CreditAttribution: yched commentedand tagging
Comment #3
jlindsey15 CreditAttribution: jlindsey15 commentedI'll take this.
Comment #4
jlindsey15 CreditAttribution: jlindsey15 commentedHere's my first try. I put it in the EntityFormDisplay class instead - that seemed to make more sense.
Comment #6
yched CreditAttribution: yched commentedThe first line of functions/methods phpdoc should fit in 80 chars if possible.
Maybe "Returns the definition of the renderer plugin used for a component" ?
Then the @return section could be:
"The definition of the renderer plugin (e.g. widget, formatter), or NULL if the component is not set."
As a replacement of field_behaviors_widget(), we need the method to exist on EntityFormDisplay, true.
But generally speaking, the method would also make sense on EntityDisplay objects.
So I'd suggest adding it to EntityDisplayBaseInterface & EntityDisplayBase
Should be $this->getComponent($field_name) :-)
(probably explains that patch fails to install)
Also, it should be wrapped in an if() because the field might be hidden, in which case getComponent() will return NULL:
Comment #7
jlindsey15 CreditAttribution: jlindsey15 commentedThanks for the comments - good point about putting it in EntityDisplayBase. When I'm flip-flopping between coding in PHP and java, I always forget to do this->function() instead of just function()... I'll have the reworked patch in a bit.
Comment #8
jlindsey15 CreditAttribution: jlindsey15 commentedComment #10
webchickSo granted I've been out of the loop awhile, but I'm a bit confused why we are ripping functions out in
"normal" tasks when we're past API freeze..?
At the very least, we should keep the old function there with a @deprecated thing, no?
Comment #11
yched CreditAttribution: yched commentedI'm fine with keeping the function around as @deprecated, but:
- This function makes very very little sense in D8. "Give me this property from the plugin definition of the widget used by this field".
But now that we have "form modes", there is no such thing as "the (one and only) widget used by this field". Just like "what's the formatter used by this field" makes no sense - in which view mode ?
The function currently uses the widget used in the 'default' form mode, but this makes no special sense.
- It's really a remnant from CCK D6 where widget info definitions had a 'behaviors' entry, which doesn't exist anymore. Its only possible remaining use is for "default values", and it's a sick use, that we need to get rid of anyway : #2056405: Let field types provide their support for "default values" and associated input UI
Comment #12
jlindsey15 CreditAttribution: jlindsey15 commentedAdded it back as @deprecated, still haven't fixed the bug in the patch though. @deprecated doc may change depending on how it gets fixed.
Comment #14
jlindsey15 CreditAttribution: jlindsey15 commentedSee comment 12 description
Comment #16
yched CreditAttribution: yched commentedNow that #2056405: Let field types provide their support for "default values" and associated input UI is in and the 'default_value' entry in widget plugin definitions is not supported anymore, we have no reason whatsoever to keep field_behaviors_widget().
We should really just remove it.
Comment #17
swentel CreditAttribution: swentel commentedLet's see
Comment #18
yched CreditAttribution: yched commentedThis looks like this might be useless now ?
Comment #19
swentel CreditAttribution: swentel commentedYeah, probably, let's see.
Comment #20
yched CreditAttribution: yched commentedLooks good if green
Comment #21
catchCommitted/pushed to 8.x.
Could use a short change notice - not much more than the image summary.
Comment #22
yched CreditAttribution: yched commentedCreated https://drupal.org/node/2102175
Comment #23
asimmonds CreditAttribution: asimmonds commentedShould the three FIELD_BEHAVIOR_* constant definitions in field.module be removed as well?
I can't find anything in core that still uses them.
Comment #24
swentel CreditAttribution: swentel commentedRight, duh, good catch, thanks! :)
Comment #25
webchickCommitted and pushed to 8.x. Thanks!