[PP-1] Experiment: Adapt existing layout builder storage model instead of starting fresh

larowlan → credited acbramley → .

larowlan → credited catch → .

larowlan → credited DanielVeza → .

larowlan → credited EclipseGc → .

larowlan → credited pdureau → .

Crediting those involved in discussions that lead to these ideas - apologies if I've missed people - please ping me

Pushed the block and made a start on the field type changes, more to go next week

This seems very worthwhile to try. I think we know the existing layout builder storage needs to change (even if there are things to work out on what exactly the new storage looks like), so whatever we change it to, we have a data migration issue.

I think we need to rule out a hook_update_N() or post update that loops through every layout-enabled/overridden entity on a site, and all of its revisions, and converts it to the new format. This is whether the new storage is provided by layout builder on a new xb module. Doing the migration in an update would force people to run something that potentially takes hours as part of a minor update of core, which is unworkable for some sites.

An idea I had was a specific migration module that would have an admin page that starts a batch (a bit like the contrib image to media field module). This would give site owners more choice when it happens, but it still requires specifically scheduling the migration, and again potentially hours of downtime. Having to do this would be a major barrier to sites switching over.

The idea here to support legacy storage on read, and automatically convert to the new storage on save, is fantastic. It would allow us to update all sites to the new storage as soon as it's available (whether that's a minor release in layout builder or a new module) with zero downtime. Bulk updates of entities and their revisions could then be done in the background whether via an admin page with batch, on cron, or via drush - potentially can support all three.

Then we can add a hook_requirements() later on that detects non-updated entities and warns the site owner, and remove the legacy support in a major release.

It does not support nested layouts

It is possible though, Layout Builder+ adds nested layout support → .

It does so by bubbling up each layout block's section storage recursively and packages it in the main entity's section storage.

@larowlan walked me through the foundations he proposes that would unblock this over at #3454519, specifically in his draft MR https://git.drupalcode.org/project/experience_builder/-/merge_requests/68 — and I'm definitely +1 🤩👏

See #3454519-22: [META] Support component types other than SDC → for the write-up of everything we discussed, and this issue depends on all 5 points there, but point 4 in particular.

@catch in #10: see the "JIT" bits in points 4 and 5 of that write-up 😄👍

@larowlan: what's next here? I imagine this would be either blocked on all 5 of the things you called out landing first, or this would become one of those 5?

Yep this is paused for now

👍