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.

Comments

jstoller created an issue. See original summary.

jstoller’s picture

Status: Active » Needs review
StatusFileSize
new1.98 KB

I think this should do it.

jstoller’s picture

Title: Add option to expand paragraph item when there is only one » Display paragraphs as open when item count is low
Issue summary: View changes
StatusFileSize
new2.83 KB

It 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.

jstoller’s picture

StatusFileSize
new3.71 KB

Fixed it so you can still collapse the paragraphs items after the initial page load, even if there are less items than the override limit.

jstoller’s picture

StatusFileSize
new3.84 KB

Cleaned up implementation. I think I'm done now. :-)

jstoller’s picture

StatusFileSize
new3.89 KB

While 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...

<?php
/**
 * Implements hook_field_widget_properties_alter().
 */
function paragraphs_defaults_field_widget_properties_alter(&$widget, $context) {
  // Force default paragraphs field widgets to display as open on new entities.
  if ($widget['type'] == 'paragraphs_embed') {
    $entity_info = entity_get_info($context['entity_type']);
    if (empty($context['entity']->$entity_info['entity keys']['id'])) {
      $widget['paragraphs_edit_mode_open'] = TRUE;
    }
  }
}

...which should help with issues like #2624596: Don't collapse default paragraphs items on new nodes.

amoebanath’s picture

Status: Needs review » Reviewed & tested by the community
StatusFileSize
new812 bytes
new3.89 KB

Works beautifully.
Made a quick spelling change though :)

sachbearbeiter’s picture

Great - thanks a lot ...

jstoller’s picture

@jeroen.b: Just a friendly request for comment, if you don't feel this is ready to commit.

  • jeroen.b committed 98679f5 on 7.x-1.x authored by jstoller
    Issue #2577229 by jstoller, amoebanath: Display paragraphs as open when...
jeroen.b’s picture

Status: Reviewed & tested by the community » Fixed

Thanks guys, this is great. Pushed!

miro_dietiker’s picture

Version: 7.x-1.x-dev » 8.x-1.x-dev
Status: Fixed » Patch (to be ported)
Issue tags: +Usability

Oh, new features. Needs a port. :-)

tassilogroeper’s picture

Issue tags: +DevDaysMilan
bonrita’s picture

Ported the drupal 7 functionality to drupal 8. Needs review.

bonrita’s picture

Status: Patch (to be ported) » Needs review

Status: Needs review » Needs work

The last submitted patch, 14: paragraphs-open-when-item-count-is-low-2577229-14-D8.patch, failed testing.

seanb’s picture

  1. +++ b/config/schema/paragraphs_type.schema.yml
    @@ -66,6 +66,8 @@ field.widget.settings.entity_reference_paragraphs:
    +    default_edit_mode_override:
    
    @@ -82,3 +84,5 @@ field.widget.settings.paragraphs:
    +    default_edit_mode_override:
    
    +++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
    @@ -38,6 +38,11 @@ use Symfony\Component\Validator\ConstraintViolationInterface;
    +  const PARAGRAPHS_DEFAULT_EDIT_MODE_OVERRIDE = 1;
    

    This name does not really reflect what it does? It store a int, but it reads as if it should store a bool.

  2. +++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
    @@ -126,6 +132,26 @@ class InlineParagraphsWidget extends WidgetBase {
    +      '#attributes' => array(
    +        'field-name' => 'edit_mode',
    +      )
    

    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?

johnchque’s picture

Status: Needs work » Needs review
StatusFileSize
new833 bytes

This 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. :)

Status: Needs review » Needs work

The last submitted patch, 18: display_paragraphs_as-2577229-18.patch, failed testing.

seanb’s picture

Maybe changing the default to empty or zero would already do the trick in regards to the default behaviour?

jstoller’s picture

@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:

+    // Force open when items are less.
+    if ($widget_state['items_count'] <= $default_edit_mode_override && $default_edit_mode <> 'open') {
+      $default_edit_mode = 'open';
+    }

to:

+    // Force open when number of items are less than the override limit.
+    $default_edit_mode = ($widget_state['items_count'] < $default_edit_mode_override) ? 'open' : $default_edit_mode;

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.

seanb’s picture

I 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.

jstoller’s picture

I 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:

Force items to display as "Open" when there are less then ____ items.

to:

Force items to display as "Open" when there ____ items, or less.

If you make that change in D8 then I'd probably want to backport it to D7, for consistency.

ginovski’s picture

Status: Needs work » Needs review
StatusFileSize
new11.24 KB

1. Added '_limit' to the variables.
2. Changed the default limit to 0.
3. Added tests.

kristofferwiklund’s picture

Status: Needs review » Reviewed & tested by the community
StatusFileSize
new11.64 KB
new5.34 KB

I have re-rolled this for latest 8.x-1.x version.

And it works nice.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 25: display_paragraphs_as-2577229-25.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

miro_dietiker’s picture

Priority: Normal » Major

We 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:

  1. +++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
    @@ -128,8 +134,28 @@ class InlineParagraphsWidget extends WidgetBase {
    +      '#description' => $this->t('Number of items considered to live paragraphs open e.g if host has 1 paragraph item. Live that paragraph open.'),
    

    live = leave?

  2. +++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
    @@ -215,6 +241,7 @@ class InlineParagraphsWidget extends WidgetBase {
    +    $summary[] = $this->t('Number of items to display as "Open" : @mode_limit', ['@mode_limit' => $this->getSetting('default_edit_mode_override_limit')]);
    

    A very long text for a summary.

  3. +++ b/src/Plugin/Field/FieldWidget/ParagraphsWidget.php
    @@ -49,6 +49,11 @@ class ParagraphsWidget extends WidgetBase {
    +  const PARAGRAPHS_DEFAULT_EDIT_MODE_OVERRIDE_LIMIT = 0;
    

    I don't think we need a const for undefined / default.

  4. +++ b/src/Plugin/Field/FieldWidget/ParagraphsWidget.php
    @@ -179,6 +188,23 @@ class ParagraphsWidget extends WidgetBase {
    +      '#title' => $this->t('Edit mode override limit'),
    

    Maybe "closed mode threshold" would be easier to understand. But it would change the logic.

  5. +++ b/src/Plugin/Field/FieldWidget/ParagraphsWidget.php
    @@ -179,6 +188,23 @@ class ParagraphsWidget extends WidgetBase {
    +      '#max' => 99,
    

    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. :-)

arpad.rozsa’s picture

Status: Needs work » Needs review
StatusFileSize
new10 KB

Changed the previous patch, so that it works with the newest state of the branch, including the previously introduced related setting "Closed, show nested".

berdir’s picture

Status: Needs review » Needs work
  1. +++ b/src/Plugin/Field/FieldWidget/ParagraphsWidget.php
    @@ -186,6 +187,19 @@ class ParagraphsWidget extends WidgetBase {
    +      '#title' => $this->t('Closed mode threshold'),
    +      '#default_value' => $this->getSetting('closed_mode_threshold'),
    +      '#description' => $this->t('Number of items considered to leave paragraphs open e.g the threshold is 3, if a paragraph has 3 items or less, leave it open.'),
    +      '#min' => 0,
    

    By changing the concept to a threshold, the exact value should then already switch to closed.

    Maybe it's just the description that's outdated.

  2. +++ b/src/Plugin/Field/FieldWidget/ParagraphsWidget.php
    @@ -311,6 +325,9 @@ class ParagraphsWidget extends WidgetBase {
    +    if ($this->getSetting('edit_mode') == 'closed' || $this->getSetting('edit_mode') == 'closed_expand_nested') {
    +      $summary[] = $this->t('Closed mode threshold: @mode_limit', ['@mode_limit' => $this->getSetting('closed_mode_threshold')]);
    +    }
    

    I guess we should only show this if it's non-zero?

  3. +++ b/src/Plugin/Field/FieldWidget/ParagraphsWidget.php
    @@ -352,6 +369,7 @@ class ParagraphsWidget extends WidgetBase {
         $closed_mode_setting = isset($widget_state['closed_mode']) ? $widget_state['closed_mode'] : $this->getSetting('closed_mode');
         $autocollapse_setting = isset($widget_state['autocollapse']) ? $widget_state['autocollapse'] : $this->getSetting('autocollapse');
    +    $closed_mode_threshold_setting = isset($widget_state['closed_mode_threshold']) ? $widget_state['closed_mode_threshold'] : $this->getSetting('closed_mode_threshold');
     
    

    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?

  4. +++ b/src/Plugin/Field/FieldWidget/ParagraphsWidget.php
    @@ -369,15 +387,28 @@ class ParagraphsWidget extends WidgetBase {
    +          // Force the paragraph to be open, if it contains less than or equal
    +          // items as the threshold.
    +          if ($widget_state['items_count'] <= $closed_mode_threshold_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:

    
    if (open || items_count_check) {
    ...
    }
    elseif (closed)
    
    

    Then it should be a pretty minimal change, you could even skip the $closed_mode_threshold_setting variable as we only need it once.

  5. +++ b/tests/src/Functional/ParagraphsExperimentalWidgetButtonsTest.php
    @@ -349,6 +349,149 @@ class ParagraphsExperimentalWidgetButtonsTest extends BrowserTestBase {
    +    // Check that the paragraphs field uses the experimental widget on the
    +    // container_paragraph paragraph type.
    +    $this->drupalGet('admin/structure/paragraphs_type/container_paragraph/form-display');
    +    $option = $this->assertSession()->optionExists('fields[field_paragraphs][type]', 'paragraphs');
    +    $this->assertTrue($option->isSelected());
    +
    +    // Check if the edit mode is set to "Closed".
    +    $this->assertSession()->pageTextContains('Edit mode: Closed');
    

    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.

  6. +++ b/tests/src/Functional/ParagraphsExperimentalWidgetButtonsTest.php
    @@ -349,6 +349,149 @@ class ParagraphsExperimentalWidgetButtonsTest extends BrowserTestBase {
    +    $this->drupalGet('admin/structure/types/manage/paragraphed_test/form-display');
    +    $option = $this->assertSession()->optionExists('fields[field_paragraphs][type]', 'paragraphs');
    +    $this->assertTrue($option->isSelected());
    +
    +    // Check if the edit mode is set to "Closed" and the threshold to 0.
    +    $this->assertSession()->pageTextContains('Edit mode: Closed');
    +    $this->assertSession()->pageTextContains('Closed mode threshold: 0');
    

    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.

arpad.rozsa’s picture

Status: Needs work » Needs review
StatusFileSize
new8.1 KB
new6.56 KB

Changed everything you mentioned.

miro_dietiker’s picture

Tested 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.

berdir’s picture

Status: Needs review » Reviewed & tested by the community

Looks good, lets get this in.

miro_dietiker’s picture

Status: Reviewed & tested by the community » Fixed

Awesome, so many contributors here! Thx everyone involved. This is in now!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.