Allow editing label (title) while converting paragraph item to library

Continuing discussion from parent issue.

I had another idea for the approach: would make sense to have a separate widget for the library item reference field (on this from library paragraph type)? This widget would then have the actual reference (maybe hidden field) and a required title field. When saving, we would update the library item title. Not sure about having another widget though in light of future plans for the experimental paragraphs widget.

I don't know what is the right approach to the solution yet, but you are right:
- What we need is a little bit like IEF on the entity reference.
- It's also not only about the title. The can have other metadata fields and putting things into the library should allow to classify it.
- The problem is that this action affects a different non-composite entity. The most simple way would be to leave the editing context (new tab OR lightbox). Opening tabs is obsolete and leaving the context will drop current changes.

One idea is to establish a completely different pattern to entity management:
- Save the current editing context somehow (from temp store, forward revision via workspace, ...)
- Switch to the regular library management entity (create, update) form with some context
- Redirect back to the original host editing on save

The key question here is:
- When should the collection save?
- If the collection item is saved while editing the original host, how do we return into the editing context?

We don't want to reinvent IEF nor Workspace here. I think this is a very challenging architectural question that need to be carefully defined first.

Sry, cross post.

We just improved the default label, see linked issue.

One thing i thought was if we should indicate generated converted Library items somehow.
Currently you could identify them due to their paragraph type label prefix (in case your manually edited labels have a different pattern:

  protected static function buildLabel(ParagraphInterface $paragraph) {
    $summary = $paragraph->getSummary();
    $summary = Unicode::truncate($summary, 50);
    return $paragraph->getParagraphType()->label() . ': ' . $summary;
  }

Alternatively we could assign a simple tag.. But the library has no tag field by default.
Mind that the prepending of the label is redundant. There's a column and an exposed filter for the Paragraph type at admin/content/paragraphs
So maybe instead we should just prepend "Converted: "?

We will redefine this issue to a better integration with Entity Browser that allows easier editing of the label.
While avoiding a hard dependency, we still will ship optional configuration and the view to browse the library.

Working on this. :)

Adding entity browser and view, updated widget if the entity browser module is enabled.

Adding some tests.

Adding test dependency. :)

There is some problem when saving the node that I don't the cause, somehow I cannot save the node after adding an element from library.

Test dependencies are now done as require-dev in the composer.json, then you don't need to wait for a commit on that. And we definitely need a test then for library with entity browser.

Adding to composer file. :)

Removing ctools as is not needed. :)

Adding ctools to library. :)

Just checked that we should include this branch of ctools. :)

+++ b/modules/paragraphs_library/config/optional/views.view.paragraphs_library_browser.yml
@@ -0,0 +1,577 @@
+      filters:
+        label:
+          id: label
+          table: paragraphs_library_item_field_data
+          field: label
+          relationship: none
+          group_type: group
+          admin_label: ''

make sure that you include a filter for default language for both the library and the referenced paragraph. Test by adding a translation to a library item and making sure that it only shows up once in the view.

Also, set the render language to interface language, so if translated, it is displayed in the currently active language.

Thanks to the help of @Berdir I could implement working tests. This should work. :)

+++ b/composer.json
@@ -15,5 +15,6 @@
+    "drupal/content_translation": "1.x-dev"

there's no such thing, content_translation is in core

Oops sorry. :)

Removing debug leftover. :)

Was only able to reproduce that problem on one system. You still had the press button inside the iframe, and then it depending on speed/timing what happened.

Removing that caused other timing issues because the ajax stuff doesn't detect ajax inside the iframe.

Committed.