Seed a Matrix and a Table field on the About page - #65
Merged
Conversation
Neither composite field type appeared anywhere in the seed data - checked the
full history of all four seed/test-data files, Matrix has never been in any of
them - so the only way to see either one render was to hand-build a
configuration in the admin UI first. That is worth fixing now specifically
because Site no longer declares these types at all: they are flex-fields kernel
built-ins as of 10.0.0-rc.16, and a seeded example is the cheapest way to keep
an eye on the integration.
Adds two fields to the About content type:
- about_highlights (Matrix) with two block types, paragraph and stat, so the
polymorphic-repeater shape is actually exercised rather than a single-block
degenerate case
- about_milestones (Table) with year/event columns
Configurations are built from the kernel's own MatrixConfiguration /
TableConfiguration and InlineFieldDefinition rather than hand-written
dictionaries, so an upstream rename or reshape fails the build here instead of
silently seeding a configuration nothing can read. Values likewise use
MatrixBlockValue / TableRow; ContentManager runs them through the field type's
own Normalize on the way in.
Verified against a real seed run, not just a compile: pointed the host at a
throwaway SQLite database, ran --migrate-database, and read the row back. Both
values are stored in the canonical camelCase wire shape -
[{"blockTypeName":"paragraph","values":{...}}] and [{"values":{...}}] - which
also confirms Normalize and the validation pass ran, since CreateAsync would
have thrown otherwise.
5 tasks
duguankui
added a commit
that referenced
this pull request
Sep 6, 2026
…w ones (#66) #65 added about_highlights/about_milestones but only verified against a throwaway database. Against a real, already-migrated database (this repo's own dev Host.db), the seed's own idempotency worked against it: GetOrCreateContentTypeAsync found the about content type already present and returned it untouched, so both fields were created and left attached to nothing. The straightforward fix - attach fields created this run - doesn't cover this exact database either: the fields were created by an earlier run of the OLD code, before this content-type-append logic existed, so they predate the run entirely. Replaced that with "attached to no content type anywhere", computed once at the start of SeedAsync and kept current as this run attaches more. A field with zero usages anywhere is specific enough to this failure mode to touch automatically for a local dev convenience seed; a field still in use elsewhere is left alone either way. New usages are appended after the current highest Order so a deliberate arrangement is not reshuffled. Verified against this repo's own dev Host.db in the exact broken state reported: the two fields moved from unattached to Order 2/3 on About, a second run made no further change, and a from-scratch database still gets all four fields in one pass.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Neither composite field type appeared anywhere in the seed data — I checked the full git history of all four seed/test-data files, and
Matrixhas never been in any of them. So the only way to see either type render was to hand-build a configuration in the admin UI first.That's worth fixing now specifically because Site no longer declares these types at all — they're flex-fields kernel built-ins as of
10.0.0-rc.16. A seeded example is the cheapest standing check on that integration.What
Two fields on the About content type:
about_highlightsMatrixparagraph(text) andstat(value + label)about_milestonesTableyear,eventMatrix gets two block types on purpose, so the polymorphic-repeater shape is actually exercised rather than a single-block degenerate case.
Configurations are built from the kernel's own
MatrixConfiguration/TableConfiguration/InlineFieldDefinitionrather than hand-written dictionaries — an upstream rename or reshape then fails the build here, instead of silently seeding a configuration nothing can read. Values likewise useMatrixBlockValue/TableRow.Test plan
Verified against a real seed run, not just a compile:
--migrate-databaseFlexFieldscolumn. Both values are stored in the canonical camelCase wire shape, which also confirmsNormalizeand validation ran —ContentManager.CreateAsyncwould have thrown otherwise:Host.db