[Needs design] Previews of pages containing (dynamically) empty blocks are malformed

I think we should make two quick hard-coded fixes for now, and then figure out how to abstract and provide UI affordance in a follow-up:

• Don't render the Highlighted region within the canvas. It can still be in the layers panel.
• Don't render the Help block within the canvas. It can still be in the layers panel.

My premise here is that what editors generally want to see in the canvas is what their site visitors will see under typical circumstances, not what only other admin users will see or what site visitors will see only under rare circumstances. There's plenty of gray area around this, but the above two items seem pretty clear cut to me, and I wonder how much closer the canvas will get to the preview with just those two fixed.

I agree with the premise set by @effulgentsia in #2. There was already some related discussion in 📌 Add support for global regions Active on this.

Content creators not seeing the site as the site visitor is a pain point that comes up consistently in interviews with users. There are several actions that are already on the way to make the rendered preview represent more closely what an actual visitor of the site would see.

We are already moving local tasks from the page to the navigation in Drupal Core in ✨ Create the Top Bar Needs review . The goal would be to do the same for local actions.

Messages may need a special case along with main content and help because they are usually not changed after the initial configuration. The initial configuration could be done by a developer.

Per #4.

The way both of you are talking about this, is about hiding irrelevant regions from the XB user. That's a different problem than the one described in the issue summary.

We can do that, but then not here: I don't want to repeat the problem space I outlined in the issue summary that will still need to be resolved anyway.

Hardcoded temporary work-around for hiding irrelevant regions in Olivero only, imperfectly

I disagree with #2 (and hence #3) being a solution to the problem described in the issue summary.

It would only solve the "problem" for a very small set of users:

• Those using Olivero
• Those who aren't putting similarly dynamically empty blocks in other regions: primary_menu, secondary_menu, hero …

All #2 would achieve is the out-of-the-box experience for Olivero users, without placing more blocks.

I'm fine with doing what's proposed in #2, if it's something that we believe improves 🌱 Milestone 0.2.0: Experience Builder-rendered nodes Active for the Drupal CMS demoing purposes. But then it must be explicitly acknowledged that this MUST be removed prior to 1.0-stable.

A possible long-term solution

I agree that hiding certain regions is likely worthwhile, actually! (Related: ✨ Focus mode for global regions Active would become more usable/useful as a bonus!)

Proposal:

• Build upon this single checkbox:
  
• … upon checking it, show a list of checkboxes: one per region, to allow opting specific regions out from editing through XB.
• This information could trivially be stored in the PageTemplate config entity.
• … we could then automatically respect that in ApiLayoutController + ApiPreviewController

Issue created for the proposed long-term solution described in #6: 📌 PageTemplate: allow configuring which regions are exposed Active .

#3498248 works. See #3498248-21: PageTemplate: allow configuring which regions are exposed → .

Restoring original title. I explained in #6 why #2 is about a different problem.

That also means this is no longer a , because the proposal in #2 is achieved in 📌 PageTemplate: allow configuring which regions are exposed Active . 😊

I think 📌 Handle components without HTML wrappers Active is a duplicate of this. Let's see if @longwave agrees :)

… but #3518250 is for SDCs, wheras this one is for Blocks. I think we need a general solution for all component sources!

Aha, good find - I agree that 📌 Handle components without HTML wrappers Active is basically a duplicate, will close that one.

However I think we can try to do something here even without a design? There are two slightly different cases here: a component that's completely blank, and a component that contains some text but no HTML wrapper.

I think we need to ensure that we are at least outputting an HTML tag that can have the XB UUID attached so the front end can find something to receive the click/be draggable/etc. We could also add some text similar to the "broken" block in core if there is none at all in the output? Leaving the "needs design" tag but removing the postponed flag because I think this could be worked on now and iterated over time.

I think we need to ensure that we are at least outputting an HTML tag that can have the XB UUID attached so the front end can find something to receive the click/be draggable/etc.

Now that we have 📌 Investigate drag-and-drop solution that removes the need to drop items into the preview iFrame Active , do we really need this? I think what's receiving the click now is a transparent box over the iframe, so we shouldn't need to wrap the bare text that's inside the iframe, or at least I hope we don't have to. It would be great to keep our previews accurate regardless of what CSS people happen to have by not having to insert any wrappers.

I still think it makes sense to use \Drupal\Core\Render\PreviewFallbackInterface::getPreviewFallbackString as there are some blocks that might be expecting this
We could have the component source interface extend that and defer to each source on how to handle an empty component

Merged @longwave's observations from 📌 Handle components without HTML wrappers Active into this issue.

@larowlan in #13: That is indeed a possibility, but it violates the promise of “accurate previews”. So I think @lauriii won’t want to follow Layout Builder’s example?

Layout Builder has to use \Drupal\Core\Render\PreviewFallbackInterface::getPreviewFallbackString because it doesn't have an alternative way to interact with the blocks that have been placed. In Experience Builder, we do have the layers as an escape hatch.

Relying on the layers isn't necessarily ideal so there's a trade-off between preview accuracy and discoverability of these components. I'll make sure to discuss this with @callumharrod and @reneelund in future but I don't think this is something we need to solve urgently.

I'm leaning towards removing this from stable blockers, and handling 📌 Handle components without HTML wrappers Active separately as a stable blocker.