Context
We currently store the following metadata fields in MDX frontmatter:
createdByEmaillastUpdatedByEmail
Based on investigation, these appear to be write-only TinaCMS metadata fields. They are written/preserved by TinaCMS and some update flows, but they are not displayed in the UI and are not consumed by business logic.
The existing “Last updated by” UI uses GitHub history rather than these frontmatter fields.
Proposed change
Remove the unused createdByEmail and lastUpdatedByEmail metadata fields from the MDX content model.
This work should cover both the app repo and the content repo:
- In the app repo, remove the schema, query, type, and update-flow support that currently writes or preserves these fields.
- In the content repo, remove these fields from existing MDX frontmatter once the app no longer depends on them.
The goal is to stop storing and maintaining metadata that is not used by the UI or business logic, while ensuring TinaCMS and content update flows continue to work correctly after the fields are removed.
Risk / impact
Expected risk is low because these fields are not displayed or consumed by business logic.
Potential impact to check during implementation:
-
Tina generated files and lock file need to be updated.
-
Tina Cloud schema may need to be synced.
-
The app repo should be updated before removing the fields from the content repo.
Acceptance criteria
Screenshot
Figure: Safe to remove after schema/type/query updates
Context
We currently store the following metadata fields in MDX frontmatter:
createdByEmaillastUpdatedByEmailBased on investigation, these appear to be write-only TinaCMS metadata fields. They are written/preserved by TinaCMS and some update flows, but they are not displayed in the UI and are not consumed by business logic.
The existing “Last updated by” UI uses GitHub history rather than these frontmatter fields.
Proposed change
Remove the unused
createdByEmailandlastUpdatedByEmailmetadata fields from the MDX content model.This work should cover both the app repo and the content repo:
The goal is to stop storing and maintaining metadata that is not used by the UI or business logic, while ensuring TinaCMS and content update flows continue to work correctly after the fields are removed.
Risk / impact
Expected risk is low because these fields are not displayed or consumed by business logic.
Potential impact to check during implementation:
Tina generated files and lock file need to be updated.
Tina Cloud schema may need to be synced.
The app repo should be updated before removing the fields from the content repo.
Acceptance criteria
createdByEmailandlastUpdatedByEmailare removed from TinaCMS schema/config.SSW.Rules.Contentis completed or tracked as a follow-up.Screenshot
Figure: Safe to remove after schema/type/query updates