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.
Problem/Motivation
In #2656196: Initialize Entity Browser with existing selection we added support for passing existing selection to the entity browser. This is one of the follow-ups.
Proposed resolution
Update field widgets that we provide to be able to laverage the new possibilities. This feature should be configurable. We will have two modes:
- Append mode: Existing selection is not passed in and entities returned from the Entity browser are appended to the current selection. This is current behaviour.
- Edit mode: Existing selection is passed in and entities returned from the Entity browser replace existing selection. In this mode we allow user to edit entire selection in context of the entity browser.
There is some code in the original patch of the parent issue (uploaded by @webflo), that should be used when implementing that. @webflo should be attributed in the commit message for this issue as a result of that.
Comment | File | Size | Author |
---|---|---|---|
#13 | interdiff-2767737-13-10.txt | 8.91 KB | mtodor |
#13 | allow_passing_existing-2767737-13.patch | 36.58 KB | mtodor |
Comments
Comment #2
mtodor CreditAttribution: mtodor commented@slashrsm - I have started working on original issue, now I want to finalize changes and prepare patches, but I have one problem and I'm not sure, should I go in that direction.
I have created options for Append Mode (it's actually Combine Mode) and Edit Mode. Now open question is, should we allow multiple selections of same entity or not? In general, that functionality should be supported, but should I make it with this patch (ticket) or not?
Comment #3
slashrsm CreditAttribution: slashrsm as a volunteer commentedYes, I think that we shouldn't make any assumptions about that. Entity reference field supports that and we should too in my opinion.
Comment #4
slashrsm CreditAttribution: slashrsm as a volunteer commented#2768585: Add option for prepending of fresh added items seems related.
Comment #5
mtodor CreditAttribution: mtodor commentedHere is patch, unfortunately I wasn't able to split it in tow parts for #2767739: Define which selection displays support existing selection and which not, so basically changes relevant for that ticket are in this patch.
Implemented things relevant for #2767739: Define which selection displays support existing selection and which not:
- annotation for selection displays (are they allow preselection or not)
- using of annotation in field widget to check is preselection supported or not
Implemented things relevant for this ticket:
- selection mode option for entity reference field widget (settings + summary)
- propagate selection to selection display if edit mode is used
Additional things fixed are:
- multiple selections of same entity (also adjusted remove functionality to work properly for that in multi step selection display and selection display for field)
- appending of selected entities (before it would combine selection from entity browser with existing selection), now it will be appended
- generation of weights didn't work properly in multi step selection display
- test is adjusted to use multi step selection display and edit selection mode
After these changes, it's possible to edit/remove/add selection with multi step selection display.
Comment #8
mtodor CreditAttribution: mtodor commentedUpdated patch, a bit of restructure and defining default selection mode for field.
Comment #9
slashrsm CreditAttribution: slashrsm at MD Systems GmbH commentedThanks! This looks great! First review:
This is common code, which can be used outside of the field scope. We shouldn't refer to the entity reference.
I am personally a bit against this kind of assignments as I think they decrease readability of code.
Comment should use all 80 characters.
This comment reads a bit strange.
It would probably make sense to have a helper function to check that. Would improve DX in my opinion.
Do we need this extra variable?
We load entities and then we iterate over their initial ids. Seems redundant. What am I missing?
We need to figure out how to refactor this condition. Probably with some logic before the actual diff.
#default_value should only be set if edit mode is active.
This will raise PHP requirement to 5.6 (which I am fine with). Core still depends on >= 5.5.9. We will need to document this requirement in README and check it in hook_requirements() if we want to do this right.
Do we need to update those since we're not actually testing this?
Comment #10
mtodor CreditAttribution: mtodor commentedHere is new patch, no interdiff, because it's based on new code.
Additional changes:
Comment #12
slashrsm CreditAttribution: slashrsm at MD Systems GmbH commentedThis looks almost ready. Thank you for your hard work! Few nitpiks:
s/prepend/prepended
s/sued/used (noticed by @primsi :))
Last sentence reads a bit strange.
Cardinality constant was put here on purpose. The reason for that was the fact that the Entity browser doesn't depend on fields at all. Fields are just one possible usage of it.
However, this doesn't seem that important. While I prefer the current solution I am open for other solutions too.
I think that this function belongs to the Selection display plugin class.
Comment #13
mtodor CreditAttribution: mtodor commentedI wasn't able to create proper interdiff (it's based on code before last 2 commits).
Comment #16
slashrsm CreditAttribution: slashrsm at MD Systems GmbH commentedCommitted. Thanks!