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
The "..." button renders on the wrong place.
Proposed resolution
Bring this button to the right on the behavior tab row... somehow. At least to the right.
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | Screenshot from 2018-01-31 15-36-06.png | 11.43 KB | johnchque |
| #7 | the_drag_drop-2933516-7.patch | 799 bytes | johnchque |
| |||
| #6 | Screenshot from 2018-01-31 15-26-40.png | 8.89 KB | johnchque |
| primer-library-button.png | 3.6 KB | miro_dietiker | |
Comments
Comment #2
BerdirI would think this is a generic issue with paragraph widget on a single-value field.
Comment #3
miro_dietikerThen promoting for investigation and maybe move into Paragraphs.
Comment #4
johnchqueTested in single-value paragraphs field, the button is displayed correctly, I think the ones that go to the left (the bogus ones) are the ones that apply operations to all elements inside the paragraph field.
We would need tests, maybe even restrict the allowed number of values to one? In the first level. In the paragraphs library item form.
Comment #5
miro_dietikerThe image above is from the paragraphs library (with its single value field) when it displays in the overlay after pressing edit in the parent widget.
@john did you really test with the drag& drop library installed?
Comment #6
johnchqueI see now, yes, it is a generic problem with the paragraph widget in single value fields.
Didn't notice at first.
It even gets out of viewport.
Comment #7
johnchqueActually only this change is needed IMHO. It works but I've notices some random pattern about the horizontal placement of this drag and drop button, sometimes it is rendered below all elements of the paragraph, sometimes at the top.
Comment #8
johnchqueForgot it, we need to move this to Paragraphs. :)
Comment #10
BerdirI guess the only question is if we want to add the same logic as we have for the per-paragraph actions, that there is a main button that is always visible.. usually that's edit/collapse all, which doesn't exist here, so maybe drag & drop should be displayed as a normal button.. looks a bit strange to have a standalone ...-thingy IMHO, but lets see what Miro thinks.
Comment #11
johnchque+1 for having it always visible.
Comment #12
miro_dietikerNote that the Library has this problem as well: #2941011: Library item paragraph field label not visible
So yeah for single value fields where we don't have the Collapse / Expand all, the top level "..." only contains Drag & drop.
It seems to me like with multivalue table header, the button should be on the same line as the field label.
If it's really only a single value field like a "text" field or in flat field lists like the field collection use case, it can be quickly cumbersome to have the "Drag & drop" button taking so much attention.
So i don't know how to define this best. Maybe need to create mock-ups for these situations. Let's readd the label first.
Comment #13
miro_dietikerComment #14
johnchquePostponed in favor of #2842094: Field label is styled differently when field is empty.
Comment #15
miro_dietiker@john thanks for the issue updates! Please make sure to also connect issues, most importantly postponed references.
Comment #16
BerdirPostponed or duplicate? Tested and it works fine with the latest patch in that issue.
Comment #17
johnchqueLet's close it then. :) We will fix this in the related issue. :)