`ContentTemplate` config entities must support exporting images in `StaticPropSource`s that reference media items: `File` content entity dependency, base64-encoded upon export

I wrote this issue summary together with @f.mazeikis 🤓

.

@mstrelan pointed out we have the 8.4 polyfill in 11.2 but not in 11.1

#6: That should be fine, because XB bumped its requirement to 11.2 in #3492722: Update XB to require Drupal 11.2? That's what's in 0.5.0-alpha1, so <0.5 is for Drupal <11.2, >=0.5 is for Drupal >=11.2

That was pretty fast! Reviewing… 🤓

We can work around this in beta by uploading images to media library and manually referencing them in component code. This is obviously not great and doesn't allow components to be moved from environment to another so we definitely still need this. Just trying to avoid rushing this before the beta.

Re polyfill:
Regardless of core version no reason XB couldn't add it as a dep, just give it a loose constraint so it doesn't conflict with core.

Looking promising!

1. This needs to have preliminary internal HTTP API support. "preliminary", because it might be imperfect, and that's fine. But we need to have the FE folks unblocked to build the entire feature; we can then still refine it later 👍
2. That MUST come with updated test coverage in \Drupal\Tests\experience_builder\Functional\XbConfigEntityHttpApiTest::testJavaScriptComponent()
3. Some missing test coverage to ensure that saved config entities in config entity storage do not actually contain these base64 blobs

Great work @f.mazeikis - did another review and added some comments/observations

🏓 Responded to @f.mazeikis' most pressing question; didn't do a full review, but … the scope here is now no longer so narrow, but generic, thanks to #3524130: Define JSON Schema $refs for linking/embedding videos and linking documents + #3534601: Add a Video prop type to the Code Component editor; requires adding `file` as default `StaticPropSource`, `FileWidget` support and various infrastructure improvements.

I'll review tomorrow — it's possible @larowlan will beat me to it, so not yet self-assigning.

Thanks for the excellent docs additions 👏, that made it 10x easier to review this! 🥳

(Still in the process of reviewing.)

Created #3538711: [PP-1] Add support for example images for Code Components' image props for the actual feature that this is intended to unblock.

Finished reviewing the MR. Epic work! 🤩 Confirmed that it meets all 5 goals outlined in the issue summary! 👍

My commits/self-addressed:

• Comment nits.
• A fix for using root-relative URLs for the example images rather than absolute ones

Remaining feedback:

• Spotted a few bits of missing test coverage.
• Everywhere this MR uses "default", it should use "example", because of #3514672: [Needs design] DX & authoring experience: support `default` in addition to `examples[0]`, enables updating a component input across all existing instances. (Yes, I know this is how we've been talking about it for a while, but that doesn't mean we shouldn't realize our mistake and get better. Not your fault, but this MR understandably introduces a lot more uses of this terminology! So: time to rectify it now.)
• Concern: manually creating a File entity in a test — what am I missing?
• Major concern: the way this paves the path for #3538711: [PP-1] Add support for example images for Code Components' image props is nice but AFAICT insecure 😅 — I think it actually might be better to REMOVE this bit from the MR, because of the security aspects, but also because it's not in scope for this issue (for that very reason).
• In fact, a similar concern exists when just using encoded_files itself; a config export+import could become an attack vector. See https://git.drupalcode.org/project/experience_builder/-/merge_requests/1... + https://git.drupalcode.org/project/experience_builder/-/merge_requests/1... + https://git.drupalcode.org/project/experience_builder/-/merge_requests/1...

Thanks, @larowlan for creating #3537728: [PP-1] Consider adding ramsey/uuid for hash-based UUID (v5) generation for default files — linked to it 👍

Asked @larowlan to double-check my security concerns, and per https://git.drupalcode.org/project/experience_builder/-/merge_requests/1... seems like he's +1 😅

Discussed with @f.mazeikis, @lauriii and @effulgentsia.

The bigger impact is actually for ContentTemplates being fully exportable and importable (without the need for content syncing!), not code component default images.

Discussed this in detail with @f.mazeikis. We tried to figure out if there would be a reasonable way to rely as much as possible on 11.3's new content exporting functionality (already in use by Drupal's Recipes ecosystem!).

We think we see a way forward. It'd require:

1. Allowing for different kinds of providers, to ALLOW but NOT REQUIRE content dependencies (e.g. Acquia Source would likely prefer to rely only on config import/export and rely on media assets in Acquia DAM).
2. Which then in turn requires transforming these URLs upon import to locally-resolvable URLs.
3. (But keep the specified image/video/… URLs conforming to the JSON Schema constraints, by leveraging https://en.wikipedia.org/wiki/Well-known_URI)

👇

Exported

So, applied to a concrete Canvas code component for both the "pure Drupal core" scenario and a "Acquia Source/DAM" scenario, an exported code component would look like this:

1. Contrib (blue rectangles): content dependencies + a "well known" URI that specifies "default content" as the provider
2. Acquia Source/DAM (purple rectangles): NO dependencies a single module dependency: acquia_dam + a "well known" URI that specifies "Acquia DAM" as the provider

Imported

Upon importing the code component, these URIs would need to be: 1) validated (that they are accessible, resolve, etc.), 2) after passing validation, transformed to concrete, actual image/video/… URLs

WDYT, @lauriii?

Forgot one thing: for Acquia Source/DAM, it would say:

dependencies:
  module:
    - acquia_dam