The two headings take the site's own spelling and the shorter word. "Typefaces" is the more precise
term and "Fonts" is the one everybody reaches for; a section heading is a signpost, not a definition.
The fonts go two by two. Four across existed to keep this section the same height as Colours, because
as tabs they shared one grid cell and a taller panel moved everything below it. Stacked sections do not
have that constraint — each is as tall as it is and nothing above it moves — so the reason expired with
the tabs.
What four across cost was the labels: in a panel this narrow every select truncated to "Martia…", so
the row said four times that a font had been chosen and never which one. Two columns give each the room
to be read, which is the only thing the control is for.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Three tabs became three collapsible sections in a column, because there are going to be more than
three. A tab strip works while the names fit on one line and degrades the moment they do not — it wraps,
or it scrolls, and either way the set stops being visible at a glance.
`type="multiple"`, so more than one can be open. Tabs enforced exactly one, which is right when the
panels are alternatives and wrong when they are parts of the same thing: the colours and the padding of
a layout are read together as often as separately.
The grid overlay went with them. Every panel shared one cell so the block stayed as tall as the tallest
and did not jump when the tab changed — a real problem that stacked sections do not have, because a
section that is closed occupies nothing and one that is open is as tall as it is.
`?tab=` still seeds which section starts open, so an old link keeps working and lands on the thing it
named.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Colours, Typefaces and Padding sat below the preview and took their height from it — the same trade the
page builder's editors made, and undone for the same reason: this screen exists to be looked at, and
the controls were eating the thing being judged.
Announced through the same slot, so the panel still holds nothing and still knows nothing about what a
layout is.
One thing that does not survive the move: a JSX comment cannot be an argument. The block carried its
own `{/* … */}` above the tabs and it had to become an ordinary comment on the effect, which is where
the reasoning belongs anyway now that the element is announced rather than rendered in place.
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>
CHANGES APPEAR IMMEDIATELY. Colours and typefaces go into the frame as CSS custom properties because
that is what the page reads them as. A gutter cannot: only a class can carry a breakpoint, and there is
no variable to set instead. So the classes are swapped on the three elements marked `data-gutter`.
That works for one reason worth stating — the classes are in the SITE's stylesheet, which the frame
already has, and the site safelists every step. A class invented in the admin would silently do
nothing, which is the failure this whole arrangement keeps circling.
Only gutter classes are touched. Those three elements carry the gutter and nothing that looks like it —
a section's own padding lands on the <section> and the band padding on <header> — so stripping `px-N`
from them is safe where doing it to an arbitrary element would not be.
Driven by the dependency list rather than a second code path: `gutter` is a dependency of onDocument, so
changing it hands SitePreview a new function, whose effect runs the previous application's cleanup —
putting the original classes back — and then applies the new ones.
THE TAB IS IN THE URL. `?tab=padding`, same rule as the mode and the device: it is addressable. "Look at
the typefaces" is a link somebody sends, and a reload that drops you back on Colours loses the place you
were working in. Absent means Colours.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
One control, three values, horizontal only — Mobile, Tablet, Desktop on one row, smallest first because
that is the direction they cascade.
Not tied to the device toggle, and the difference from the per-band control is the reason. That one has
two axes and three bands, where showing every width would be eighteen inputs, so it writes to whichever
width the preview is showing. Here there is one axis and one value, so all three fit — and seeing them
together is the point. A gutter is a progression, 4 then 8 then 12, judged as a whole; reading it off
three separate visits to the same control is how a site ends up tighter on a tablet than on a phone.
Inherit still says what it is inheriting, and Mobile still says "None", because there is nothing below
it to inherit from.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Not a per-band control. The header, the content column and the footer share one measure and should
share one number at its edges — three sections' worth of controls would be three ways to disagree about
the same decision.
PaddingTab is untouched and stays. It is the per-band control and it is right for the pages, where a
band genuinely does want its own spacing. This panel just is not where that decision belongs.
Same interaction as everything else here: the device toggle picks the breakpoint, Inherit and 0 are
separate options because they are separate instructions, and the select says which value it is
inheriting rather than leaving it to be worked out.
Saved with the colours and the typefaces, because it is a field of the same row — so the per-band write
path this panel had briefly is gone with it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Choose a band — Header, Page, Footer — and set its horizontal and vertical padding. Which WIDTH you are
setting is decided by the Desktop / Tablet / Mobile buttons already in the bar:
Mobile 390 base every width
Tablet 834 md 768 and up
Desktop 1440 lg 1024 and up
That mapping is Tailwind's own and it lines up with the three preview widths exactly. Editing all three
at once would be six controls per section, five of them for a width you are not looking at; this way
you switch to Mobile, see the phone, and change the padding you can see changing.
INHERIT AND ZERO ARE DIFFERENT OPTIONS, because they are different instructions. Unset takes the
smaller breakpoint's value — which is what makes "one padding everywhere" a single choice rather than
three — and zero means no padding HERE even though the smaller width has some. The select says which
value is being inherited rather than leaving it to be worked out, and at the smallest width it says
"None", since there is nothing below to inherit from.
An emptied breakpoint is REMOVED rather than stored as `{}`, so "inherit everything" stays an absence
instead of becoming a thing that has to be told apart from one later.
One Save for both endpoints. The alternative was a second Save for spacing, which means somebody
changing a colour and a padding presses two buttons and is told about unsaved work by one of them.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Making Typefaces one row equalised the two tabs by luck, not by construction — the labels and the hints
under the selects still differed, and any tab that grows a row would put the jump straight back.
So every panel now sits in the SAME grid cell. The block is as tall as the tallest of them and stops
moving entirely, and it stays right when a tab is added or one of them grows.
Measuring instead would have meant a ResizeObserver, a re-measure after every edit, and a wrong answer
for one frame after each. `col-start-1 row-start-1` gets the same number out of the layout engine for
nothing.
`invisible`, not `hidden`. An invisible element still takes its space, which IS the mechanism — and it
is out of the tab order, so the controls behind the front panel cannot be reached by keyboard. The Tabs
root is controlled now, because visibility is decided here rather than by Radix unmounting.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The one-row change was committed and never deployed, so it had not been seen at all. And the breakpoint
was lg — 1024 — which four short selects had no reason to wait for. The breakpoint here is the browser
window's rather than the panel's, and the panel is wide in every window the admin runs in.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two columns made Typefaces twice the height of Colours, so switching tabs moved everything below it and
resized the preview above. A tab strip whose contents jump is one that has to be re-read every time it
is used — which is the opposite of what tabs were for here.
Four across on a wide panel, two on a narrow one, and the hints truncate rather than wrapping into the
second row of height they were really costing.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
?mode=edit
docs/navigation-audit.md draws the line: anything ADDRESSABLE goes in the URL, and whether you are
editing a page or looking at it is exactly that. It survives a reload, it can be sent to somebody, and
a link to a page being edited is a different thing from a link to the page.
`mode`, not `view`. The parameter names the AXIS and the value names the state, so the pair reads
`mode=edit` and `mode=view` rather than the tautological `view=view`. Absent means View — the default
and the common case — so an ordinary link carries nothing and the parameter appears once somebody has
chosen.
The DEVICE deliberately stays in React state. It is a way of looking rather than a thing being looked
at, and nobody has wanted to send one. Worth keeping that distinction deliberate rather than letting
both drift into whichever place was convenient.
COLOURS AND TYPEFACES ARE TABS. They were two stacked cards taking as much height as both together, and
every pixel of it came off the preview — which is the thing being judged. One at a time costs a click
and gives the page back most of the panel.
The 55% cap on the controls is gone with them: one tab is short enough not to need capping, which is
the other thing this bought.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The content column's edges were drawn only by the page builder, and they answer a question the Layout
section has just as much: 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 marks where.
`paintMeasure` is its own function now, called by both. The builder also draws sections, columns and a
drop zone; none of those belong in Layout, whose bands are code and cannot be rearranged from there.
What the two share is exactly the measure and nothing else.
Nothing in View, for the same reason as the builder: chrome of any kind means you are not looking at
the page.
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>
No save, no request, no reload. The panel sets the CSS custom properties on the frame's own <html> and
the page restyles itself, because those are the variables it already reads.
This is only possible because the frame is SAME ORIGIN — it comes through the platform's dev proxy on
Officer's own host. It is the payoff from dropping this plugin's hand-rolled cross-origin proxy, and
the reason that swap was worth making beyond the bugs it fixed.
`removeProperty` where a value is null, not an empty string. Setting the variable to nothing is not the
same as unsetting it: the page's `var(--site-bg, #fff)` fallback would never come back, so choosing
"default" would fail to restore the default — the one case somebody would test.
Applied on load as well as on change, because a reload replaces the document and the properties go with
it. Keyed on the serialised theme rather than the object, which is a new identity every render — the
same trap that hung this component on "Connecting…", one level down.
The property names mirror themeStyle() in the site's layout.tsx and cannot share code across the two
repositories, so this is a copy that can drift. Said so in the file, with the check: the saved page is
rendered by the site's own function, so if live and post-save disagree, this copy is the wrong one.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
It was capped at the device's own height, on the reasoning that a 390x844 phone drawn 1200 pixels tall
is not a phone. That was wrong, and the empty band under the preview in View was the tell.
Media queries answer WIDTH. The layout at 390 is the phone's layout whatever the height, so a taller
frame shows more of the page rather than a different device — a scroll position, not a viewport class.
Width stays the device; height is now simply the room there is.
DEVICES carries widths only. The heights had exactly one consumer, and it was the cap.
One consequence, and it is the right one: the footer is min-h-dvh, so it sits at the bottom of the
FRAME. A taller frame puts it lower, exactly as a taller browser window does.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Edit put a fixed 420px band above a scrolling column, so the preview was a letterbox in the mode where
changes are actually being made — and there was empty panel below the controls while the thing being
judged was squeezed.
One column now, for both modes, and it never scrolls as a whole. The preview is flex-1, so it is always
as tall as whatever is left. The controls are shrink-0, so they are exactly as tall as their content
and no taller. Edit takes height from the preview and only as much as it needs.
Capped at 55% with their own scroll, because shrink-0 alone would let a short window hand the controls
everything and leave the preview at nothing — the same failure in the other direction.
The frame is also capped at the device's real height. A 390x844 phone in a 1200px panel would otherwise
be drawn as a phone 1200 pixels tall, which is not a phone. Past that it stops growing and the space
stays empty, which is honest: there is no device that shape.
Two modes were two return paths; now switching modes hides a block rather than rendering a different
component.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
"Default" told somebody nothing. The question they are asking of that dropdown is "what is it now, and
what would I be changing it from" — so the empty option now reads "Martian Title (site default)", from
the stylesheet that actually decides it.
A label that refuses to answer makes people change the setting to find out, which is the one action
that loses the answer.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The bar is three groups now: how you are looking at it, at what width, and what to do with it. The
middle is centred against the BAR rather than against its neighbours, because the outer two change
width as sections come and go and a middle that drifted with them would never be in the same place
twice.
A section OPTS IN, the same way it opts into Save. Most have no preview — Media is a file browser,
Administration is a connection form, Messages is an inbox — and offering to view any of them at tablet
width offers something that means nothing. A control that does nothing teaches people that controls do
nothing.
The widths are REAL viewport sizes and the frame is SCALED to fit, never squeezed into whatever the
panel has. That distinction is the whole point: an iframe given the panel's width has the site's own
media queries answering the PANEL's size, so "Desktop" in a narrow panel renders the tablet layout and
labels it desktop — the one thing a preview must not do. Never scaled up either: a 390px phone blown
up to fill a wide panel is a phone nobody has, and every judgement made against it is wrong in the
direction of "looks fine".
390 is the iPhone width slots.ts already assumes. 834 is iPad portrait, deliberately above the site's
md: breakpoint at 768 so it shows the desktop nav rather than the drawer — 768 exactly sits on the
boundary and is the least informative width available. 1440 is past the 1280 the content column caps
at, so the margins either side are visible rather than implied.
View gives the preview the whole panel. That is what makes it worth having: at edit height a phone is
a letterbox, and a phone is the width somebody most wants to look at properly.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The header and the footer are designed — they belong to whoever writes the site's code, not to whoever
edits its content. A panel offering to rearrange them offers a power that should not exist, and every
use of it would be a decision made in the wrong place.
What is left in Layout is the part that really is a content decision: the colours and the four typeface
roles. The preview above them is still the real page, so what the code decides is visible here even
though nothing here can change it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`useClient()` rebuilds its verbs on every render, so `get` has a new identity each time. It was in the
effect's dependency list, so the effect re-ran on every render — and its first act is setReady(false),
which renders again, which builds another `get`, which re-runs the effect. The frame never mounted.
Through a ref instead, with the effect depending only on the port.
This trap is documented in CLAUDE.md and it is the same one that silently disabled every playback
report in the Jellyfin player. The platform's own Preview panel sidesteps it by depending on neither
the client nor the URL, which is what this now does.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The preview went through a proxy written into this plugin. The platform already had one —
/api/dev-proxy/:port/* — and it is better in exactly the ways the copy was worst.
Authentication. An iframe navigation cannot carry an Authorization header, and the copy answered that
by putting a token on the URL and on every asset the page then requested. The platform's answer is a
short-lived cookie obtained by an ordinary authenticated request, and its own comments say why: a
token on an iframe URL is a guess about which key the browser stored it under. It had been tried
there and rejected before this plugin repeated it.
Coverage. The copy rewrote URLs with a regex over the markup, which catches only what is written into
the document. The platform injects a script that patches fetch, XMLHttpRequest and WebSocket, so URLs
the page BUILDS at runtime are moved as well — which is most of them in a modern dev server. It also
normalises `..`, forwards HMR, and has nineteen tests behind it.
So the plugin's proxy is gone, previewUrl with it, and the panel does what the platform's Preview
panel does: ask for the session, then mount the frame at the dev port.
No sandbox attribute, for the reason that panel gives. Without allow-same-origin a frame has an opaque
origin and no storage; with allow-same-origin and allow-scripts it can reach up and remove its own
sandbox attribute. Claiming a protection that does not hold is worse than not claiming it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two mistakes, and the second would have bitten immediately after the first was fixed.
The iframe pointed at /fofos-admin/preview/layout. But /fofos-admin is a FRONTEND route — the
single-page app owns it, and anything under it no router claims is answered with the app's own
index.html. So the iframe was served Officer. The plugin's API is mounted at /api/fofos-admin, which
every other call already knew: useClient defaults its base to /api, and thumbnail.ts spells the full
path out for <img> tags that cannot use it.
And an iframe cannot send an Authorization header. Neither can the stylesheet, the fonts or the images
the page goes on to request — those are all Officer requests now, so all of them need ?token=, the
same reason every <img> in this plugin carries one. The token comes off the iframe's own query string
and is propagated into every URL the rewrite touches, with the separator decided per URL because many
already carry the site's ?v= stamp.
It is stripped before the request reaches the site. The token is Officer's and the site has never
heard of it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The panel drew its own header and footer in React. It looked plausible and it was wrong — the site's
header has a logo hanging past a rule and a nav in the content column — and worse, it was a second
implementation of the layout, so it would have gone on being wrong differently every time either side
moved.
So the admin embeds the site's own `/layout` route instead: the real shell with no page in it. A
designer changing the header in code changes what the admin shows, with no admin change at all. That
is the bridge.
Proxied through Officer rather than linked, because everything this plugin knows about where the site
lives is loopback — 127.0.0.1:<devPort> and nothing else. There is no public hostname stored anywhere
and adding one would be a second fact about the same thing, kept in step by hand. The request goes the
way every other request here goes, server-side, and the browser talks only to Officer.
Same origin, which is also what keeps the door open: the day the page builder wants to draw handles on
top of the real page, it can. A cross-origin iframe never could.
The rewrite is narrow and its limits are the interesting part. The site writes root-relative URLs and
those resolve against Officer's root inside the iframe; a <base> tag does not help, because it moves
relative URLs and leaves root-relative ones exactly where they were wrong. So href, src, srcset and
CSS url() are moved under the prefix — and `//` is excluded deliberately, because that names another
host and prefixing one would turn it into a path on this server.
Only HTML is rewritten. Stylesheets, fonts and images are returned as they came: rewriting bytes we do
not understand is how a proxy corrupts a font.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The admin was a section each for Home, About Us, Collections, Gallery, Collabs, Drops and Services,
because the site's pages were a constant in site-map.ts and a developer was the only one who could add
one. A page builder is going to replace that, so the nav stops enumerating pages.
What is left is the two things a page is NOT: Layout — the shell every page renders inside — and Pages,
listed but not built. Layout is first because it is first in the work: building pages before the frame
they sit in means building them twice.
The panel is a sketch of the page with the controls under it. Menu across the top, a body, the footer
at the bottom, in the chosen colours and typefaces — the same principle the header editor already
follows, where the admin renders the structure as the page will show it. It is honest about being a
sketch: drawing the logo and the rules would be a second implementation of the layout, and the two
would drift the first time either changed.
Fonts are a mapping, not free text. styles.css already declares four ROLES — body, sub, title,
display — and every template asks for a role rather than a typeface, so choosing a font is choosing
which of the four faces the build subsets plays each part. The list travels with the payload rather
than being copied here, because a picker offering a face the build never subsets renders as a fallback
nobody chose.
The per-page panels are NOT deleted. AboutPanel, HomePanel and RecordsPanel are still in the tree and
still work; they are unreachable, which is a line in sections.ts rather than a rewrite. The page
builder is not finished, and removing the only way to edit the live site's content before its
replacement exists would leave a gap with nothing in it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
pastilhasandClaude Opus 5