Render component tree inside the default theme, as a regular page

The designs are already showing that the UX should be similar to Layout Builder so that the page is rendered with the blocks in place to show how the content looks in context of the page. This has some positive effects on the UX but some negative impacts as well because it does mean that we are displaying more content in the current space. We may need to consider implementing a more complex renderer that simplifies the preview and provides a "focus mode" where only the content that is currently being edited is displayed.

First attempt at this, the Olivero footer and background show up in the XB preview.

Happy to change this so it renders more of the page (e.g. header/footer blocks as well) but it's not clear whether that is required or if it would get in the way in some cases.

Nice! I think we may want to render the header and footer blocks too. How much work it would be to build that so that me and the designers could test that? FWIW, I don't think we need to block this issue on that – this could be done in a follow-up.

Something I noticed was that bunch of stuff is not rendering outside the frame which is pretty confusing. I think that's something that @jessebaker or someone else from the frontend team should investigate.

So if we render the full page instead of the bare page, we get the header and footer but also the toolbar...

MR!185 renders all blocks as suggested in #16 but as per #17 I think we need to restrict this - we don't want the toolbar showing up, and we probably want to remove other blocks too. This could be a region setting, but it could also be a block condition? It seems likely there are some blocks people will want to show in XB and others that they don't, and perhaps hardcoding it by region in the theme isn't enough?

To me MR!184 should be merged here to unblock progress and then the decisions about additional blocks deferred to a followup.

Cool, the preview is now looking a lot more like the front end!

RE @lauriii in #16

Something I noticed was that bunch of stuff is not rendering outside the frame which is pretty confusing. I think that's something that @jessebaker or someone else from the frontend team should investigate.

I think the broken layout you are seeing is "correct" - in so much as it now matches the styles seen on the front end. Before it was not an accurate representation of the actual page as it is displayed.

If you visit /node/1 you will see all the content is shoved over to the right just as it is in the XB. On a quick investigation it seems that now we are correctly loading in the CSS there is a css rule to set <img> tags to have display: block; and the image we load in the default component has height and width attributes set to 1024.

Reran stylelint, seems you have to run it from /core otherwise it only picks up some of the config?

Thanks for opening a MR for rendering the full page! I'm pretty sure that's the approach we'll go eventually. There's many problems in that MR which I know we're aware of. Maybe we could merge the bare page preview first and open a follow-up to move to using the full page renderer? This would allow us to move faster because AFAIK the full page renderer is not on the critical path for the first milestones.

… or did you also want the hero etc? Either way, I think the consequence is quite clear: it'll depend on the front-end theme which regions we want to render the blocks for inside the XB preview. 👉 XB will need third-party settings to track this in the THEME.settings config for the default front-end theme.

I would expect it to render the preview just as is when rendering the actual node page. What I wouldn't think we should render there are our "admin UI" elements in the frontend: i.e. admin toolbar and contextual links.