Add from library should only display allowed paragraph types

Created on 19 March 2020, over 4 years ago
Updated 21 February 2024, 4 months ago

If a paragraph field allows certain paragraph types, including "From library", the list of paragraphs in the dialog to select a reusable paragraph should be filtered to show only the allowed types.

There is validation in place, but it would be a better user experience to only show the paragraphs that can be used.

✨ Feature request
Status

Needs review

Version

1.0

Component

Module: Library

Created by

🇬🇧United Kingdom malcomio

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇬🇧United Kingdom malcomio

    I think that this is happening because the LibraryItem class does not specify any value for default_reference_revision_settings, which means that the DefaultSelection class is used when querying.

    Compare with the Paragraph class, which specifies that the ParagraphSelection EntityReferenceSelection plugin class should be used.

    So I think the next step will be:

    1. define an EntityReferenceSelection plugin for paragraphs library items
    2. update the LibraryItem class to use it
    3. implement the buildEntityQuery method to limit the selection based on the parent, similar to ParagraphsLibraryItemHasAllowedParagraphsTypeConstraintValidator

  • 🇬🇧United Kingdom mjmorley

    I've been working on this to try and get a nice solution, it feels like much better UX.

    I think the best solution here would be to set the target bundles in the form alter from a paragraph. In the $context variable we can get the target bundles of the parent field, and then set them on the #selection_settings of field_reusable_paragraph.

    This does mean in LibraryItemSelection::buildEntityQuery we can't call parent::buildEntityQuery as it will throw errors. For now in the patch I have just copied relevant code from the parent function, but I guess an alternative would be to store the target bundles in a different field and then use them from there. But it seems clunkier to me.

    I have added one patch that has the form_alter built into the paragraphs_library module. I will also add another comment below with a patch that omits the form alter, so people can add their own form alter implementation if they wish.

  • Status changed to Needs review 7 months ago
  • Open in Jenkins → Open on Drupal.org →
    Core: 9.5.x + Environment: PHP 7.4 & MySQL 5.7
    last update 7 months ago
    Composer require-dev failure
  • 🇬🇧United Kingdom mjmorley

    Here is the patch that omits the form_alter

  • Open in Jenkins → Open on Drupal.org →
    Core: 9.5.x + Environment: PHP 7.4 & MySQL 5.7
    last update 7 months ago
    Patch Failed to Apply
  • Open in Jenkins → Open on Drupal.org →
    Core: 9.5.x + Environment: PHP 7.4 & MySQL 5.7
    last update 7 months ago
    Patch Failed to Apply
  • 🇬🇧United Kingdom mjmorley

    The last patches were erroneous so here are the patches again but with the fixes in the entity annotation

  • Open in Jenkins → Open on Drupal.org →
    Core: 9.5.x + Environment: PHP 7.4 & MySQL 5.7
    last update 7 months ago
    Composer require-dev failure
  • Open in Jenkins → Open on Drupal.org →
    Core: 9.5.x + Environment: PHP 7.4 & MySQL 5.7
    last update 7 months ago
    Composer require-dev failure
  • 🇬🇧United Kingdom mjmorley

    Having a nightmare here. The last patches didn't have the new custom entity reference selection on.
    These two patches should.

  • Open in Jenkins → Open on Drupal.org →
    Core: 10.1.x + Environment: PHP 8.1 & MySQL 5.7
    last update 7 months ago
    180 pass
  • Open in Jenkins → Open on Drupal.org →
    Core: 10.1.x + Environment: PHP 8.1 & MySQL 5.7
    last update 7 months ago
    180 pass
  • 🇬🇧United Kingdom malcomio

    @mjmorley I'm confused about the difference between the two patches.

    What's the difference, and which one is your preferred option?
    Also, it's probably easier to create merge request(s)

  • First commit to issue fork.
  • 🇧🇪Belgium DieterHolvoet Brussels

    I rebased the branch against 8.x-1.x and finished the draft implementation in the MR based on the form alter hook by @mjmorley. I also rewrote LibraryItemSelection, now we can keep the parent::buildEntityQuery($match, $match_operator) call and we don't need to query all paragraph ids of a certain type, which could break for sites with a lot of paragraphs. Now this is actually ready for review, without the need for custom form alters.

  • 🇧🇪Belgium DieterHolvoet Brussels

    The MR should be marked as ready, but it seems like I don't have permission to do so.

  • Pipeline finished with Failed
    4 months ago
    Total: 319s
    #100372
  • Pipeline finished with Failed
    4 months ago
    Total: 263s
    #104254
  • Pipeline finished with Failed
    2 months ago
    Total: 449s
    #146879
  • Pipeline finished with Failed
    15 days ago
    Total: 360s
    #196243
Production build 0.69.0 2024