Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
In the current situation, the ViewsReferenceSetting plugins have limited options to provide settings fields to the widget. For more complex settings this might not be enough.
Proposed resolution
Implement subforms for the ViewsReferenceSetting plugins to allow more flexibility.
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | 2932621-viewsreference-setting_plugin_configuration-12.patch | 2 KB | bgilhome |
| #2 | 2932621-better-argument-widget-2.patch | 12.37 KB | rodrigoaguilera |
Comments
Comment #2
rodrigoaguileraHere is a working patch.
It depends on the patch I did at #2932381: Hide the choice for a view display if there is only one option
To guess how to build the widget it looks into the argument validation configuration and arranges a select list based on the entity type and bundle.
I changed the interface for the plugins so there is more options and info to alter the form.
I unified the way for retrieving a View (no need to fetch the views executable).
This patch has an ajax problem: when you create a field value for the first time and you select a view that triggers the widget replacemet the configuration for the arguments is not saved correctly. You have to load the form again and configure the arguments.
Without the workaround in the patch detecting if this is an ajax request the loading of the widget breaks with:
Cannot create references to/from string offsets in Drupal\Component\Utility\NestedArray::setValue() (line 156 of /var/www/html/web/core/lib/Drupal/Component/Utility/NestedArray.phpI feel there should be no ajax to load the displays and it should be summarized in one select list with NAMEOFTHEVIEW - NAMEOFTHEDISPLAY but that is the concern of a different issue.
Comment #3
rodrigoaguileraMaybe alterFormField should also be more flexible about the widgets that can be provided instead of forcing a single textfield
Comment #4
seanbI personally try to write custom
ViewsReferenceSettingplugins instead of trying to solve everything with arguments. Is there a reason why you are not usingViewsReferenceSettingplugins to accomplish this?Comment #5
rodrigoaguileraWhat I am trying to achieve is to improve the
ViewsReferenceSettingplugin shipped with the module to select arguments for the view in a friendlier fashion for the end user that does not know how to get the ids of the nodes that need to go separated by '/' and want to select them by just looking at the titles.We wanted to configure different views with arguments and have the widget automatically set up instead of writing a custom
ViewsReferenceSettingfor each view.Do you think it should be a different
ViewsReferenceSettingplugin? Maybe is a bit confusing to have two plugins of this kind that affect views arguments.One thing I feel should be improved is the capability for this plugins to alter the form of the widget so they can be a bit more powerful. Maybe this is a previous issue that needs to be sorted out before this one.
Comment #6
seanbI thought about providing more information to the plugins about the form, but I decided they should not care about the parent form. We could make the plugins provide subforms, this would allow them to get more complex without being able to mess with the parent for too much. This is a separate issue though (thinking about it I should have probably done it like this to begin with).
About the arguments widget, there are lot's of argument types and different ways you want to go about selecting values for that. I'm not sure if we can do this in a way that works for everything, all the time. I feel the 'smarter' this gets, the more the users would expect of this feature. Making the entire configuration 'automatic' based on the arguments configured in your view would probably be really complex. Even the example of users selecting nodes could work in lot's of different ways: autocomplete, select list, entity browser. How about selecting multiple nodes?
I would be happy to accept a patch that changes the plugins to use subforms and allow them to provide more fields. I think the complex
ViewsReferenceSettingplugin should probably go in a separate module. This could lead to a lot of bugs and support requests of which I'm not sure I'm willing to take on the maintanance.Comment #7
rodrigoaguileraOk this is at least a way forward :)
I will make a proposal for improving the
ViewsReferenceSettingplugin system that will open the door for more complex plugins while maintaining all the current ones.I hope I can do this before the end of the alpha cycle.
Comment #8
seanbThank you!
Comment #9
rodrigoaguileraComment #10
bgilhome commentedApologies for commenting on a closed thread - just wondering if something like the attached would be suitable to extend the ViewsReferenceSetting plugin system by passing view name & display id to the plugin? This allows customising the plugin based on selected view/display but not on the parent form context.
Patch attached - renames the view name & display id variables to reflect what they are (renamed from $full_view_name and $default_value).
Comment #11
bgilhome commentedUpdated patch to check isset before passing view_name / display_id to plugin configuration.
Comment #12
bgilhome commentedFixing the variable name passed to 'display_id'.
Comment #13
seanb@bgilhome I'm not opposed to adding the patch you suggested. Could you create a new issue for that? Changing the IS of this issue to reflect we are going to implement subforms for the plugins.
Comment #14
seanbComment #15
scott_euser commented