0.37.0: content editor renders only 4 of 23 fields on a database-backed collection (manifest is complete)

[eisenbruch]

Upgrading 0.36.0 -> 0.37.0 left the content editor rendering 4 of the 23 fields on a database-backed collection. Rolling the same site back to 0.36.0 restores all 23 immediately, with no other change.

What renders

For an articles collection with 23 fields, the editor shows only:

• Title (string)
• Excerpt (text)
• Hero image (image)
• Body (portableText)

Missing from the main column: two select fields (both with option lists), one repeater, six boolean fields, two datetime fields, one integer and several string fields. Field labels are redacted; the kinds are what matter here.

Missing from the sidebar: the whole Publish panel (slug, content locale, publication date, "Created and updated") and the Ownership panel. Bylines, SEO, Revisions and Move to Trash still render.

What the server sends

GET /_emdash/api/manifest is correct and complete. It returns all 23 fields with their metadata, e.g.

"title":    { "kind": "string", "label": "Title", "required": true,  "id": "<ulid>" },
"type":     { "kind": "select", "label": "Type",  "required": false, "id": "<id>",
              "options": [ { "value": "article", "label": "Article" }, { "value": "guide", "label": "Guide" } ] },

and

"supports": ["drafts", "revisions", "search", "seo", "scheduling"],
"hasSeo": true,
"urlPattern": "/articles/{slug}",
"titleField": "title"

The fields are also intact in _emdash_fields. So this looks like the admin rendering a subset of what it is handed, rather than missing data.

There are no console errors — the panels and fields simply do not draw. The only console output is repeated Uncompiled message detected ... fallback was used warnings from the i18n catalog, which we ruled out (see below).

Reproduction

1. A collection created through the schema API / admin (database-backed, not file-defined) with select, boolean, datetime and repeater fields.
2. Open an entry in the content editor on 0.37.0.
3. Only string / text / image / portableText fields render; the Publish and Ownership panels are absent.
4. Downgrade to 0.36.0 and reload — all fields and panels return.

One inconsistency worth knowing

It is not perfectly deterministic. On the first load after the upgrade, type and category did render, and the Publish panel with the slug and dates was present; every load afterwards showed the reduced form, including after a hard navigation, and on a second deployment and a second article. Reported to us as intermittent for about a day before becoming constant. That pattern might point at something cached client-side rather than a pure render bug, but we have not isolated it.

Ruled out

• The manifest — verified complete, as above.
• A locale/message-catalog build optimisation of ours that aliases non-English admin locale chunks to English. We deployed one environment with all 27 locale chunks and one with the optimisation, on identical code. Both showed the identical reduced editor, so this is not the cause.
• Data loss — all 23 rows present in _emdash_fields.

Possibly related

#1645 ("Fixes admin manifest field mapping so database-backed collections expose field IDs, widget hints, selected validation, SEO flags, and URL patterns with matching public types") landed in 0.37.0 and touches exactly this path for exactly this kind of collection. #2891 reworked the Publish section, which is one of the missing panels. I have not confirmed either.

Environment

emdash	0.37.0 (broken) / 0.36.0 (fine)
@emdash-cms/admin	0.37.0 / 0.36.0
@emdash-cms/cloudflare	0.37.0 / 0.36.0
Astro	7.2.10
Runtime	Cloudflare Workers, D1, R2, KV
Build	Node 22

Happy to supply the full manifest response or test a patch — we have a staging environment on the same data where this reproduces.

[eisenbruch]

Some more detail after reading the 0.36 -> 0.37 diff, in case it shortens the search. I have not found the fault, and two things I expected to be the cause are not.

0.36 did not put database-backed collections in the manifest at all. generateManifest() in 0.36 walks only the build-time config collections. 0.37 (#1645) adds buildManifestCollections(), which reads _emdash_fields through SchemaRegistry for collections that have no config entry. Every collection on this site is database-backed, so the admin's source of truth for our fields changed between the two versions rather than merely changing shape. That would explain why this reproduces here and not on a site whose collections are defined in config.

The manifest we are served on 0.37 is correct, and comes through the new database branch — it carries urlPattern, titleField and kind values that only dbFieldDescriptor() produces. All 23 fields are present with their option lists.

Two things I ruled out that looked promising:

• ContentEditor does not filter. It maps every entry of collectionConfig.fields to FieldRenderer, and FieldRenderer's switch has a case for all thirteen kinds, including the ones that do not draw for us (select, boolean, datetime, repeater, json). On the source alone, these fields should render.
• dateField. Ours is NULL on this collection, and fix(core/schema): persist titleField/dateField on PUT /schema/collections/{slug} (#2573) #2581 in the same release fixed titleField/dateField being silently dropped by PUT /_emdash/api/schema/collections/{slug}, so a collection built through that API can end up in our state. But dateField is only read by ContentList (date column, default sort, date filter) and never reaches ContentEditor or ContentSettingsPanel, so it does not explain the missing editor fields. Mentioning it because the null is real and may be a separate bug worth its own look.

The inconsistency in the original report may matter more than I gave it credit for. The very first editor load after the upgrade rendered type, category and the Publish panel; every load after that did not, including hard navigations, a second article, and a second deployment. Code does not vary between loads, so something stateful is involved — but I could not find any persisted panel layout or manifest cache in the admin source to account for it, and there are no console errors.

Environment as before: Astro 7.2.10 on Cloudflare Workers with D1, 23 fields on the collection, supports: ["drafts","revisions","search","seo","scheduling"]. Still happy to run a patch or dump anything useful — we have staging on the same data.

[eisenbruch]

This narrows to the admin package alone. Running emdash@0.37.0 with @emdash-cms/admin overridden to 0.36.0 — so the 0.37 core, the 0.37 manifest, the 0.37 API, and only the admin rolled back — renders all 23 fields and every sidebar panel correctly. Deployed to a staging environment on the same database and confirmed in a browser.

So the manifest is not merely "complete", it is consumable: 0.36's admin renders every field from the very same 0.37 manifest that 0.37's admin renders four of. Whatever the fault is, it is entirely inside @emdash-cms/admin 0.37 and does not involve the core, the schema registry or the manifest handler.

For what it is worth, I could not find it by reading the diff, and the places I expected it are ruled out:

• router.tsx passes fields={collectionConfig.fields} from the manifest on both the create and edit routes, byte-identical between 0.36 and 0.37.
• ContentEditor maps Object.entries(fields) to FieldRenderer with no filtering, and that block is unchanged between the two versions.
• FieldRenderer's switch has a case for every kind we are missing (select, boolean, datetime, repeater, json).

Given identical input and seemingly identical rendering code, the difference is presumably somewhere I did not think to look — the settings panel rework in #2891 and the 742-line change to ContentSettingsPanel.tsx are the obvious remaining candidates, since the Publish and Ownership panels vanish alongside the fields.

Two details that may still matter: the first editor load after upgrading rendered everything correctly and no load afterwards did, which suggests something stateful; and there are no console errors at any point.

Reproducing this needs a database-backed collection, which is what makes it awkward — a config-defined collection goes through extractFieldDescriptors() and never touches the new buildManifestCollections() path.

[eisenbruch]

Closing this: it was ours, not EmDash's.

We run a small script in the admin that hides a few technical fields and moves others into the sidebar. One part of it hid the "Content locale" row by climbing from that label to a surrounding block, with a guard that stopped at any block containing "Publish date" or "Status". The 0.37 Publish panel says "Publication date" and has no Status line, so the guard no longer stopped it and it hid the whole Publish section, along with the fields our script had moved into it. That is why the fields were in the manifest and in the DOM but not on screen, why there were no console errors, and why pinning @emdash-cms/admin to 0.36 made it go away.

With that part of our script removed, the 0.37 editor renders every field and panel on the same data. Sorry for the noise, and for pointing at #1645 and #2891.