Display usage number of library items

Mind that this is specifically about user awareness when editing.
Simply show a message with count if paragraphs (with our library field) exist with the reference.

For regular usage tab, see:
https://www.drupal.org/project/entity_usage
Let's try to avoid cloning its complexity.

I think this should be an info (or even warning) box at the top of the edit form.

Treat these things as different issues.
A usage count on the overview is helpful.

The item itself each can have a usage tab showing where they are used. The entity usage module is providing that!
https://www.drupal.org/project/entity_usage

We should recommend it at least in documentation! Plz check if the number in the list can also be provided by that module. I'm fine to depend to that module if it makes life significantly easier!

This patch adds "used in' column in admin/content/paragraphs
it appears that we need to use aggregation in view when we want to show the usage count without duplicates.
The problem is that it does't play nice with the paragraphs column in view, I'm getting some sql error.
I will investigate that but the easiest fix will be to remove it...

this patch is btw without the aggregation enabled.

Right the dependency

Sorry, moved to the wrong place.

Probably uploaded wrong patch.

So paragraphs library doesn't depend on collection only on paragraphs. Adding the dependency in collection composer.json wont help and we probably don't want it in paragraphs.

After discussing with @Primsi we wanted to check if this works when adding to collection.

Checking if nothing else is causing the problem

Updated tests. This works locally.

This patch above is for the admin/content/paragraphs listing page.
I removed the column that lists what paragraphs are in library item since it caused error when using aggregate. Is this ok?
Wondering if we need some update hook for indexing library items?

Also do we want to split the displaying usage on edit in another issue?

I removed the column that lists what paragraphs are in library item since it caused error when using aggregate. Is this ok?

I think it's fine for now.

Wondering if we need some update hook for indexing library items?

No need for that, we are still in very early development stage.

Also do we want to split the displaying usage on edit in another issue?

IMHO we can do it here

Display usage on edit with test coverage.

+++ b/modules/paragraphs_library/config/install/views.view.paragraphs_library.yml
@@ -305,22 +355,22 @@ display:
+            path: 'admin/content/entity-usage/paragraphs_library_item/{{ id }}'

So this is not a tab / local task when editing a library item? It's a completely different path.

I'm not so convinced about the grouping.

Since this is a UI change, we want to have screenshots in the issue.

So this is not a tab / local task when editing a library item? It's a completely different path.

Since #4

I think this should be an info (or even warning) box at the top of the edit form.

i added an warning when editing a library item. I can add a link for more usage information here too?

For the listing here are some screenshots and comparison to listing for files.

Library item listing:

Files listing:

And when we click on the link to get more details about usages:
Library item:

Files:

Now by looking at it i see that the breadcrumbs for files usage information page are more useful since you can go back to files listing page. For paragraphs usage information you can only get back to admin/content.

Tested this manually. Looks quite ok. Just two remarks.

"Operations" are usually in the last column of the table.

+++ b/modules/paragraphs_library/paragraphs_library.module
@@ -5,16 +5,64 @@
+function paragraphs_library_count_usage(array $usage_data) {

I would prefix this with _ given that this a utility function.

Yeah, operations need to be last.

I would just name the column "Used" and make it contain the number. I don't like the repetition of "place" / "places".
IMHO these number columns should be right aligned.

Also i really don't like that the summary is removed. We added it as an example to learn how we need to provide and improve the summary. It's very important to collect the different use cases for the collapsed summary and learn from them. It will be a critical issue to readd it.

This covers #35 and #36

I will next create a followup for the summary...

Test fixes.

followup #2858366: Re add summary in admin/content/paragraphs

Let's get that in then. Thanks.