Move Thunder CE display configs into thunder submodule

Created on 23 May 2024, about 1 month ago
Updated 22 June 2024, 3 days ago

1)

I've tried moving them now, but somehow the functional test keeps protesting. I would like to postpone this until after the last (gallery) paragraph is converted to a kernel test.

2)

Make sure the config is usable on a 'bare' Thunder install. Test it.

If necessary, strip down the current custom_elements_test_paragraphs to have only thunder related config. Remove the recently added config/install files for strange fields, from them.

πŸ“Œ Task
Status

Fixed

Version

3.0

Component

Code

Created by

πŸ‡³πŸ‡±Netherlands roderik Amsterdam,NL / Budapest,HU

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @roderik
  • Merge request !70Move display configs to thunder submodule β†’ (Merged) created by roderik
  • Status changed to Fixed 3 days ago
  • πŸ‡³πŸ‡±Netherlands roderik Amsterdam,NL / Budapest,HU

    Minor points to solve (that have been solved):

    • While stumbling through the tests, my local system somehow had extra fields 'image:field_media_image' and 'video:field_media_video_file'. Not sure how that happened, but I've re-tested that they are not present in Thunder, and have removed them again.
    • CustomElementsRenderMarkupTest is now dependent on custom_elements_thunder. custom_elements_thunder is dependent on the test module in this case... cannot officially depend on it.

    More major point (maybe related to the first one): custom_elements_thunder, and the tests for the video field, depended and still depend on a field of type 'video_embed_field' / the video_embed_field module... but Thunder itself has removed this field since 8.x-3.0-beta1. I had no idea about this.

    It likely means that (almost?) noone is interested in this field type / module anymore, and VideoEmbedCeFieldFormatter (that has been added to the main module to support this field) will likely see very few users.

    I have not spent any more time undoing this. I just documented it.

    I also added more info in a README about upgrading, referring to a backward-compatibility module that I made for our internal project, and which I'll upload to the parent issue. (I don't know how big the audience is for it, but probably more than zero people will want to grab that module. And if I don't document the mechanics properly, I'll never remember them.)

    --

    I'm merging this myself, because not important enough / no time for review by others. If there are comments, I weicome them and will address them later.

    Unfortunately I pressed the "merge" button in Gitlab, not in this issue, so the d.o issue reference is now missing :-(

Production build 0.69.0 2024