Layout post preview reverts to the first post

Hi!

When I edit a post , product or a CPT, the layout builder used to open that particular post. Now it reverts to the first post. Also if the layout is reloaded, the one I was previewing is lost to the first one.

I am not sure if it is just me, but this was not the case earlier.

Thank you!

Hey @Misho,

Thanks for posting in! I am using the latest Pro 6.8.6. I cannot replicate the issue. The last post item I edited still displays when I edit the single layout. Even after closing and reopening the layout, that item is still being loaded by the builder. Did this happen after you updated to the latest? Clear the System Cache first in Cornerstone > Settings.

Cheers.

Nothing helped, but I found a site with the latest Pro where it worked, so it must be me. I tried clearing all caches and disabling all plugins, still no luck. I’ll keep debugging.

Or, let me just give it to Claude Code to fix it…

Done, it fixed it! Here is what it reported:

context hint is ignored by builder; preview-group useEffect overwrites it

Version: Cornerstone 7.8.6 / Pro 6.8.6, vanilla install, no custom wrapping.

Expected: When I click “Edit Layout” from the admin bar on a frontend product page, the builder should preview that product. The admin bar emits the URL context as a ?url=<permalink> query arg on the builder link ( Admin.php → get_app_route_url with url_context: true ).

Actual: The builder always previews whichever post was last pinned as the preview for that layout, regardless of where I came from.

Root cause in the React app: The preview-picker component ( app.react18.7.8.6.js — I’m reading the minified function SNe ) has this useEffect:

let [r, i] = OH(e);                       // r = current preview-group for this doc
let l = R8(o);                            // preview contexts for the doc type
let {criteria: u = {}} = useMemo(..., [l, r]);
useEffect(() => { u.url && a(u.url) }, [u.url, a]);   // ← this

For a WC layout with groups[docId] = "single:post-type|product" , the matching context’s criteria has no url field, so u.url is undefined and the useEffect shouldn’t fire. But for other context types ( wc:is-cart etc., which do have criteria.url ) it does fire — and more importantly, whatever resolution happens for single:post-type|product is overriding the ?url= arg the admin bar is passing, because the URL-map resolution chain ( previewUrl: e.documentUrl ?? n[e.id] ?? defaultPreviewUrl ) never reads the query arg at all.

Two specific asks:

  1. Is there a supported way for server-side PHP to tell the builder “preview this specific post for this layout on this session”? If so, what filter/data path?
  2. Would Themeco consider having the app read ?url= on initial mount as the last step of the resolution chain (when url_context: true was used to build the link)? Currently the admin bar emits the arg but the app silently discards it.

Workaround we’re using (if useful context): a mu-plugin that hooks cornerstone_app_enqueue_scripts , checks for ?url= on /cornerstone/edit/{id} , and emits an inline script before cs-app that writes {[docId]: url} into the document-preview-urls localStorage map and deletes the matching document-preview-groups entry so the group-resolution useEffect doesn’t re-pin a stale default. Works reliably but is obviously a hack against internal state.

We’ll have a fix in place for the next release. Thanks for sending this our way and have a great day.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.