Extend preprocessor to cope with thunder paragraphs.

- This needs to check it's working with node articles first.

+ case 'field_text':
+ $entity_values->setDataAttribute($field_name, json_encode($entity->{$field_name}->value));

this doe snot make sense to me. it should either just use the plain value without json encding or the ->processed field if markup is there

+ case 'pinterest':
+ $entity_values->setDataAttribute('pinterest_url', $media_entity->field_url->uri);
+ break;

Let's just stay with an uri attribute. Why would we generate a pinterest element with a pinterest_url attribute? The logical name would be URL.

This shows we really need to to do #2994914: Allow modules to control how entity fields are transformed. But let's handle this there and re-factor this later.

>Let's just stay with an uri attribute. Why would we generate a pinterest element with a pinterest_url attribute? The logical name would be URL.

Pinterest was just the example, same for others:

+ case 'twitter':
+ $entity_values->setDataAttribute('twitter_url', $media_entity->field_url->uri);
+ break;

How about instagram, isn't that included?

I figured that this uses related URLs for image media, but it should be absolute so that the custom element markup is re-usable. Attaching a new patch.

Still we need to address #2994914: Allow modules to control how entity fields are transformed for being able to implement this properly.

#2994914: Allow modules to control how entity fields are transformed is fixed in 2.x now. It has this code refacored as ThunderParagraphsCustomElementsProcessor - however that's a WIP and needs to be completely refactored still.

Todos to make this work properly:
- For each media bundle in thunder, add a MediaEntity{ bundle}Processor. The processor should support media entities and control how they are rendered.
- Since we know it's thunder we can assume the thunder fields and add an optimized custom element tag for the media entity.
- In the end, we should have a wrapping custom element tag per paragraph that contains slot elements as suiting.

Patch with default processor for thunder gallery.
Wrong file. Correct file in comment #11

Patch with default processor for thunder gallery.

New patch with --staged diff for added files.

+  public function addtoElement($data, CustomElement $element, $viewMode) {
+    assert($data instanceof MediaInterface);
+    $paragraph = $data;

since it's working for paragraphs, $data must be the paragraph entity and the assert wrong?

* Default processor for media field items.
+ */
+class MediaEntityGalleryProcessor implements CustomElementProcessorInterface {
+
+ use CustomElementGeneratorTrait;
+

This says it's handling media entities, but then it handles the paragraph type 'gallery'. Mismatch.

+ use CustomElementGeneratorTrait;
not used?

Why has the gallery a separate class and the other paragraphs not?
I think it would be cleanest to have a single class per paragraph type / media entity bundle so it can be easily extended like that and it's easy to overrride the output for a single paragraph only.

Here is a patch with all thunder paragraphs in separate class.
Also removed unused trait (it is not used since nested element "lupus-" tag and not a custom_elements tag).
Refactored to use Paragraph instead of MediaEntity.

thx, works as it should! Committed.