Closed (fixed)
Project:
Experience Builder
Version:
0.x-dev
Component:
Internal HTTP API
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
12 Mar 2025 at 08:07 UTC
Updated:
8 May 2025 at 12:59 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
wim leersSo this does not happen when the auto-saved code component is in a content entity's XB field, and only if it is in a
PageRegion?If so, this would be a missed edge case in #3500386: Code Components should render with their auto-saved state (if any) when rendered in the XB UI.
Or are you referring to the
PageRegionitself being auto-saved?Comment #3
lauriiiYes, exactly. This is what I tried to describe in the steps to reproduce.
Comment #4
wim leers25-min deep dive suggests this is because #3500386: Code Components should render with their auto-saved state (if any) when rendered in the XB UI only modified
\Drupal\experience_builder\Controller\ApiLayoutController::buildPreviewRenderable()to do:which results in a
JsComponent::renderComponent(isPreview: TRUE)call, rendering the auto-save (draft).But the page regions are not rendered in
::buildPreviewRenderable(), but in\Drupal\experience_builder\Plugin\DisplayVariant\XbPageVariant::build(), where there's still this:(note the absence of
isPreview: TRUE)It'll be up to
\Drupal\experience_builder\EventSubscriber\PreviewEnvelopeViewSubscriber::onViewPreviewEnvelope()to pass that information toXbPageVariantsomehow.AFAICT the only feasible approach is to rely on this bit in
HtmlRenderer:IOW: update
XbPageVariantto implementContextAwareVariantInterface. Then do something like\Drupal\display_variant_test\EventSubscriber\TestPageDisplayVariantSubscriber::onSelectPageDisplayVariant()to provide a yet-to-be-created "XB preview" context, which can then be respected byXbPageVariant, and which would result in$page_display->setContrexts(['xb_preview' => TRUE]);.The only alternative I see: add a
#xb_preview => TRUEkey-value pair to the "main content", which then is detected byXbPageVariant.Comment #5
wim leers⚠️ AFAICT this also affects the component preview upon hovering the list of available components:
Comment #6
wim leersExtracting #5 into a separate issue, because as @f.mazeikis and @longwave pointed out: there's cache invalidation challenges there. So extracted
A) preview-on-hoverinto #3516705: Auto-saved changes to code components are not visible in preview-on-hover-component-list until published.Comment #7
wim leersWhile reviewing another MR, I stumbled upon
\Drupal\experience_builder\EventSubscriber\RenderEventsSubscriber::onSelectPageDisplayVariant(), which made me doubt my proposal for a second!But … that solves a different problem: that's for loading the auto-saved
PageRegions when appropriate, not for loading the auto-savedJavaScriptComponents when appropriate.So: all good AFAICT 👍
Comment #8
tedbowworking on this
Comment #10
tedbowGave this a start, I put a couple todo's in where I was user how to get the preview context.
Manually testing it, it does work to pick up the autosaved Code component changes
I can work on it tomorrow but if someone wants to take it over before then that works too
Comment #11
wim leers🥳
Nice progress here! 😄
Comment #12
tedbowAssigning to myself to add tests. I looked at this last week but confused about the number of places/ways I could test this.
Hopefully a couple days break will have given me clarity 🤞🏻
Comment #14
wim leersPer #3502371-21: Make "Page title block" work A) also outside regions, B) on the only routes XB currently supports: content entity routes, this now blocks that. Thanks @larowlan for the idea!
Comment #15
tedbowTo write a test I really wanted to understand how this all works
Just noting that I just now realize how the html previewing works. I wasn't involved in these issue but wondering if we should document better how these classes relate to each other
I will re-read the class docs again and see if they are clear but I think they might be clear only because I have actually done some research to see how all these classes fit together.
I think each one this classes have good `@see` links to 1 or 2 of the other classes but I haven't yet found a place where it is clear how on the parts fit together.
Comment #16
wim leers#15++ for improving docs here. I propose a class-level docblock on
\Drupal\experience_builder\Controller\ApiLayoutController.Comment #17
wim leersVery nice work here — only trivial feedback, I think that once the docs exist, this is ready! 😄
Comment #18
tedbow@wim leers re #15 and #16
Could we actually do that in another issue? I think doing it in another issue would allow us to rename a class or 2 to make the relationship more clear, if needed. Whereas if we just do it here I think we might just do quick job and keep the whole flow a bit hard to understand
Comment #19
tedbowre #18, I chatted with @wim leers and he is fine with this in a follow-up. I created #3517977: Doc and otherwise make clearer how the 'html' preview element is generated
Comment #20
tedbowComment #21
wim leersComment #22
wim leersComment #24
mayur-sose commentedThere are two scenarios, one of which is working as expected, and the other is not:
Working Scenario:
When we click "Add to components" from the right-hand side section, changes made to code components in global regions are reflected in the preview immediately without needing to publish or refresh the page.
Non-Working Scenario:
When creating a code component and clicking "Add to components" from the left-hand side section, changes do not reflect in the preview. Below are the steps to reproduce the issue:
Hover functionality doesn’t work, drag-and-drop of myCode7 does not show anything, and the preview remains blank.
Comment #25
lauriiiI don't think that's a regression because we already have an issue for that: #3513147: Using actions from the contextual menu from the sidebar list overrides code component with its latest non-autosaved version.
Comment #26
wim leersComment #27
nagwani commentedComment #28
lauriiiI don't think this has been fixed yet at least for components that had been previously added to the component library, and then changed when they are placed in a global region:
Comment #29
lauriiiI'm actually now realizing that my component wasn't in the header region so this isn't related to global regions 🤔 I'll report this as a new bug.