The frame carried key={reloadToken}, so a reload was a NEW element: React
unmounted the old one and the panel went white until the next document arrived.
After a crop change that is not instant — the site is asking av-club for a fresh
ladder — so every framing adjustment flashed an empty panel, which reads as the
preview breaking.
A browser keeps painting the current document while the next is being fetched. So
the element stays and the frame is navigated instead. Same origin through the dev
proxy, which is what makes contentWindow reachable.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Home has no grip, and dropping onto it is refused — hiding the handle alone
would still let something be dragged above the site's front door.
Every preview now reloads on the change channel, not just the page builder's own
writes. The Layout preview draws the top menu and had no reload token at all, so
the one screen where a reorder is visible was the one that never showed it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The line under every nav row, the line under every font select, and the caption
under the preview. Each explained a control to somebody who has already found
it, and the caption was wrong as well — there is no Save to press.
The nav rows are one line now, so they centre.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The frame took all the room the panel had, so a short page left a band of white
under the footer with the measure guides running down through it. An iframe has
no height: fit-content, so the page is measured inside it and the frame follows.
The wrapper, not the body — body is min-h-screen, so measuring it would ask the
frame how tall the frame is.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two things, both asked for after looking at it.
The tint came out. Shading the margins was meant to say "the page does not use this", and against a
white page it read as a blue background — a colour the site does not have, on the screen that exists to
show the site's colours. The two hairlines say the same thing without claiming anything.
And Desktop is fluid. `width: null` means the frame takes whatever the panel gives it, which is the
honest answer for a device that has no width: a desktop is whatever window somebody opened. 1440 was a
guess that then had to be centred and scrolled inside the panel — a page rendered at one width and
looked at inside another, with dark room either side of it.
Tablet and mobile stay pinned, because 834 and 390 are claims about real devices and pinning them is
the only way the preview can answer "what does this look like on a phone".
Fluid, the frame IS a desktop window: the site's media queries answer the panel's real width, and the
measure guides mark where the content stops in the pixels you are actually looking at.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The bar offered Edit and View, and View existed to see the page without the builder's outlines and
handles on top of it. It was the DEFAULT, which put a click in front of every arrival at the one panel
whose job is editing — and it put a branch in every painter that did nothing but wait for that click.
So the mode is gone rather than defaulted the other way: no toggle, no `?mode=`, no guard. The clean
page is still one click away and always was — it is the site, on its own URL. What the admin owes is
the editing surface, always.
The left group in the bar stays, empty. The middle one is centred against the BAR rather than against
its neighbours, so removing the left group would let Desktop/Tablet/Mobile drift as the right group
changes width.
The preview's caption stays too. It reads as a duplicate of the device buttons and is not: they say the
width, and it says which SERVER — development, not production — which nothing else on the screen does.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A classic scrollbar — Linux, Windows — is laid out INSIDE the element, so it takes width from the
frame. The preview then shows less than the device width it claims to be, and at tablet the last menu
item ran off the edge of a page that fits perfectly well at 834.
It cascades, too: a horizontal bar costs height, which can force a vertical bar, which costs more
width, which is how a page that fits ends up not fitting.
Hidden with the same trick the site uses in its own stylesheet, for the same reason. The cost is the
same and worth stating: wheel, trackpad and touch still scroll, and what goes is the visual position
indicator on the platforms where scrollbars are always classic.
Found by looking for a fixed gap between the menu items that turned out not to exist — the nav has no
horizontal gap at all, and justify-between was already doing exactly what it should.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two things the guides made visible the moment they existed.
THE SKELETON CROSSED THE LINES. Add section was appended to `main`, which is the full width of the
page — the content column is what holds it to its measure. So the drop zone ran edge to edge and
straight past the guides, describing a place a section could go that no section will ever occupy. It
goes in the column now, falling back to main for a page that opts out of the measure, where the column
genuinely is the page.
The section outline had the same fault in miniature: `outline-offset: 4px` puts it OUTSIDE the element,
so a band filling the column drew its edges past the guides. Inset now. Editor chrome that overflows
the thing it describes is chrome that lies about it.
THE VIEW WAS LEFT-ANCHORED. Narrowing the panel showed the left margin and the start of the content —
the least informative part of a centred layout and never the part anybody is looking at. The scroller
now starts in the middle, because the page is centred on a real screen and the preview should be too.
On the scroller, not a transform. A transform is the scaling this just stopped doing.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
TWO CHANGES, and the first is an argument I got wrong.
The frame was scaled to fit the panel with a transform. That made the preview change apparent size as
the panel was dragged, so the same page looked different at every panel width and nothing could be
judged against anything. A preview is 1:1 or it is not a preview.
So it stays at the device's real width and OVERFLOWS when there is not room — a scrollbar rather than a
lie. The width was never negotiable anyway: the site's media queries answer it, so a frame given the
panel's width renders the tablet layout and calls it desktop. What changes is only what happens when it
does not fit, and scrolling is the honest answer.
THE MEASURE, as two fixed lines and a width in pixels.
The page is held to max-w-7xl and centred, so on a wide screen the content stops well short of the
window and nothing says where. That is invisible until something is placed against the edge and turns
out to be in the wrong place — which is the moment it becomes expensive.
Fixed rather than absolute, so they stay while the page scrolls; a guide that scrolls away is a guide
for the top of the page only. Not drawn at all when the column IS the full width, because two lines
against the window edges are noise claiming to be information.
One more site marker: data-content-column. Four attributes now, still no behaviour.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The iframe's ref was an inline callback that reset `loaded` to 0 when called with null. React treats an
inline ref as a DIFFERENT ref on every render, so it detaches and reattaches each time — calling the
callback with null, then the node. So `loaded` went back to 0 on every render, which re-rendered, which
reset it again. The injection never survived long enough to run and the page came up with no controls
at all.
An object ref again, and the reset moved into an effect keyed on `reloadToken`, which is the thing that
actually means "a new document is coming".
Same lesson as `useClient` two files along, and the third time this session: a value rebuilt every
render must not be the thing something else keys on.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
An empty section renders as nothing. That is correct on the public site and useless in an editor:
somebody who has just chosen "two columns" sees a blank page and has to take it on trust.
So the canvas outlines every band it finds, names it, says its shape, and offers Delete — and outlines
the columns inside it, because a one-column band and a two-column band are identical until something is
in them, which is exactly when it is too late to notice the wrong choice.
The site provides three attributes and no behaviour: data-page-empty, data-section-id, data-column.
Markers rather than classes, so they cannot be mistaken for styling, cannot be purged by a build that
has never heard of this file, and read as what they are. That is the whole contract — one attribute on
the public site buys the entire editor.
Section names and layouts are FETCHED, not read out of the DOM. The markup says which row a band came
from and nothing else; inferring the layout from its classes would be the admin reading the site's
stylesheet, which is the coupling all of this exists to avoid.
── The race, and why the fix is not another ref ──
Creating a section starts two things that do not finish in a fixed order: the frame fetches a new
document, and the panel fetches the sections to draw on it. Painting only on load meant painting with
whatever had arrived by then, which after a create was usually the data from before it existed.
So SitePreview re-runs the injection when EITHER moves — `loaded` is state, `onDocument` is a
dependency, and whichever arrives second triggers the paint that counts. The caller then controls
repainting through its own useCallback dependencies, which is what those are for.
The handlers still go through a ref, and the data does not. Callbacks are rebuilt every render and
would repaint on every one; the sections are the thing being drawn and should be exactly what decides
when to redraw.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Pressing the button drawn inside the page opens a dialog: a name, and a choice between one column and
two, then Create section. The row lands in the database and the frame re-renders to show it.
The layouts are DRAWN rather than named. "One column" is words for a shape, and a shape is faster to
recognise than to read; the words stay underneath for anybody the picture does not reach.
The name is asked for and not generated. It never appears on the site — it exists so a page of eight
bands is navigable, and "Section 4" tells nobody anything, which is exactly the state a generated name
would leave every page in. Asked at the only moment somebody knows what they are about to build.
The frame is remounted after a write rather than the admin drawing the new band itself. The site
renders from the database; the admin does not know how to render a page, and if it learnt it would be
a second implementation of the very thing this preview exists to avoid.
The canvas now finds the empty-page placeholder by its `data-page-empty` marker instead of taking
`firstElementChild`. That was right for exactly as long as an empty page was the only kind — the moment
a page has a section, the first child IS that section, and it would have hidden the thing being edited.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A component that lives at the PLUGIN level and appears on the site's page: an empty drop zone with an
Add section button, injected into the frame at runtime. Nothing of it exists in the website's source,
so the site never carries code only an editor would see, and the builder can change without the site
being rebuilt.
It works because the preview frame is SAME ORIGIN — through the platform's dev proxy, on Officer's own
host — so contentDocument is readable and writable. That single fact is what the page builder rests on,
and it is why swapping this plugin's hand-rolled cross-origin proxy for the platform's mattered beyond
the bugs it fixed.
SitePreview grew one prop, `onDocument`, called with the frame's document after every load and
returning a cleanup that runs before the next one. So a reload never leaves two sets of controls
behind, and nothing injected outlives the document it went into.
Plain DOM rather than React. Portalling would mean running a reconciler against a document that reloads
underneath it whenever the dev server rebuilds; these are a handful of elements with a click handler,
and this way a reload is a document that no longer exists rather than a tree React still thinks it owns.
Inline styles, not classes. The frame carries the SITE's stylesheet, built by scanning the site's own
templates — a class invented in this file was never scanned and would silently do nothing. The button
takes its colours from --site-fg and --site-bg, so it belongs to whatever theme the site is wearing.
The page's existing content is HIDDEN rather than removed, so the same call will leave real blocks
visible once there are any.
The panel counts the presses for now. That is the only visible proof the wire runs both ways, and it
becomes the section picker when there are sections to pick.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The nav already said it: Pages is a section, and the pages are rows under it. Two things, two screens.
The detail panel was showing one screen with a row lit up, which made the list the answer to both
questions.
?section=pages the list — what exists, what it is called, where it lives, in what order
?section=pages&page=4 that page — what is on it
Both addressable, which is why the distinction is a query parameter rather than state.
Pressing PAGES itself now clears `page`. Without that the section row and the row for whichever page
was last open lead to the same screen and there is no way back to the list but the browser's back
button. Scoped exactly like `media`, and for the same reason: a parameter belonging to one section
should not ride along into the others.
The list stops having a selection — selecting a page leaves the screen entirely — so its rows are
plain rows again and the panel no longer reads or writes the URL at all.
Adding a page deliberately does NOT open it. The next thing anybody does is name it, and the name lives
on the list; jumping into the builder would mean coming straight back.
SitePreview is now shared, lifted out of LayoutPanel with the dev-port lookup beside it. Layout passes
the theme it is editing; a page passes nothing and just gets its own page. The builder shows the real
page at its real address today, which is what the blocks will be judged against when they exist.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
pastilhasandClaude Opus 5