Problem/Motivation
The ability to collapse paragraphs items and show simple previews is great when you have a lot of items on a field. However, I've found that I frequently have paragraphs fields that only have one item in them. For instance, a page content field on a node that can potentially hold lots of items, but on some nodes just has one bundle with a text field for the body copy. Or a "highlight box" paragraphs bundle with a nested paragraphs field that, likewise, could hold a number of items but in many cases only one is needed. In these cases the extra click needed to open the paragraphs item for editing becomes a burden. The second case can be particularly annoying, since I have to first expand the highlight box item to edit it and then expand the nested paragraphs item within it.
Proposed resolution
If someone chooses "Closed," or "Preview" as the default edit mode on a paragraphs field, then allow them to set a default edit mode override limit. If a fields item count falls below that limit then items will be forced to display as "Open" when the field is edited.
| Comment | File | Size | Author |
|---|---|---|---|
| #30 | interdiff-2577229-28-30.txt | 6.56 KB | arpad.rozsa |
| #30 | display_paragraphs_as-2577229-30.patch | 8.1 KB | arpad.rozsa |
| #28 | display_paragraphs_as-2577229-28.patch | 10 KB | arpad.rozsa |
| #25 | interdiff-2577229-24-25.txt | 5.34 KB | kristofferwiklund |
| #25 | display_paragraphs_as-2577229-25.patch | 11.64 KB | kristofferwiklund |
Comments
Comment #2
jstollerI think this should do it.
Comment #3
jstollerIt occurred to me that only supporting this feature for a single item was rather arbitrary on my part. I've updated the patch so site builders can set a limit from 1-99, below which the paragraphs bundles will be forced to display in the open edit mode. I've updated the issue title and description to match the new behavior.
Comment #4
jstollerFixed it so you can still collapse the paragraphs items after the initial page load, even if there are less items than the override limit.
Comment #5
jstollerCleaned up implementation. I think I'm done now. :-)
Comment #6
jstollerWhile I'm waiting for this to be reviewed, I figured I'd throw in one more little tweak. :-)
Now you can do something like this...
...which should help with issues like #2624596: Don't collapse default paragraphs items on new nodes.
Comment #7
amoebanath commentedWorks beautifully.
Made a quick spelling change though :)
Comment #8
sachbearbeiter commentedGreat - thanks a lot ...
Comment #9
jstoller@jeroen.b: Just a friendly request for comment, if you don't feel this is ready to commit.
Comment #11
jeroen.b commentedThanks guys, this is great. Pushed!
Comment #12
miro_dietikerOh, new features. Needs a port. :-)
Comment #13
tassilogroeper commentedComment #14
bonrita commentedPorted the drupal 7 functionality to drupal 8. Needs review.
Comment #15
bonrita commentedComment #17
seanbThis name does not really reflect what it does? It store a int, but it reads as if it should store a bool.
This is a bit weird. I understand why it's done, but at least use a data attribute or class or something valid.
The test need to be updated to reflect the latest changes.
Besides that, I think we can improve this. We should at least not change the default behaviour and add a checkbox to opt-in on this feature. Maybe it's best to create a new issue for this?
Comment #18
johnchqueThis is just a proposal.
I've been working on Paragraphs the last months and the maintainers plan was to avoid cluttering the UI with too many options and so on, so why if instead of setting a max/min number of paragraphs we just add a checkbox to enable this feature with a fixed amount of paragraphs in a node?
For example, the patch attached to this comment would just check if there are more than 4 paragraphs to change the edit mode to "open". We would anyway need to add the checkbox in settings. As said, this is just a proposal, just want to avoid cluttering the UI. :)
Comment #20
seanbMaybe changing the default to empty or zero would already do the trick in regards to the default behaviour?
Comment #21
jstoller@seanB: In the D7 patch, we override the default edit mode if the number of paragraphs items is less then $default_edit_mode_override, so we define PARAGRAPHS_DEFAULT_EDIT_MODE_OVERRIDE = 1 to maintain the default behavior. It appears that the D8 patch overrides the default edit mode if the number of paragraphs items is less then, or equal to, $default_edit_mode_override, though the description of the field still indicates it is simply less than. To fix this, I'd change:
to:
This changes the
<=to<, simplifies the if statement and clarifies the comment.@yongt9412: I strongly oppose hard coding the limit value. Originally I was going to set this at 2 on my site. Then I decided to up up that to 3, but I can foresee cases where I would want it to be less, or more. This is something that should be set by site builders when defining a paragraphs field, not end users, so I think they can handle a slightly more cluttered UI to get this functionality.
Comment #22
seanbI still think it's strange that a field to override something has a default value. Overriding something should be optional, not default behaviour IMHO.
And we should add _limit to the various names since we are actually storing limits.
Comment #23
jstollerI have no problem with adding "_limit" to all the variables.
Setting the default value to 1 means you aren't overriding anything, so overriding is optional. I guess you could set it to NULL, but you'd probably have to add some !empty() checks in there to prevent errors. This just seemed simpler and has the same effect.
The other option is to change it so you are setting the highest number of items for which the override will happen, instead of the number under which the override will happen. Then you could set the default to zero. I have no problem with this conceptually, but you'd need to change the form field from:
to:
If you make that change in D8 then I'd probably want to backport it to D7, for consistency.
Comment #24
ginovski commented1. Added '_limit' to the variables.
2. Changed the default limit to 0.
3. Added tests.
Comment #25
kristofferwiklund commentedI have re-rolled this for latest 8.x-1.x version.
And it works nice.
Comment #27
miro_dietikerWe have a new partially related functionality: #2901994: Add edit mode option to expand only paragraph types with paragraph field
So what we want is that this threshold applies to all closed modes as the implementation seems to do.
Here's a quick review:
live = leave?
A very long text for a summary.
I don't think we need a const for undefined / default.
Maybe "closed mode threshold" would be easier to understand. But it would change the logic.
I don't think that 99 is a real technical limit or specifically makes sense. Can we not just skip the limit?
Looking forward to get this in soon as this seems to improve the UX in many cases. :-)
Comment #28
arpad.rozsa commentedChanged the previous patch, so that it works with the newest state of the branch, including the previously introduced related setting "Closed, show nested".
Comment #29
berdirBy changing the concept to a threshold, the exact value should then already switch to closed.
Maybe it's just the description that's outdated.
I guess we should only show this if it's non-zero?
We need some settings in $widget_state as we also need them on submit callbacks, but I don't think that's true for the threshold setiting, so this can probably just directly use the setting?
ok, not just the description, this should be < then IMHO.
Also, this now has to duplicate the condition in two places.
I think we can actually make that part of the first if condition, basicaly:
Then it should be a pretty minimal change, you could even skip the $closed_mode_threshold_setting variable as we only need it once.
this doesn't seem really necessary, the widget check is basically just testing our test helper method and the edit mode summary is already tested elsewhere.
this would then go away, so we'd need a negative check and can limit it to the minimum, checking the summary on that page.
PS: I guess the previous patch changed so much that an interdiff was not useful, but don't forget to post one for these changes.
Comment #30
arpad.rozsa commentedChanged everything you mentioned.
Comment #31
miro_dietikerTested this locally, works like a charm.
I was quickly confused about the setting when i have set it to 6 and edited a node with 10 Paragraphs and was confused the items were closed... But it seems the label / description made sense and i'm just used too much to the old behavior.
Comment #32
berdirLooks good, lets get this in.
Comment #34
miro_dietikerAwesome, so many contributors here! Thx everyone involved. This is in now!