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.
I've just realised that in the use case I am working towards, it makes way more sense to the user if the choice made in the modal overwrites all previously-selected items on the form (instead of adding to them).
It's actually quite simple to add this possibility to this module by adding an extra option for it and tweaking the behaviour/wording at key points. Is this a piece of functionality you can see being in this module?
Patch to follow, so you can see what I mean.
Comment | File | Size | Author |
---|---|---|---|
#5 | entityreference_view_widget_support_a_replace-2771357-5.patch | 7.45 KB | jamsilver |
Comments
Comment #2
jamsilver CreditAttribution: jamsilver commentedPatch attached.
It adds a new field widget setting:
It also adds a new views field option:
When both are ticked you get a fully working replace workflow.
Comment #3
jamsilver CreditAttribution: jamsilver commentedOh, sorry - left a debug line in that one. New patch attached.
Comment #4
jsacksick CreditAttribution: jsacksick commentedHey jamsilver, I added you as a co-maintainer, feel free to commit it. I'm wondering about having two buttons (one for adding the items, the other one for replacing), what do you think?
Comment #5
jamsilver CreditAttribution: jamsilver commentedNew patch added with the following bugs fixed:
1. Cannot use a different "Choose/Replace" button label when a value is already selected or not as this breaks subsequent ajax requests (Drupal uses the form button value to determine what the triggering element is),
2. Fixed an issue whereby the boxes would become un-checked when the user interacted with any exposed filters. The new patch now embeds the settings/selected_Items in a hidden element in the exposed form, in the same was as is being done in the wider modal form.
Cool - thanks for that. I'll let it run a bit in the wild to catch any more bugs, and commit when RTBCed
This is an interesting idea. The patch I've added gives the choice to the site-builder - essentially forcing the content-admin to use either the Add item workflow or the Replace item workflow. This is what I want for my use case here. However, there is probably a use case for exposing both approaches to the user.
I wonder if what we need is a slight revamp of the field settings, to make it clear to the site-builder that they are choosing one of (or both of) two different workflows?