The pending changes API endpoint should list individual regions for global template changes

Besides changing this endpoint, is there any other complication we can foresee with breaking the 1:1 relationship between what the UI shows in the pending changes list and what corresponds to an entity? Hopefully, it's no big deal, but just wanting to ask before we go down that road.

@effulgentsia

Rough implementation plan:

• (ideally) Get 📌 Make AutoSaveManager::getAutoSaveKey static Active in
• Add a new method to autosave manager saveGlobalRegion - this just appends the region name to the existing key and label
• Change ApiPreviewController to store one entry per model region instead of in one hunk by calling this new method
• Update ApiPublishAllController to group page template entries in $all_auto_saves and join them before calling the existing code

So whilst the title says 'pending changes api' the actual changes are elsewhere.

#3: 📌 Make AutoSaveManager::getAutoSaveKey static Active already landed Jan 17 :)

Crosspost

Per https://git.drupalcode.org/project/experience_builder/-/merge_requests/5..., I'd like @longwave's thoughts here in particular because it's thanks to him we have docs/adr/0005-Keep-the-front-end-simple.md, and @larowlan's remark reveals that here we're deviating from that.

I like the approach here and there's no need to expand this issue's scope. Regarding my comment #2, I opened ✨ Allow a wse_config entity to represent a config partial rather than a complete config entity Active .

Just thinking out loud a bit, but are we over complicating by trying to split the config entity both here and eventually in Workspaces? We created the config entity - should page_template be a page_region config entity instead? This would simplify all the cases we have so far - perhaps there are downsides I haven't thought of.

I think it's worth exploring that idea. I'm not sure if this is the issue for that or we should postpone this on a spike

I opened 📌 Consider refactoring page_template into page_region(s) Active .

Per #3501600-7: Consider splitting 1 PageTemplate config entity into N PageRegion config entities → , I now think it's quite likely we should not do this, and do that instead. Postponing until #3501600 lands and we're 100% confident we won't need (something like) this.

@longwave: well predicted! I see at least one nice bonus benefit — see bottom of that comment 😄

99% certain that we're going with #3501600 per #3501600-13: Split 1 PageTemplate config entity into N PageRegion config entities → , just needs @lauriii confirmation for me to tackle this next week 👍

📌 Consider refactoring page_template into page_region(s) Active landed.

we want to only show the regions that actually have changed.

That is indeed the remaining challenge after 📌 Consider refactoring page_template into page_region(s) Active :

But … this is a problem already for the content entity's XB field already. For that, we have 🐛 Once previewed in XB an entity with no changes will still show up in "Review x changes" Active . Both the edited content entity and the global regions (1 PageTemplate with N component trees, and as of minutes ago, N PageRegion config entities with 1 component tree each) get their auto-save states created through \Drupal\experience_builder\Controller\ApiLayoutController::buildPreviewRenderable(), so it's all already in a single place already anyway.

Hence my proposal to tackle that all in 📌 Consider refactoring page_template into page_region(s) Active .

wim leers → closed merge request !572