web: update blog categories and categorize all articles#3966
web: update blog categories and categorize all articles#3966devin-ai-integration[bot] wants to merge 3 commits intomainfrom
Conversation
New categories: Product, Comparisons, Engineering, Founders' notes, Guides, Char Weekly Category mapping for existing articles: - Tool roundups/reviews/alternatives -> Comparisons - Tech implementation/decisions -> Engineering - Founder reflections/building in public -> Founders' notes - How-to articles -> Guides - Product announcements -> Product - Weekly updates -> Char Weekly (kept) Co-Authored-By: john@hyprnote.com <john@hyprnote.com>
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
✅ Deploy Preview for hyprnote-storybook canceled.
|
✅ Deploy Preview for hyprnote ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
There was a problem hiding this comment.
Devin Review found 3 potential issues.
🐛 1 issue in files not directly in the diff
🐛 Default frontmatter for new articles uses removed category "Case Study" (apps/web/src/functions/github-content.ts:115)
When creating a new article via the admin panel, getDefaultFrontmatter sets category: "Case Study" in the frontmatter template. Since this PR removed "Case Study" from the Zod enum in content-collections.ts, any newly created article will fail schema validation at build time.
Root Cause and Impact
The getDefaultFrontmatter function at apps/web/src/functions/github-content.ts:115 still uses "Case Study" as the default category for new articles. However, the Zod enum at apps/web/content-collections.ts:95-101 no longer includes "Case Study" — it was replaced with "Product", "Comparisons", "Founders' notes", and "Guides".
When an admin creates a new article (via createContentFile or createContentFileOnBranch), the generated frontmatter will contain category: "Case Study". This will cause the content-collections build to fail with a Zod validation error, since "Case Study" is not in the allowed enum values.
Impact: Every new article created through the admin CMS will fail to build until the category is manually corrected.
View 3 additional findings in Devin Review.
There was a problem hiding this comment.
🔴 MetadataPanel's category still lists old removed categories The MetadataPanel component in the admin CMS has a hardcoded <select> dropdown with the old category values (Case Study, Productivity Hack), missing the new categories (Product, Comparisons, Founders' notes, Guides). Root Cause and Impact At apps/web/src/routes/admin/collections/index.tsx:2203-2207, there is a raw <select> element with hardcoded old category options. While the PR updated the CATEGORIES constant (line 1977-1984) and the CategorySelect component that uses it, this separate <select> in MetadataPanel was missed. The old options are: <option value="Case Study">Case Study</option> <option value="Char Weekly">Char Weekly</option> <option value="Productivity Hack">Productivity Hack</option> <option value="Engineering">Engineering</option> The correct options should be: Product, Comparisons, Engineering, Founders' notes, Guides, Char Weekly. If an admin selects "Case Study" or "Productivity Hack" from this dropdown, the article will fail Zod validation at build time since those values are no longer in the schema enum. Additionally, the new categories (Product, Comparisons, Founders' notes, Guides) cannot be selected from this panel at all. Impact: Admins using this metadata panel view will see stale category options, potentially setting invalid categories that break the build, and cannot assign any of the new categories. (Refers to lines 2203-2207) Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
🚩 Duplicate category selector pattern in admin panel caused missed update
The admin CMS has two independent category selection UIs for articles: a CategorySelect component (used at line 2437 in a different editing view) and a raw <select> element hardcoded inside MetadataPanel (lines 2198-2208). The CategorySelect component references the shared CATEGORIES constant at apps/web/src/routes/admin/collections/index.tsx:1977-1984, which was properly updated. But the MetadataPanel's inline <select> has its own hardcoded option list that was missed.
This architectural duplication is the root cause of BUG-0002. Consider refactoring MetadataPanel to also use the CategorySelect component or at least reference the shared CATEGORIES constant, to prevent this class of bug from recurring.
(Refers to lines 2197-2208)
Was this helpful? React with 👍 or 👎 to provide feedback.
Co-Authored-By: john@hyprnote.com <john@hyprnote.com>
There was a problem hiding this comment.
Devin Review found 1 new potential issue.
🐛 1 issue in files not directly in the diff
🐛 Default frontmatter for new articles uses removed category "Case Study" (apps/web/src/functions/github-content.ts:115)
When creating a new article via the admin panel, getDefaultFrontmatter sets category: "Case Study" in the frontmatter template. Since this PR removed "Case Study" from the Zod enum in content-collections.ts, any newly created article will fail schema validation at build time.
Root Cause and Impact
The getDefaultFrontmatter function at apps/web/src/functions/github-content.ts:115 still uses "Case Study" as the default category for new articles. However, the Zod enum at apps/web/content-collections.ts:95-101 no longer includes "Case Study" — it was replaced with "Product", "Comparisons", "Founders' notes", and "Guides".
When an admin creates a new article (via createContentFile or createContentFileOnBranch), the generated frontmatter will contain category: "Case Study". This will cause the content-collections build to fail with a Zod validation error, since "Case Study" is not in the allowed enum values.
Impact: Every new article created through the admin CMS will fail to build until the category is manually corrected.
View 5 additional findings in Devin Review.
web: update blog categories and categorize all articles
Summary
Replaces the old blog category set with new categories requested by the marketing team, and assigns a category to every existing article.
Old categories: Case Study, Products In-depth, Char Weekly, Productivity Hack, Engineering
New categories: Product, Comparisons, Engineering, Founders' notes, Guides, Char Weekly
Changes were made in three definition locations:
content-collections.ts— Zod enum schemasrc/routes/_view/blog/index.tsx— public blog filter listsrc/routes/admin/collections/index.tsx— admin CMS category selectorAll 54 existing articles now have a
categoryfield in frontmatter. Previously only 4 articles had one.Category mapping applied:
Review & Testing Checklist for Human
choosing-a-cmsanddeveloper-documentation-toolsare tagged Engineering (not Comparisons),what-makes-reliable-ai-note-takeris tagged Comparisons (not Guides),can-you-transcribe-meetings-without-sending-data-to-cloudis tagged Guides (not Engineering)"Founders' notes"renders correctly — the apostrophe in the category name should be verified on the blog page filter bar, desktop sidebar, and admin category dropdown/blog/and verify category filters work, counts are correct, and articles show under the right categories/admin/collections/, edit an article, and verify the category dropdown shows all 6 new optionsNotes
Case Study,Products In-depth) had zero articles using themProductivity Hack→Comparisonsmigration applied tobest-ai-notetaker.mdxpnpm -r typecheck)Requested by: @ComputelessComputer
Link to Devin run