Improve Paragraph collapsed/closed summary

Just identified the "Warning this content needs save".
Should be a separate issue to make sure it's yellow and catches the users' eye. :-)

The screen shows more space below "Type: Nested paragraphs" than we currently have. Is there an empty element or accidental space added?

+++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
@@ -1146,4 +1152,31 @@ class InlineParagraphsWidget extends WidgetBase {
+    return strip_tags($collapsed_summary_text);

The code should still cutoff after a limited amount of text IMHO to some large value. Currently we would output here large full text bodies and then set them to a single line overflow hidden...

Not sure if we can always add this on closed items as long as it adds a full new line. We might want to have an optional setting "Show closed summary".
If we can display it after the type, i see no regression in space and we could always output it.

Since this is a great improvement and we are not adding any new API and contracts, we can commit this early. Flexibility to support more field types, ... can always be added later.

That's great progress. We should discuss the approach with some UX people next week at DDD.
I think "Text: " is superfluous. Even if it's the field label, i think that the characters are so much limited, the value only is totally OK.
- How does it look if a nested level is collapsed?
- What if the type label is longer than the indentation?

Some first code feedback:

1. +++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
   @@ -1146,4 +1154,43 @@ class InlineParagraphsWidget extends WidgetBase {
   +  public function addCollapsedSummary(paragraphs\Entity\Paragraph $paragraphs_entity, $collapsed_summary_text = FALSE) {
   ...
   +      if ($collapsed_summary_text) {
   +        $collapsed_summary_text .= ', ';
   

   It's strange you pass in $collapsed_summary_text as boolean and then you do string concatenation on it. Anyway, it is never passed in.

2. +++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
   @@ -1146,4 +1154,43 @@ class InlineParagraphsWidget extends WidgetBase {
   +    foreach ($paragraphs_entity->getFieldDefinitions() as $key => $value) {
   

   What is the field sequence? I think it should be the default formatter field sequence.

3. +++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
   @@ -1146,4 +1154,43 @@ class InlineParagraphsWidget extends WidgetBase {
   +      if ($value->getType() == 'image') {
   

   We should also support major us cases through entity references.
   Also thought about a tiny image, but not sure if it really helps at that tiny size.

4. +++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
   @@ -1146,4 +1154,43 @@ class InlineParagraphsWidget extends WidgetBase {
   +          $text = strip_tags(substr($text, 0, 50)) . '...';
   

   There is a special UTF8 character for "..." we should use.

5. +++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
   @@ -1146,4 +1154,43 @@ class InlineParagraphsWidget extends WidgetBase {
   +          $collapsed_summary_text .= $this->addCollapsedSummary($paragraphs_entity->get($key)->entity);
   

   Caution, this can result in a recursion. Especially once we add support for entity_references.

BTW there is just another issue that adds a collapsed summary by looking for a "title" field. #2749257: Show a paragraph title if there's a field with a title
Since we have dropped the concept of a label for regular paragraphs, this seems not to fit our approach.

Note that
- I see the value of indentation for optical alignment of the summary start.
- I still would like to see real cases without any horizontal alignment. Google mail also decides against it (subject + body one line summary) since the subject length is even more variable than here.

Adding my gmail origin screenshot again here:

So I had rather long talk with @yongt9412 about other tickets, including this one. We came to some conclusions:

1. a gmail like row is desired
2. the preview area (orange, Plugin defined area) should expand as much as possible. (not exact in the screen)
3. it would be nice to have a plugin like system for each field type, to have a "preview" renderer if the field is not empty (orange)
4. the actual area to drag, click and expand (green area) needs to be quite big, to be usable. not only the draggable icon!

to 3.
Image you would need to implement a ParagraphFieldPreview. This allows every field type to define, how it will be broken down to one single line.
Text: formated or not
(image) File: the file path, or file name, file size, file type
Color Widget: the hex/hsl code AND a colored box
Paragraphs: titles of nested paragraphs inside it
and so on... A couple of core field types can be provided by paragraphs as well.
If there is no such PragraphsFieldPreview defined, it will fallback to some existing previews.

adding to my last comment
5. the Edit/delete button does not to be a split button at all if 4. will be implemented, we only need the remove button there.

To sum it up: the interactions with one single row would be
- resort on drag and hold (green)
- expand/collapse on click on the draggable area (blue)
- remove item by click on the button (button)

I agree with #18. One text field should be sufficient for collapsed paragraphs. There could be a setting to pick the field.

There is already the option to show previews instead of collapsed paragraphs for users who want to set up something more elaborate. If #2684187: Allow existing view modes to be used for the editor preview gets done they'll be able to set up a view mode specifically for that purpose too.

IMO the UI should follow Drupal standards and other common examples as much as possible. Inline Entity Form provides an edit button for its collapsed entities in multi valued fields. That makes it obvious how the item can be edited and accessible. One of the reasons that the area to click and drag items is limited to the icon in the side is that these icons represent the possibility of horizontal movement as well as vertical (the arrows point in 4 directions) which comes into play when they appear in, for example, field groups that can be nested at various levels. That may not apply to collapsed paragraphs but it's still a standard UI element with a well-defined behaviour. You can see them at admin/structure/block too, for example.

Didn't change much but tried to address a few of the comments:

• The indentation for the summary line is smaller, leaving more room for the summary. If the type label is too long it will be cut off with ellipsis.
• The triple dots have been replaced with ellipsis.
• $collapsed_summary_text is no longer a parameter.
• The labels have been removed from the summary line.
• The tests should pass.

About what I said in #21 I tried to add a setting to let the user choose a field to show in the summary but it wouldn't be able to be a widget setting because the type of paragraph won't be known at that point. I thought of making it a setting on the paragraph bundles too but that setting screen is something you usually only see once on the first step of creating the bundle and I didn't think trying to get people to go back there after they add fields would be user friendly.

Awesome stuff. I will need some time to play with this. You're challenging me in convincing my finger not to be too committy! ;-)

I'm promoting it to consider it prior to next release.

For me, the paragraph types are cutoff way too early. At 1024, i can only see 5 characters of the paragraph type.
And with a mobile like browser width, it can happen that there is no type information at all.
This is not satisfying. I guess we need additional rules for lower widths, such as a fixed min width of the type info.

With the different visual indication, i now even consider removing "Type:" completely as a paragraph type prefix. At least when collapsed. It steals too much space.

I don't like that the summary indicates not if the content is clipped.
Also, the summary doesn't start at a consistent horizontal indentation - it looks misaligned to me.
I played with flex and overflow definitions and with setting flex-base to the summary also it was possible to have ellipsis also on summary.

Follow-up: I also have seen again the "Warning" on collapsing a para, that is still not yellow indicated, confusing me as it looks more like text that contains to the content and doesn't read like a message.

But yeah, i think it's a great improvement.

+++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
@@ -1189,4 +1197,42 @@ class InlineParagraphsWidget extends WidgetBase {
+      if ($field_type = $value->getType() == 'entity_reference_revisions') {

I think we should add support for entity references also, displaying the entity label. But if we add this, we need to prevent infinite recursion. Can be a follow-up in general.

How about cross browser testing? Do we need to spend some time in review?

Ah, and i'm getting this with some stale data:

Notice: Trying to get property of non-object in Drupal\paragraphs\Plugin\Field\FieldWidget\InlineParagraphsWidget->addCollapsedSummary() (line 1216 of modules/paragraphs/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php).

So yeah, data is stale, like i have uninstalled paragraph types... But i guess the notice can be easily avoided.

Okey, first thing this is very ugly stuff ;) And its ugly because of two things:

• the drag/drop table ordering control - its not possible to apply text-overflow ellipsis because of table implementation. Actually i found one way with cell position absolute approach and it works by default, but when you turn on manual ordering of rows it completely breaks the thing
• dropbutton control - using position absolute for styling really make things hard when you want to have button inline with other stuff

So what is done then? Here are the stuff that is done in new patch

• CSS code is cleaned, lots of rules are removed, other rules are optimized and some bugs are fixed
• Added color-warning class for all em warning messages.
• Ellipses for text overflow is not possible but i manage to add fade out effect - check the screenshots. It looks cool and there is clear indication that there is more hidden text there. However we are introducing new visual pattern here so this need to be checked and verified by others.
• Tested for now in Chrome and FF, and fully tested responsive behavior. If somebody can check IE10+ and Safari that would be cool. Also, because of lot of CSS cleanup more testing of various cases would be cool - i tried to cover as much as possible but one additional check from somebody else would be nice.

Here are the screenshots:

Closed desktop

Closed mobile

Open desktop

Open mobile

> I think we should also add here text-align: center to make the star be in a better position like:

Hmmm we are losing some vertical space there and also if everything is aligned horizontally then it make sense to try to put * also in the same line. Here it is how it looks with new patch

> Also in the previous screenshot the fade out effect doesn't match the background color.

New patch fixes this so hover and dropped background colors are followed now.

> IMHO removing it and adding the summary without the ellipsis effect is clear enough.

I don't have a stand on this basically, OK for me also to drop fade out if other agrees. But i would like somebody else to give opinion on this from UX perspective.
Also adding ellipsis is almost impossible with current Drupal core drag-able interfaces but we wanted multiple time in the past and now to add this indication to end user somehow so it make sense to think little bit more about this before deciding what to do finally.

> Btw also the css indentation should be just 2 spaces.

Correct here is separate patch, just indentation changes so no interdiff needed.

> I've been checking more and I like it more in this way:

Not sure what is the better way, it seems more logical to me that its first because its easier to get notice like that. On the other hand block admin drag and drop page is putting * on the end of a label, something we can not do that easily here. So i guess your suggestion also make sense.

Ok make sense, do you wanna role a new patch with this?

That looks very promising.
What's this asterisk (*) for per paragraph in #40 screenshot?

Need to check this also on low width devices. Screenshots would also help.

I checked a text field with multiple values.

Only lines that changed position get a "*" and also they are with yellow background.
Your screen above shows all lines - also non-yellow ones - with an asterisk.

Is this a general problem?

Yeah i see, only one row remains yellow. So this could be fine.

I installed the patch and tested it in Chrome and FF. The improvements are awesome and work for me.

One suggestion: We use https://github.com/AmazeeLabs/paragraphs_collapsible in one of our projects and i like ease of use of their js solution to collapse and expand paragraphs. The advantage i see over the standard solution is, that it is possible to expand/collapse paragraphs even when creating new nodes. With the solution here its is not possible to collapse a paragraph while creating it.
But yes, basically that has nothing to do with this issue.

@megadesk3000 There is an issue about adding JS based collapse in Paragraphs and it explains the process of adopting this and reasons for our decision here. This is a first step in a long process - see also other META issues and it's important that we move steps forward that keep complexity low, well test covered and being perfectly aligned with the long term direction.

Almost committed, but checked #30 comment again with code from then. The logic is still same.

+++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
@@ -1191,4 +1199,42 @@ class InlineParagraphsWidget extends WidgetBase {
+    foreach ($paragraphs_entity->getFieldDefinitions() as $key => $value) {
...
+      if ($value->getType() == 'image') {
+        $text = $paragraphs_entity->get($key)->entity->filename->value;

A paragraphs field could have an image that has no file attached to it. So this needs better checking for empty cases to avoid notices.

+++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
@@ -1206,4 +1214,57 @@ class InlineParagraphsWidget extends WidgetBase {
+      if ($collapsed_summary_text) {
+        $collapsed_summary_text .= ', ';
+      }
...
+            if ($collapsed_summary_text) {
+              $collapsed_summary_text .= ', ';
+            }
+            $collapsed_summary_text .= $text;
...
+        $collapsed_summary_text .= $text;
...
+    return strip_tags($collapsed_summary_text);

Make this an array, always append and implode with comma at the end.

So, let's take this one step further. ;-)

Committed and thus ready for big party for the weekend! :-D :-D
Thank you all for this awesome work. For now it remains hidden (because you need to switch to closed paragraph widget) but it will soon make people happy when we allow collapsing in more cases.

I have the feeling that the grey is a bit too low and leading to contrast trouble for some screens and people. So we should make it a bit more dark.

OK, done.