Layout and styles overview page

This is my progress thus far.

Added functions to get from grid layouts to entities in which those layouts are being used.

Deleted all Paragraph entities stuff. Added functions for styles.

This is an admin UI feature, please provide a screenshot of the UI.

+++ b/src/Controller/OverviewController.php
@@ -0,0 +1,229 @@
+  public function getParagraphsTypesLayoutsEnabled() {
...
+  public function getParagraphsTypesStyleGroupsUsed() {

I think we should generalise this method to getParagraphTypesWithPlugin($plugin_id)

Work in progress. I still need to add the right classes to the table entries.

Work in progress. The styles overview is now working nicely. I will work on refactoring the grid layout overview code into the working styles code now.

@Ginovski
I will make the generalization changes later. Everything #2860830: Add group filter in the layout and style overview page wants is already in this patch, however. I am not going to split it anymore. That would mean far too much useless refactoring.

Yeah, let's try to avoid changing the goal. Just complete the current scope properly.
Basic test coverage is still a must to get this in. To speedup, we could do JS tests in a follow-up.

1. +++ b/js/overview.js
   @@ -0,0 +1,74 @@
   +      function filterSensorList() {
   ...
   +        $rows.each(showSensorRow);
   

   Eliminate the term Sensor.

2. +++ b/paragraphs_collection.routing.yml
   @@ -0,0 +1,18 @@
   +    _permission: 'administer paragraphs types' # @todo Change this?
   ...
   +    _permission: 'administer paragraphs types' # @todo Change this?
   

   IMHO these permissions are pretty fine.

The styles and the layouts overview now both look nice and the search is functional everywhere.

Moving on to writing the tests.

Fixed wrong labeling in the layouts overview.

1. +++ b/src/Controller/OverviewController.php
   @@ -0,0 +1,389 @@
   +   * ['<plugin ID>' => ['<Paragraphs Type ID>' => <item(s) (plugin-specific)>]]
   

   Better make an example.

2. +++ b/src/Controller/OverviewController.php
   @@ -0,0 +1,389 @@
   +   * Lists Paragraphs Types with discoverable items they allow for a plugin.
   ...
   +   *   Discoverable items keyed by by Paragraphs Type IDs. The form of the items
   ...
   +  public function getItemsPerParagraphsTypesPerPlugin($plugin_id) {
   

   What are discoverable items?

3. +++ b/src/Controller/OverviewController.php
   @@ -0,0 +1,389 @@
   +  public function layouts() {
   +    return self::content('grid_layout');
   

   This method calls a different method that delivers two pretty much different things based on a string argument.
   Instead, the called method should deliver what is uniform and the caller should do the specific things.

4. +++ b/src/Controller/OverviewController.php
   @@ -0,0 +1,389 @@
   +    switch ($plugin_id) {
   ...
   +    switch ($plugin_id) {
   ...
   +      switch ($plugin_id) {
   ...
   +      switch ($plugin_id) {
   ...
   +    switch ($plugin_id) {
   ...
   +    switch ($plugin_id) {
   

   All these switches should not exist.

   Do not create methods that do two different things based on an argument.
   Instead, put parts that are similar code-wise and outsource them in a method you call.

Added a test. Removed all the switch statements and broke up both affected methods into two methods each.

1. --- /dev/null
   +++ b/css/overview.css
   
   @@ -0,0 +1,10 @@
   diff --git a/js/overview.js b/js/overview.js
   

   Both this files are actually used in admin context, so I would do overview.admin.js

2. +++ b/js/overview.js
   @@ -0,0 +1,67 @@
   +      // var $selects = $
   

   Commented out code.

3. +++ b/src/Controller/OverviewController.php
   @@ -0,0 +1,427 @@
   +   * The first level is keyed by Paragraphs Type IDs. The second-level keys have
   +   * no meaning. The second-level values are machine names of the grid layouts
   +   * that the first-level key Paragraphs Type has enabled.
   +   * Exception: An empty second-level array means that all layouts are enabled
   +   * for that Paragraphs Type.
   

   IMHO we could just add an example and shorten this text.

4. +++ b/src/Controller/OverviewController.php
   @@ -0,0 +1,427 @@
   +  protected $gridLayoutsOrderedByParagraphsTypes;
   ...
   +  protected $styleGroupsOrderedByParagraphsTypes;
   

   Ordered or grouped?

5. +++ b/src/Controller/OverviewController.php
   @@ -0,0 +1,427 @@
   +   *   A nested array. The first level is keyed by Paragraphs Type IDs. The
   +   *   second-level keys have no meaning. The second-level values are machine
   +   *   names of the grid layouts that the first-level key Paragraphs Type has
   +   *   enabled.
   

   Same here, an example would be helpful.

6. +++ b/src/Controller/OverviewController.php
   @@ -0,0 +1,427 @@
   +    $paragraph_type_ids = \Drupal::entityQuery('paragraphs_type')->execute();
   

   I think ParagraphsType::loadMultiple() should do it here.

7. +++ b/src/Controller/OverviewController.php
   @@ -0,0 +1,427 @@
   +      $paragraphs_type_ids = $this->getParagraphsTypesPerLayout($layout_id);
   ...
   +      foreach ($paragraphs_type_ids as $paragraphs_type_id) {
   +        $paragraphs_type = ParagraphsType::load($paragraphs_type_id);
   

   Maybe I am not getting something but, do we need the list built by get*OrderedBy... elsewhere too? If it's only here shouldn't we rather have a list of behavior ids as keys and paragraph types that use them as values? If that's the case we could get rid of a some of the above methods. Also if we load multiple and store them there I think we wont need to load them separately here.

8. +++ b/src/Controller/OverviewController.php
   @@ -0,0 +1,427 @@
   +        if($paragraphs_type_link_list != []) {
   +          $paragraphs_type_link_list[] = ['#plain_text' => ', '];
   +        }
   

   Just implode the list where you use it.

9. +++ b/src/Controller/OverviewController.php
   @@ -0,0 +1,427 @@
   +        '#type' => 'markup',
   ...
   +        '#prefix' => '<span class="table-filter-text-source">',
   +        '#suffix' => '</span>',
   

   I think you could use container instead of markup.

10. +++ b/src/Controller/OverviewController.php
    @@ -0,0 +1,427 @@
    +        '#markup' => Html::escape($layout['title']),
    

    Not sure if this needs escaping, doesn't twig do that for us already?

11. +++ b/src/Controller/OverviewController.php
    @@ -0,0 +1,427 @@
    +        '#title' => $this->t($layout['description']) ?: $this->t('Details'),
    

    Description should be translatable elsewhere. If it's not an issue should be opened. Also Details should probably be "Description not available" imho.

12. +++ b/src/Controller/OverviewController.php
    @@ -0,0 +1,427 @@
    +        '#type' => 'item',
    +        '#title' => $this->t('ID'),
    +        '#markup' => '<span class="table-filter-text-source">'. Html::escape($layout_id) . '</span>',
    +        '#prefix' => '<div class="container-inline">',
    +        '#suffix' => '</div>',
    

    Same remark about escaping and use of container as above

13. +++ b/src/Controller/OverviewController.php
    @@ -0,0 +1,427 @@
    +    $filters = [
    +      '#type' => 'fieldset',
    +      '#attributes' => [
    +        'class' => ['table-filter', 'js-show', 'form--inline'],
    +        'data-table' => '.paragraphs-collection-overview-table',
    +      ],
    +      '#weight' => -10,
    

    If that's meant to be above, let's move filters to the top of this method.

Given that the styles method is quite similar same remarks as for the grid one apply.

8. That wouldn't work. I need the '#plain_text' keys for it to be rendered correctly inside the table.

10.'#markup' always needs escaping. However, it's no longer an issue here, as I removed all the occurrences from the current patch.

11. I have created a new issue to make the descriptions (and titles) translatable: #2867856: Titles and descriptions of grid layouts and styles are not being translated

I implemented all the other suggestions.

Re-roll.

Adjusted the test to accommodate a change to the present grid layouts.

Overlooked "To speedup, we could do JS tests in a follow-up.", re-opening. Please close when the follow up is created

Looks pretty nice. Committed as is.

Back to needs-work to discuss the missing steps and create all follow-ups. Then plz close.

Follow-up: If i limit the grid paragraph type in paragraphs_collection_demo to two layouts, all others disappear. Layouts without usage should also be listed. Same for the group.

Follow-up: Should we remove the term "Grid" completely from the layout plugin? Can we really only handle grids? Not yet sure.
If not, i think we should be clear that the tab list Grid layouts, not layouts in general.

We need a meta about evolving the management UI of layout and grid. All related features should be grouped there. For instance, also the creating of new groups through the UI.