Two of these were live: PageBuilderPanel still compared kind === 'gallery' in
two places, so a carousel block's editor and its Choose button were both dead
branches. The type checker could not see them — both compare against string.
The rest is copy somebody reads: "Change gallery", "Name a new gallery",
"Reading the gallery", "Add to this gallery", Home's Gallery heading, and the
"Create Gallery" file action, now "Carousel from folder".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
It always rendered as one — data-carousel, a snap track, two arrows, driven by
carousel.client.js. The entity was the last thing still calling it something
else, and that collided with the site's own Gallery section: two nav rows
reading Gallery and Galleries, meaning a list of objects and a list of
photograph sets.
GalleriesPanel, GalleryPicker and GalleryItems become Carousels*, the endpoint
becomes /fofos-admin/carousels, the block kind becomes carousel and
subject-gallery becomes subject-carousel. The publish allowlist follows the
renamed tables.
What did NOT move: GALLERY_CONFIG at /fofos-admin/gallery, subjects.ts's
base '/gallery', and home_gallery_media. Those are the Gallery section and the
legacy rows, and both are correct.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The Gallery is a flat list of peças, each with a title, a gallery of mixed
media, and the specs from the client's sitemap — measurement, raw material,
colours, and NOTAS: production time and shipping conditions.
That is a collection one level flatter, so the panel is shared rather than
copied. SubjectPanel and SubjectFields take a section config (subjects.ts);
CollectionsPanel and PiecesPanel are one line each.
The five template blocks are renamed collection-* to subject-*. They never read
anything collection-specific, and copying them per section would have meant
twenty kinds by the time Drops and Collabs land.
Called Pieces in the nav, not Gallery — there is already a Galleries section
meaning a named set of media, and two rows called Gallery and Galleries is a
question somebody has to answer every time they look at it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Removing `chooseCover` cut the wrong span and left an orphan `});` behind. Bun's parser refused the
file, `rebuildFrontend()` failed at every boot, and the server went on serving the last bundle that
built — 14:23. Every plugin change after that reached the disk, was merged, was restarted, and never
reached a browser.
Which is why the template preview looked unfixed twice: the fix was live on the server and absent from
the page. The symptom of a failed frontend build is not an error anywhere a person looks — it is the
previous build, working perfectly, being wrong.
Also fixes a choice with `kind: null` — one that is not built yet — being filtered out by a list that
only knows about the kinds that are.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`collection-cover` draws the FIRST photograph in the gallery, large, beside the words — the shape the
client's sitemap draws. Not a second way to choose one: a gallery is ordered and reordering it is how
the lead changes, which is the rule everywhere else here.
The five subject blocks are places-only, like the contact form and the partner row. They hold nothing
at all — what they draw is the collection the URL names.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`/collections/amadoras-mythology` and `/collections/70s` are the same page with a different subject.
Building each would be absurd; hard-coding the arrangement would put it out of reach of the admin. So
the arrangement is built once — a template page, composed exactly like any other — and every
collection is drawn through it.
Four blocks read the subject: its name, its description, its specs, its photographs. They hold nothing
at all, not even a reference. `collections` holds no content because the list is a query; these hold
none because the subject is the URL, and the same block draws a different collection on the next
request.
Offered only on a template, and HIDDEN rather than disabled elsewhere. A greyed-out row invites "why
not here", and the answer — this page has no subject — is not something a tooltip fixes. Available and
silently drawing nothing is the worse failure.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The first block whose content is a QUERY rather than something somebody typed. It stores nothing at
all: a page holding "the collections" must not also hold a copy of which collections there were, or
adding one tomorrow would mean remembering to edit every page that lists them.
That makes it a places-only kind alongside the contact form and the partner row — one click to add, no
editor behind it. The hint says "every collection" rather than naming a picker, because there is
nothing to pick.
Gallery, Drops and Collabs all want the same shape. This is the one that decides it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A fourth level under the open band only — a page of six bands with four blocks
each is thirty rows, and the nav stops being somewhere you can find anything.
Blocks are named by the same list the picker offers, so a thing is called the
same word wherever it appears.
Clicking a block in the PAGE now writes that address too, rather than calling the
handler directly. Both ways of picking a block are the same act, so neither can
disagree with the other about what is selected — and closing it is the band row.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two rows, one of them marked `soon`, for a distinction that was never the editor's to make. The path
names a real file and what that file IS is a fact about it — the site reads it off the extension the
way a gallery item always has. So the picker asks for a file and stops asking what kind.
`video` is gone from what an editor can create and still legal in the database. Every row was migrated;
one written by something older should still be editable rather than open nothing, which is why the
edit path answers to both.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Both hold nothing, so adding one opens no editor: a dialog with no field on it is a step that exists
only to be got past. The picker itself answers the opposite way for the kinds that DO have a choice
to make, which is the distinction worth keeping.
The canvas draws no Edit button for them either — an Edit that opens nothing is worse than no Edit.
It asks the panel rather than holding a list of kinds, because which kinds are editable is the same
knowledge that decides which editor opens, and that already lives there. Absent means editable, so a
caller that has never thought about it gets what it had.
The Spacing dialog's label became a map. It was two kinds and readable as a ternary, then three and
not.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The picker listed it as `soon` beside Image. It is not soon any more — the set, its ordering and the
carousel that draws it were already built on the site, so the block is a reference to one and the
admin's whole job is choosing which.
`GalleryPicker` chooses a SET and nothing else. Editing what is IN the set stays under Galleries: a
block that could also rearrange its own pictures would be a second place to do one job, and the two
would disagree. No thumbnails — every stored path names an original a browser cannot display, and the
plugin has no way to address a rendition, so the name and the count identify it instead.
Saved on choose, like a video and for the same reason: picking one thing is one act with one outcome,
so there is nothing to draft and nothing to cancel out of.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The picker offers it now, and choosing it opens the media picker rather than a dialog. A video is a
PATH, saved as soon as it is chosen: free text needs a draft because writing is something people do
halfway, and picking a file is one act with one outcome.
Edit means whatever editing that KIND means. The canvas draws one button; which door it opens is decided
in the panel, where the kinds are known — so Edit on a video reopens the picker and Edit on text opens
the editor.
Image and Gallery stay named and disabled. Both are things the site already has.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
It opened the text editor straight away, and I had argued for that: Free Text is the only kind that
works, so a picker offering it is a click asking to be got past.
That was wrong in the way a shortcut usually is. It optimised the state of the app today and hid its
shape — somebody adding a component could not see what a component IS, or that there will be others,
and the day the second kind lands the interaction changes underneath them.
It is also the pattern this admin already uses. The nav lists unbuilt sections as `soon` rather than
hiding them, because a list of only what is finished gives no sense of what the thing is for. The same
argument applied here and I had not noticed.
Image, Video and Gallery are named and disabled. Those three are things the site already HAS — media,
video and galleries all exist as concepts here — which is the difference between saying what is coming
and inventing a roadmap.
The list lives in the plugin rather than the API. The API decides what may be STORED; this decides what
may be OFFERED, and it has to be here because every kind needs a label, an icon and an editor that only
exists in this plugin. A kind the server would accept and this has never heard of is not creatable
anyway.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
pastilhasandClaude Opus 5