Improve icon selection in paragraphs type form.

Re-rolled patch against latest 8.x-1.x-dev branch.

The patch from #17 misses a lot of code changes from #10, therefore hiding it. The MR diff contains all the code changes from #10 and also fixes the deprecated usage of file_create_url(). You should use the MR and its diff instead.

I rebased branch 2854585-improve-icon-selection with 8.x-1.x and improved the calls to file_create_url() resp. the file_url_generator service.

Just found a small bug with this patch: The following element is added to ParagraphsTypeForm::form() method's form array by this patch:

<?php
$form['static_icon_file']['description'] = [
  '#type' => 'item',
  '#description' => $description,
];

Unfortunately an element with '#type' => 'item' is treated as an input value and thus interferes with the form's actual description form field value.

So my changes add '#input' => FALSE to the new $form['static_icon_file']['description'] element to NOT treat this element as a form value anymore.

I'd really like a way to set icons that don't have to be uploaded and stored in the files directory. It would be ideal to be able to just specify a path to an icon, so it could be included with the theme. I would also like the option of using something like fontawesome to provide icons, so being able to just put in an HTML tag that displays an icon would be great. Then it's on me to make sure that the icon font is included with the admin theme for the sites I build, which I already do and use in other areas.

@teknocat Hi. Did you had a change to test the merge request we've made?
After applying the changes you are able to implement hook_paragraphs_type_static_icon_uri_alter() (in a module or theme) where you can set the icon path to wherever you want. The file could be saved in a module, in the a theme, on an external storage, you name it ...

To use icons provided by fontawesome, you'll nee to override/decorate the ParagraphsTypeListBuilder class and change the way, $row['icon_file']['data'] is build.
Example (not tested):

<?php
      $row['icon_file']['data'] = [
        '#theme' => 'html_tag',
        '#tag' => 'span',
        '#attributes' => [
          'class' => ['fa-' . $entity->id()],
        ]
      ];
?>

This will create a <span> tag using the paragraph type ID as fontawesome class.

@stborchert ah ok! Sorry I don't think I fully understood the possibilities with that merge request.

I'll try that out.

Hello together 👋 What do you think about changing the direction here completely and make use of Drupal's new API for icon management → ?

That would allow themes or modules to define icon packs that can be easily referenced in the Paragraph type configuration like my_icon_pack_name:gallery and can be rendered via PHP or Twig:

PHP:

$build['icon'] = [
   '#type' => 'icon',
   '#pack_id' => 'my_icon_pack_name',
   '#icon_id' => 'gallery',
   '#settings' => [
     'size' => 64,
   ],
 ];

Twig:

{{ icon('my_icon_pack_name', 'gallery', {size: 64}) }}

There is a really cool widget that is available when installing the UI Icons → module that allows you to choose icons via autocomplete:

When storing simple IDs of icons we don't need to care about storing paragraph icons anymore and they can easily survive deployments 😏

@yannickoo

Sounds interesting.

Let's say that I'm creating a new paragraph bundle. Where do I put my icon? In the front-end theme? In the admin theme (That would be a hassle because then I'd need to sub-theme Gin)?

@dalin the cool thing about the new Icon API is that any extension can provide an icon pack so it might be totally enough to have a custom module with an images folder that contains screenshot of your different paragraph types.

You can easily let Drupal scan your folder for any *.png files and tell Drupal how to render your "icons" e.g.

paragraph_icons:
  extractor: path
  config:
    # One icon per listed source, allowed extensions: svg, png, gif, relative to
    # this file or to drupal root if start with a `/`. Remote icons are allowed too
    # Format can be mixed but only one template is possible. If same id (name here)
    # later will override.
    # If an icon does not exist, it will be ignored and a log message will be created.
    sources:
      - images/gallery.png
      - images/another-image.png
      - images/text-paragraph.gif
      - https://www.drupal.org/files/drupal-wordmark.png
  template: '<img src="{{ source }}" width="270" height="160" alt="{{ icon_id }}">'

That would register and provide four different screenshots that could be referenced like paragraph_icons:gallery, paragraph_icons:another-image, paragraph_icons:text-paragraph, paragraph_icons:drupal-wordmark.

No matter if we have nicely prepared SVG files or just screenshots, the new Icon API would allow us to expose them easily and use them by just their ID 🔥