DEV Community: DevFixel

Dynamic Open Graph Images in Next.js With ImageResponse (next/og)

DevFixel — Fri, 25 Sep 2026 10:18:19 +0000

Dynamic Open Graph Images in Next.js With ImageResponse (next/og)

Every page on a site technically has an Open Graph image slot — most sites just leave it blank, or ship one generic banner image for the entire domain. Next.js's ImageResponse API (next/og) makes it cheap enough to generate a real, on-brand OG image per route instead, using JSX and inline styles, rendered to a PNG at request time (or at build time for static routes). No design tool, no manually exported PNGs sitting in /public.

The file convention

Next.js's App Router treats opengraph-image.tsx as a special file, the same way it treats layout.tsx or page.tsx. Drop one next to a route's page.tsx and Next.js automatically wires up the right <meta property="og:image"> tags — you don't touch the metadata export for it at all.

Here's a real one, the site-wide default for a marketing site:

import { ImageResponse } from 'next/og';

export const runtime = 'edge';
export const alt = 'DevFixel — Custom Software Development Studio';
export const size = { width: 1200, height: 630 };
export const contentType = 'image/png';

export default function OpengraphImage() {
  return new ImageResponse(
    (
      <div
        style={{
          width: '100%',
          height: '100%',
          display: 'flex',
          flexDirection: 'column',
          alignItems: 'flex-start',
          justifyContent: 'center',
          padding: '80px',
          background: 'linear-gradient(135deg, #0d6aa8 0%, #1280c7 55%, #3fa9dc 100%)',
          fontFamily: 'sans-serif',
        }}
      >
        <div style={{ display: 'flex', alignItems: 'center', gap: 16, fontSize: 40, fontWeight: 700, color: '#ffffff' }}>
          DevFixel
        </div>
        <div style={{ display: 'flex', marginTop: 40, fontSize: 58, fontWeight: 700, color: '#ffffff', lineHeight: 1.15, maxWidth: 900 }}>
          Custom Software That Keeps Pace With Your Business
        </div>
      </div>
    ),
    { ...size }
  );
}

A few things worth noting about what's actually happening here:

It's just JSX, but not full CSS. ImageResponse uses Satori under the hood, which supports a meaningful-but-limited subset of CSS — flexbox layout works well, grid does not, and most modern layout primitives you'd reach for in a browser aren't available. Stick to flex containers and you'll avoid most of the friction.
runtime = 'edge' matters. Rendering happens at request time by default, so you want this on the edge runtime for low latency rather than a cold Node serverless function.
The exported size and alt aren't decorative — Next.js reads those exact exports to populate og:image:width, og:image:height, and og:image:alt automatically.

Making it dynamic per page

The example above is static — same image for every request, since nothing in it depends on route params. The actual payoff of this API shows up when the image reflects the specific page it's attached to: a blog post's title rendered onto the card, a product's name and price, a location page's city.

You do that the same way you'd make any other route segment dynamic — accept params:

// app/blog/[slug]/opengraph-image.tsx
import { ImageResponse } from 'next/og';

export const runtime = 'edge';
export const size = { width: 1200, height: 630 };
export const contentType = 'image/png';

export default async function OpengraphImage({ params }: { params: { slug: string } }) {
  const post = await getPostBySlug(params.slug); // however you fetch it

  return new ImageResponse(
    (
      <div
        style={{
          width: '100%',
          height: '100%',
          display: 'flex',
          flexDirection: 'column',
          justifyContent: 'center',
          padding: '80px',
          background: '#0d6aa8',
        }}
      >
        <div style={{ display: 'flex', fontSize: 56, fontWeight: 700, color: 'white', lineHeight: 1.2 }}>
          {post.title}
        </div>
      </div>
    ),
    { ...size }
  );
}

Next.js generates a distinct image per slug automatically — no extra routing config needed, because opengraph-image.tsx inherits the dynamic segment from its parent route the same way page.tsx does. If a post's title is long, that's genuinely a layout problem, not just an aesthetic one — you'll want a font-size clamp or truncation, since Satori doesn't give you graceful text overflow handling for free the way a browser's text-overflow: ellipsis does.

Caching and cost

For a route with a bounded, known set of params (a fixed list of locations, a small product catalog), you can pair this with generateStaticParams so the images get generated once at build time rather than on every request — worth doing if the underlying data doesn't change often, since edge-rendered images on every social-share request add up in both latency and function invocations for high-traffic pages.

Why this is worth doing at all

Social platforms use whatever og:image a page declares (or nothing, if it's absent) when a link gets shared — Slack, Twitter/X, LinkedIn, iMessage previews all read it. A generic site-wide image is fine as a fallback, but a blog post that shows its own title in the preview card gets noticeably more clicks than one showing the same banner as every other page on the domain. It's a small thing that's easy to skip, and cheap enough with next/og that there's not much reason to.

Using this pattern on DevFixel's marketing site for the site-wide default image, with per-route dynamic versions being the natural next step for the blog and location pages.

Auto-Generating FAQPage JSON-LD From Rich Text Content Instead of a Separate CMS Field

DevFixel — Fri, 25 Sep 2026 10:16:28 +0000

If you want FAQPage structured data on a blog post, the usual approach is a dedicated CMS field: an array of question/answer pairs, separate from the post body, that a content editor fills in alongside the article. It works, but it's one more field type to build, one more thing for an editor to remember to fill in, and it duplicates content that often already exists in the article itself as a normal "FAQ" section.

I ended up doing something else: scanning the post's existing rich text for an FAQ-shaped section and generating the schema from that, with no extra field at all.

The convention

Instead of a new field, the rule is just an authoring convention: if a post has an H2 heading matching "FAQ" or "Frequently Asked Questions," everything after it — until the next H2 — is treated as a sequence of question/answer pairs, where each H3 is a question and the paragraph immediately following it is the answer.

## Frequently Asked Questions

### Is this actually necessary?
Only if you want the FAQ rich snippet in search results — the content still reads fine without it.

### What if I don't have an FAQ section?
Nothing happens. The schema generator just returns an empty array and no FAQPage script gets rendered.

Any writer already knows how to write an FAQ section like this. There's nothing new to learn, and nothing to fill in twice.

The extraction code

Working from a Lexical JSON tree (this generalizes to any block-based rich text format), the scan is a straightforward loop:

interface LexicalNode {
  type: string;
  tag?: string;
  text?: string;
  children?: LexicalNode[];
}

function nodeText(node: LexicalNode): string {
  if (node.text) return node.text;
  if (!node.children) return '';
  return node.children.map(nodeText).join('');
}

function extractFaqJsonLd(content: unknown) {
  const blocks = (content as any)?.root?.children ?? [];

  const faqStart = blocks.findIndex(
    (b: LexicalNode) =>
      b.type === 'heading' &&
      b.tag === 'h2' &&
      /frequently asked questions|^faq/i.test(nodeText(b))
  );
  if (faqStart === -1) return [];

  const faqs: { question: string; answer: string }[] = [];
  for (let i = faqStart + 1; i < blocks.length; i++) {
    const block = blocks[i];
    if (block.type === 'heading' && block.tag === 'h2') break; // next section, stop
    if (block.type === 'heading' && block.tag === 'h3') {
      const question = nodeText(block).trim();
      const next = blocks[i + 1];
      const answer = next?.type === 'paragraph' ? nodeText(next).trim() : '';
      if (question && answer) faqs.push({ question, answer });
    }
  }
  return faqs;
}

nodeText recursively flattens any node's text content, so it doesn't care whether a heading has one text run or several (bold spans, links, whatever) — it just concatenates everything under it.

Rendering the schema

Once you have the pairs, the JSON-LD itself is small:

const faqs = extractFaqJsonLd(post.content);

const faqJsonLd = faqs.length
  ? {
      '@context': 'https://schema.org',
      '@type': 'FAQPage',
      mainEntity: faqs.map((f) => ({
        '@type': 'Question',
        name: f.question,
        acceptedAnswer: { '@type': 'Answer', text: f.answer },
      })),
    }
  : null;

{faqJsonLd && (
  <script
    type="application/ld+json"
    dangerouslySetInnerHTML={{ __html: JSON.stringify(faqJsonLd) }}
  />
)}

Why this over a dedicated field

The honest tradeoff: a dedicated field is more explicit and more robust against someone writing an FAQ section that doesn't quite match the convention (wrong heading level, no paragraph directly after the question). Scanning content is more fragile in that specific way.

What it buys back is that every post automatically gets the structured data the moment it has a normal-looking FAQ section, with zero extra CMS schema, zero extra editor UI, and no way for the visible content and the structured data to drift out of sync — because they're the same content. For a blog where FAQ sections are common but not universal, that traded off in favor of "just write it like a normal FAQ section" over "remember to also fill in this separate field."

Using this on DevFixel's blog. If you're doing FAQPage schema a different way — especially anything more robust against the heading-order edge case — I'd be curious how you're handling it.

Debugging a Vercel ISR Route That Silently Refuses to Revalidate

DevFixel — Fri, 25 Sep 2026 10:10:13 +0000

I had a sitemap.ts route in a Next.js App Router project with export const revalidate = 60, pulling its URL list from a CMS. I published over a dozen new pages, waited a few minutes, checked the live sitemap — still the old, shorter list. Waited longer. Still stale.

The setup

Nothing exotic:

export const revalidate = 60;

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const payload = await getPayloadClient();
  const { docs } = await payload.find({ collection: 'posts', limit: 1000 });
  return docs.map((doc) => ({ url: `https://example.com/blog/${doc.slug}` }));
}

This is the standard ISR pattern — the route is cached, and after the revalidate window passes, the next request should trigger a background regen, with the following request getting fresh data.

What actually happened

I checked the response headers instead of just the body:

age: 245
x-vercel-cache: HIT
last-modified: Fri, 25 Sep 2026 07:35:22 GMT

age kept climbing well past 60 — 199, then 245, then higher — with last-modified never moving. Multiple requests, several minutes apart, all served the identical stale cached response instead of triggering a regen.

Meanwhile, other pages fetching from the exact same data source, using revalidate = 0 instead of a cached interval, showed the new content immediately. So the data layer was fine. The problem was specific to this one cached route not revalidating on schedule.

What fixed it

A fresh production deploy. Nothing more surgical than that — redeploying forces every ISR route to regenerate against current data as part of the build/first-request cycle, sidestepping whatever caused the scheduled revalidation to stop firing for that specific route.

I don't have a fully satisfying root cause here — ISR revalidation failures on a hosting platform are hard to diagnose from the outside, since a failed background regeneration typically just... keeps serving the last good version silently, with no visible error. If you don't happen to check age and last-modified against how long it's actually been, you won't know it's stuck.

What I'd check first next time

Compare age in the response headers against your configured revalidate value directly — don't trust that "I waited a while" means the window passed if you haven't waited longer than the number, ideally by a wide margin, and hit it more than once.
Compare against a revalidate: 0 route hitting the same data, if you have one, to rule out a data-layer problem before assuming it's a caching problem.
If a fresh deploy fixes it, that's a strong signal the issue was specific to that route's cached build artifact, not your code's logic — worth knowing before you spend an hour rewriting a query that was never the problem.

Hit this on DevFixel's sitemap route. If anyone's got a cleaner way to force a single ISR route to revalidate without a full redeploy, I'd like to hear it — the only on-demand revalidation APIs I'm aware of require calling them explicitly from your own code after a content change, which wasn't the situation here.

Sourcing Free Stock Photos Programmatically Without Accidentally Grabbing Unsplash+ Premium Images

DevFixel — Thu, 24 Sep 2026 16:18:04 +0000

If you've ever scripted stock photo sourcing — pulling images for a content pipeline, a CMS seed script, a batch of location pages, whatever — you've probably hit the same trap I kept hitting: a big chunk of what shows up in a normal Unsplash search is actually Unsplash+, a paid tier, and nothing about the URL or the search result makes that obvious until you're looking at the actual photo page.

Grab enough images automatically and you will download a premium photo you don't have a license for, without realizing it, unless you check for it explicitly.

The problem in practice

A typical workflow looks like: search for something, pick a promising result, construct an images.unsplash.com URL, download it. That last step almost always "succeeds" — you get a valid image file back — regardless of whether the photo is free or Unsplash+. The CDN doesn't refuse the request. Nothing errors. You just end up with a file you don't actually have rights to use, sitting in your project looking exactly like every other downloaded image.

The only reliable tell is on the photo's own page: free photos serve from images.unsplash.com, Unsplash+ photos serve from plus.unsplash.com. If you're constructing download URLs from a search result without visiting the actual page, you can miss this entirely.

Checking programmatically instead of by eye

Unsplash's own site uses an internal API you can query directly for search results, and — usefully — each result includes a plus boolean:

curl -s "https://unsplash.com/napi/search/photos?query=warehouse+logistics&per_page=10" \
  | python3 -c "
import json, sys
data = json.load(sys.stdin)
for r in data['results']:
    print(r['id'], '|', r['alt_description'], '| plus:', r['plus'])
"

That gives you a clean list to eyeball — plus: False is safe, plus: True isn't — before you commit to downloading anything. You can filter it in the same script instead of eyeballing it:

free_results = [r for r in data['results'] if not r['plus']]

For a single candidate photo you already have the ID for, you can check it directly the same way:

curl -s "https://unsplash.com/napi/photos/PHOTO_ID" \
  | python3 -c "import json,sys; d=json.load(sys.stdin); print(d['plus'], d['urls']['raw'])"

This also hands you the actual photo description and location metadata, which is worth checking too — I've had search results come back for a photo whose alt text vaguely matched what I was looking for, but which turned out (per its own location data) to be a completely different city than intended.

Downloading and actually looking at what you got

Once you've confirmed a photo is free, constructing a sized download URL is straightforward:

https://images.unsplash.com/photo-XXXXXXXX?w=1600&auto=format&fit=crop&q=80

The step people skip here is the same one that matters most: open the downloaded file and actually look at it before using it. Alt text and descriptions are written by photographers and occasionally wrong, misleading, or missing context — I've pulled a photo tagged for one city that turned out, on inspection, to have an odd framing issue (an out-of-focus object blocking half the shot) that no amount of metadata would have warned me about. A quick visual check catches that in seconds; skipping it means finding out after it's already live somewhere.

The full loop

Search via the API, filter for plus: false
For your shortlisted candidates, fetch the individual photo record and confirm plus again (belt and suspenders — I've seen search results and individual lookups disagree)
Construct the sized download URL and pull the file
Actually open and look at the image before using it
Only then wire it into whatever you're building

It's a few extra steps over "grab the first result that looks right," but it's the difference between a defensible content-sourcing process and quietly shipping an unlicensed image because the download URL didn't complain.

Built this into a content pipeline for DevFixel. If Unsplash's public API behavior changes or there's a more official way to filter by license, I'd genuinely like to know — this was reverse-engineered from what the site itself calls, not from documented API behavior.

The CSS Bug That Silently Killed 84% of My Background Effect (position: fixed vs absolute)

DevFixel — Thu, 24 Sep 2026 16:06:40 +0000

I built a decorative background layer for a long marketing page: a handful of large, blurred color blobs meant to drift behind the content as you scroll, giving frosted-glass cards something to actually blur into. I wrote it, checked it in the browser, saw color, called it done.

A day later someone told me the effect "looked the same as before." I was confused — I could see the blobs working. Except I'd only ever looked near the top of the page.

The setup

The background lived in its own component, absolutely positioned relative to a fixed viewport-height container, with a handful of blurred <span> elements inside it:

.ambient-background {
  position: fixed;
  inset: 0;
  z-index: -10;
  overflow: hidden;
  pointer-events: none;
}

.ambient-background span {
  position: absolute;
  border-radius: 9999px;
  filter: blur(70px);
}

And the blobs themselves were placed at increasing top offsets to spread them down the page:

<span style={{ top: '-8rem', left: '-6rem' }} />
<span style={{ top: '8rem', right: '-8rem' }} />
<span style={{ top: '48rem', left: '5%' }} />
<span style={{ top: '80rem', right: '0%' }} />
// ...and so on, down to top: 178rem

Looked reasonable. Rendered fine in the first screenshot. Shipped.

Why it was actually broken

position: fixed doesn't just make an element stay put while scrolling — it also makes its containing block the viewport, not the document. That means inset: 0 on a fixed element resolves to "cover the current viewport," full stop. It is not a tall box you can scroll through; it's permanently exactly one screen tall.

So every blob I'd placed at top: 48rem or beyond wasn't rendering somewhere further down a tall background — it was being laid out inside a box that only ever exists from 0 to ~100vh, and then clipped by overflow: hidden the instant its position fell outside that range. On a typical screen, only the first two blobs (roughly top: -8rem and top: 8rem) ever had a chance of being visible. Everything from 48rem down was being computed, laid out, and silently discarded on every single render.

The page in question was about 20,000px tall. My "sitewide background effect" was covering roughly the first 1,600px of it — 8% of the page — and I'd built it to assume otherwise.

How I actually found it

Eyeballing screenshots wasn't going to catch this, because the visible part looked correct. What caught it was walking the DOM directly and comparing element positions against the full document height:

const bg = document.querySelector('.ambient-background');
const spans = [...bg.querySelectorAll('span')].map(s => {
  const r = s.getBoundingClientRect();
  return { top: Math.round(r.top + window.scrollY), height: Math.round(r.height) };
});
console.log({ docHeight: document.body.scrollHeight, spans });

That printed exactly what you'd expect once you know the bug: every blob's computed top clustered in the first ~1,600px, regardless of what top value I'd set in the source. The moment I saw the numbers next to document.body.scrollHeight, the mismatch was obvious in a way no screenshot was going to show me.

The fix

Swap position: fixed for position: absolute, and make sure the containing block is actually the full document, not the viewport:

body {
  position: relative; /* gives the absolute child a real containing block */
}

.ambient-background {
  position: absolute; /* not fixed */
  inset: 0;
  z-index: -10;
  overflow: hidden;
  pointer-events: none;
}

With position: absolute, the element's containing block is the nearest positioned ancestor — here, <body> — and its inset: 0 now stretches to match <body>'s actual rendered height, which is determined by its normal-flow content (the real page). Because negative z-index descendants of a stacking-context-creating ancestor paint above that ancestor's own background and below its normal content, the blobs still show up behind everything else, but now they're mapped against the real document, not a 100vh window pretending to be one.

I also switched the blob positions from fixed rem offsets to percentages of the container (top: 12%, top: 44%, etc.), so the layout doesn't quietly break again the next time the page's content — and therefore its height — changes.

The takeaway

position: fixed and position: absolute look interchangeable in a lot of tutorials because for a short page, or an element near the top, they often render identically. The difference only bites when the element needs to represent something relative to the whole document, not the current screen — and by then, the bug is invisible unless you specifically go looking for it below the fold.

If you're building any kind of full-page decorative layer, background, or overlay: check its actual rendered position against document.body.scrollHeight, not just what's in the first viewport. A screenshot of the top of the page will lie to you.

Ran into this while working on DevFixel's marketing site. Curious if others have a cleaner pattern for full-document decorative layers — I'd take container queries over percentage math if there's a tidier way to do this.

Publishing Rich-Text Blog Content to Payload CMS Programmatically (No Admin UI Required)

DevFixel — Thu, 24 Sep 2026 16:04:07 +0000

If you're running Payload CMS with the Lexical rich-text editor and you ever need to publish content programmatically — bulk-importing posts, scripting content from another source, or just automating your own publishing workflow — the admin UI isn't your only option. Payload's Local API lets you write directly to the database, including fully-formed Lexical rich-text fields, without touching a browser.

Here's the pattern I've been using, and the gotchas that aren't obvious from the docs.

The shape of a Lexical field

Payload's richText field (with the default Lexical editor) stores a JSON tree. At the root, it's just a list of block-level nodes:

{
  "root": {
    "type": "root",
    "format": "",
    "indent": 0,
    "version": 1,
    "children": [ /* paragraphs, headings, lists, uploads... */ ]
  }
}

Each node type has its own shape. A paragraph:

{
  "type": "paragraph",
  "format": "",
  "indent": 0,
  "version": 1,
  "children": [
    { "mode": "normal", "text": "Your text here", "type": "text", "style": "", "detail": 0, "format": 0 }
  ]
}

A heading is nearly identical but adds a tag (h1–h6):

{
  "tag": "h2",
  "type": "heading",
  "format": "",
  "indent": 0,
  "version": 1,
  "children": [ { "mode": "normal", "text": "A Heading", "type": "text", "style": "", "detail": 0, "format": 0 } ]
}

Lists nest one more level (list → listitem → text nodes), and the listType field controls bullet vs. numbered:

{
  "tag": "ul",
  "type": "list",
  "start": 1,
  "format": "",
  "indent": 0,
  "version": 1,
  "listType": "bullet",
  "children": [
    { "type": "listitem", "value": 1, "format": "", "indent": 0, "version": 1,
      "children": [ { "mode": "normal", "text": "First item", "type": "text", "style": "", "detail": 0, "format": 0 } ] }
  ]
}

None of this is officially documented as a "build it by hand" API — I reverse-engineered the shape by creating a piece of content in the admin UI, then reading it back via a temporary API route. That's the fastest way to confirm the exact fields Payload expects for any node type you need (blockquote, relationship, upload) before you try to generate it yourself.

Writing a small builder instead of hand-writing JSON

Hand-writing this JSON for a real article is miserable. A handful of small helper functions make it manageable — this is the Python version I used, but the same idea works in JS/TS:

def p(text):
    return {"type": "paragraph", "format": "", "indent": 0, "version": 1,
            "children": [{"mode": "normal", "text": text, "type": "text", "style": "", "detail": 0, "format": 0}]}

def h(tag, text):
    return {"tag": tag, "type": "heading", "format": "", "indent": 0, "version": 1,
            "children": [{"mode": "normal", "text": text, "type": "text", "style": "", "detail": 0, "format": 0}]}

def ul(items):
    return {"tag": "ul", "type": "list", "start": 1, "format": "", "indent": 0, "version": 1, "listType": "bullet",
            "children": [{"type": "listitem", "value": i + 1, "format": "", "indent": 0, "version": 1,
                          "children": [{"mode": "normal", "text": item, "type": "text", "style": "", "detail": 0, "format": 0}]}
                         for i, item in enumerate(items)]}

Then an article is just a list of function calls:

blocks = [
    p("Intro paragraph..."),
    h("h2", "A Section Heading"),
    p("More content..."),
    ul(["Point one", "Point two", "Point three"]),
]

content = {"root": {"type": "root", "format": "", "indent": 0, "version": 1, "children": blocks}}

Embedding inline images

Payload's default Lexical config includes an UploadFeature out of the box, which means you can embed a media relation directly inline in the content, not just as a "featured image" field. The node looks like this:

def upload(media_id):
    return {"type": "upload", "version": 3, "format": "",
            "id": uuid.uuid4().hex, "fields": None, "relationTo": "media", "value": media_id}

The id here is just a unique key for the Lexical node itself (any UUID works) — value is the actual ID of the media document you're pointing at. You have to upload the media document first (via payload.create({ collection: 'media', ... }) with a file buffer), grab the returned id, and only then insert the upload node referencing it into your content tree.

Writing the content via a temporary route

The cleanest way to run this once, using Payload's config and access to your database, is a throwaway Next.js API route that calls the Local API directly:

export async function GET() {
  const payload = await getPayloadClient();

  const media = await payload.create({
    collection: 'media',
    data: { alt: 'Descriptive alt text' },
    file: { data: imageBuffer, mimetype: 'image/jpeg', name: 'photo.jpg', size: imageBuffer.length },
  });

  const post = await payload.create({
    collection: 'posts',
    data: {
      title: 'My Post',
      content: builtContentTree, // the JSON you constructed above
      _status: 'published',
    },
  });

  return NextResponse.json({ postId: post.id });
}

Hit the route once with curl, confirm it worked, then delete the route file. No admin UI clicking, no CSV importer, no plugin — just the same Local API Payload uses internally, called from a script instead of a request from the dashboard.

The one bug that'll bite you

If you're inserting more than one image, don't reuse the same media ID in two different upload nodes "for convenience." I did this once — used a photo as both the featured image and the first inline image in the body — and ended up with the same picture rendered twice on the page. Obvious in hindsight, easy to miss when you're generating content programmatically and not eyeballing every field. Fetch the rendered page after publishing and actually check what got embedded before you call it done.

I've been using this pattern to publish content for DevFixel, a software studio I work with — happy to answer questions if you're doing something similar with Payload or another headless CMS's rich-text field.