I have a paragraph field on a node where editors can select one of two different paragraph bundles, but they can only add one paragraph to the node. Currently, when this paragraph is added it is displayed in a draggable table cell, even though a second paragraph can never be added to that node, so reordering will never be an issue. This can create confusion for users.
If a paragraph field has been configured to only accept one item, then don't wrap the paragraph in a draggable table.
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | Paragraphs.mp4 | 1.08 MB | steinmb |
| #2 | only-one-paragraph-2272221-2.patch | 4.57 KB | jstoller |
Comments
Comment #1
jeroen.b commentedSounds reasonable. Initially Paragraphs did not have support for a amount limit (only unlimited).
The limit (so also limit on 1 item) was built in later, so I didn't really think about this.
Will look into this soon.
Would be nice if somebody else were to look into this, it's not that hard to fix, but there are many other issues in the queue.
Comment #2
jstollerI took a crack at fixing this. I just reorganized theme_paragraphs_field_multiple_value_form() a bit, ditching the table if the paragraphs field can only hold one item. I'm sure there are more optimizations that could be made if I dug deeper into the code, but I'm not sure it's worth it to try.
Comment #3
jstollerComment #4
amoebanath commentedLooks good! Working nicely for me.
I'd only really quibble the extra line on 1192 :)
Comment #5
miro_dietikerI think we also need to consider this in 8.x where we recently started more intense discussions about the UI.
Comment #6
amoebanath commentedSure. Link?
Comment #7
jstoller@miro_dietiker: In the mean time, any chance you could commit this to the D7 branch?
Comment #8
miro_dietiker@jstoller Not really, sorry.
I took the lead towards a stable D8 release and sometimes commit RTBC bugfixes on D7. But i don't know enough about the D7 version and there is no good test coverage that allows me to see if things are still fine. Note that the patch above adds complexity with a bunch of new conditions.
Finally, in D8 we strictly only commit issues with test coverage. I would establish a 8.x feature first workflow anyway...
Comment #9
jstoller@jeroen.b: Just a friendly request for comment, if you don't feel this is ready to commit.
Comment #10
jeroen.b commentedLooks alright. Committed, thanks!
Comment #12
jeroen.b commentedComment #13
miro_dietikerSo now that this is committed, we will need to discuss if this needs a port.
IMHO we should wait until we have a clean uniform UX in D8 that follows the idea of a default best practice pattern.
Indentation was always an issue and we tried to improve it. We have seen that by removing drag handles or adding them, indentation changes and this can cause user confusion.
As an example, take this: #2737863: [META] Allow to add a paragraph between any item
The button was before not indented and horizontally aligned with the label. By adding drag handles this alignment is lost.
If indentation varies for nested cases, it can be highly confusing.
Also for D8, note that the issue to make items draggable accross fields will require to ALWAYS have drag handles present.
See #2658694: Move a nested Paragraph across fields and nesting
Still assigning to 8.x once for discussion, but from our plans and D8 UI goals, i would see this a won't fix.
Comment #14
jeroen.b commentedAgreed that we should wait until we have a clear vision on the D8 UX goal.
Comment #15
jstollerPerhaps this could be a configurable option. In my case, the paragraphs fields that only accept one item do not need to support dragging across fields. The bundles they support are only used in those fields.
Comment #16
jonathanshawYou could override in the theme layer? Miro has implied in various places that having many minor aspects of the UI be configurable makes maintenance difficult.
Comment #17
jstollerPerhaps, but this is a UX issue. An single undraggable item rendered as a draggable table can be confusing.
Maybe there could be an option to enable/disable cross-field dragging on a per field basis. Then, if a one-item field has cross-field dragging disabled you can render it appropriately. And I wouldn't be surprised if people have use cases where they want to disable this behavior on specific fields for other reasons.
Comment #18
steinmb commentedBumping a old issue. Not sure it is related but here is Drupal 9.0.4 with Claro. Notice how tabledrag look when it is enabled even if there is only a single value.