Builder hub blog

[mnelsonBT]

Launches a new blog section under /developers/blog/ for the Builder Growth team (and others) to publish long-form technical content.

Description

Blog infrastructure

• BlogLayout — new layout template for individual blog posts, with table of contents, breadcrumbs, reading time, and file contributors. Mirrors the established TutorialLayout patterns.
• BlogPostMetadata — metadata strip component showing author, team, tags, published date, and reading time.
• /developers/blog/ listing page — server-rendered listing sorted by publish date (newest first), with per-post tags, team attribution, and reading time.
• getBlogPostsData utility — uses the shared getContentListData helper to load posts from blogPosts.json slug registry. Adding a new post only requires creating a content directory and appending its slug to the JSON array.
• BlogFrontmatter interface — extends SharedFrontmatter with author, published, team, tags, sourceUrl, image, breadcrumb, and hideEditButton.

Blog posts

Post	Author	Published	Type
Building on Ethereum in 2026	Philip Krause	2026-05-07	Original
Privacy apps on Ethereum	Philip Krause	2026-04-14	Syndicated from X
Agentic commerce infrastructure	Rick	2026-03-27	Syndicated from rick.build

JSON-LD structured data

• Author personas (3 new entries in KNOWN_PERSONS)
• Listing page (page-jsonld.tsx) — CollectionPage schema with ItemList of all posts, full breadcrumb trail, and contributor list.
• Individual posts (page-jsonld.tsx in [...slug]) — enhanced to emit BlogPosting type for blog slugs, with author resolution via KNOWN_PERSONS alias map.

Developer hub integration

• "Recent updates" carousel on /developers/ page linking to latest blog posts.
• Blog listed in breadcrumb navigation as "Builder updates" via custom i18n mapping.

Notes

sourceUrl without source

The TutorialFrontmatter has both source (display label) and sourceUrl (link). We added only sourceUrl to BlogFrontmatter because the display label can be derived from the URL if we ever build the component, and we are not building it now.

blogPosts.json slug registry

New posts are added by creating a public/content/developers/blog/<slug>/index.md directory and appending the slug to src/data/blogPosts.json. This mirrors the internalTutorials.json pattern and keeps the content data layer simple

Preview link

https://deploy-preview-18146.ethereum.it/latest

[netlify]

✅ Deploy Preview for ethereumorg ready!

Name	Link
🔨 Latest commit	fed5762
🔍 Latest deploy log	https://app.netlify.com/projects/ethereumorg/deploys/6a183feda700060008970e51
😎 Deploy Preview	https://deploy-preview-18146.ethereum.it
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	7 paths audited Performance: 70 (🟢 up 5 from production) Accessibility: 96 (no change from production) Best Practices: 100 (no change from production) SEO: 98 (🔴 down 1 from production) PWA: 59 (no change from production) View the detailed breakdown and full score reports

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[mnelsonBT]

@wackerow changes in May 27 commits:

• URL structure moved from /developers/blog/ to /latest/
• Updated /latest/ landing page hero image
• Added hero images to post frontmatter
• Refactored BlogLayout to use MdxHero (instead of a custom hero image config)
• Updated /developers/ carousel fallback to use the new post header images
• Deleted unused images and older post files

[myelinated-wackerow]

Mirror external blog post hero images to S3

Out of scope for the current PR. This comment is placeholder context; intent is to convert it into a follow-up issue via GitHub's "Reference in new issue" once this PR merges.

Context

Blog posts under /latest/ support an optional image: field in frontmatter that renders on the article page and preview cards. Today all posts use local /images/... paths, but contributors will want to reference external URLs (third-party hosting, generated artwork, screenshots from external tools). Next.js will refuse to render those via next/image unless the source domain is allowlisted in remotePatterns — and we don't want to open the allowlist post by post. The canonical pattern in this repo is to fetch external images at sync time and mirror them to S3 (s3-dcl1.ethquokkaops.io), which is already allowlisted.

Proposed approach

Follow the existing data-layer Trigger.dev pattern (see src/data-layer/fetchers/fetchEvents.ts and fetchApps.ts for the logo/banner upload pattern; fetchVideoThumbnails.ts for a per-item conditional upload). The skill that codifies this lives at .claude/skills/data-layer.

Wiring checklist:

• src/data-layer/fetchers/fetchBlogImages.ts — new fetcher. Reads public/content/latest/*/index.md via the GitHub API (fetchers can't access the app filesystem; see fetchGitHubContributors.ts for the pattern). Parses frontmatter, applies isExternal() from @/lib/utils/url, calls uploadToS3(url, "latest/posts") from @/data-layer/s3 for each external image. Returns Record<slug, string> mapping slug → mirrored S3 URL.
• src/data-layer/tasks.ts — add KEYS.LATEST_IMAGES = "fetch-latest-images" and a DAILY task tuple (or HOURLY if cadence warrants).
• src/data-layer/index.ts — getter passthrough: export const getLatestImages = () => get<Record<string, string>>(KEYS.LATEST_IMAGES).
• src/lib/data/index.ts — cached wrapper via createCachedGetter with appropriate revalidation window.
• src/data-layer/mocks/fetch-latest-images.json — mock for local dev.
• src/lib/utils/md.ts getBlogPostsData — read the cached mapping; if frontmatter.image is external and the slug has an entry, substitute the S3 URL before returning. If not external, pass through unchanged.

uploadToS3 already handles SSRF protection, content-type validation, dedupe via SHA-256 of the source URL, 5MB size cap, and existence checks against S3. Nothing new to build there.

Open design question — fallback when mapping is absent

Worth verifying when this is picked up: Trigger.dev tasks in this repo appear to fire on production deploy. If correct, the timing concern largely takes care of itself — a PR merging a new external-image post deploys with its mapping populated as part of the same deploy cycle. What remains is choosing a fallback for the edge cases: first-ever build before any mapping exists, trigger task failure, or a slug missing from the mapping for any reason. Reasonable default: render the deterministic tile fallback (already the path for posts without an image: field). Pass-through of an unmirrored external URL is a non-starter — that would still require per-source remotePatterns allowlisting.

Acceptance criteria

• Blog post with external image: in frontmatter renders the mirrored S3 URL on /latest/<slug> and in the /developers/ recent-posts carousel
• isExternal() check gates the upload — local paths pass through untouched
• Build does not fail when a mapping entry is missing for a known slug
• Mock file populated so local dev works without S3 creds
• No new entries added to remotePatterns in next.config.js (the whole point)

Reference points already in place

• src/data-layer/s3.ts — uploadToS3 and uploadManyToS3
• src/lib/utils/url.ts:17 — isExternal(href)
• next.config.js already allowlists s3-dcl1.ethquokkaops.io
• Authoritative skill reference: .claude/skills/data-layer

[wackerow]

@mnelsonBT Looks good! Patched a handful of things and added the RSS feed. Should be good to go! Nice job 🔥