WordPress

Use WordPress when REST API pages, posts, or custom endpoints map to a Next.js frontend.

Install

For CLI scans, @cms-lab/cli includes the bundled adapter. Add @cms-lab/core for defineConfig. Install @cms-lab/wordpress only when importing the adapter directly in project code or tests.

pnpm add -D @cms-lab/cli @cms-lab/core
pnpm add -D @cms-lab/wordpress

Config

import { defineConfig } from "@cms-lab/core";

export default defineConfig({
  site: { url: "http://localhost:3000" },
  framework: { type: "next", router: "app" },
  cms: {
    provider: "wordpress",
    url: "http://localhost:8080",
    contentTypes: [
      { type: "page", endpoint: "pages" },
      { type: "post", endpoint: "posts" },
      { type: "case_study", endpoint: "case-studies", uidField: "acf.slug" },
    ],
  },
  routes: [
    { type: "page", pattern: "/:slug", getPath: (doc) => "/" + doc.uid },
    { type: "post", pattern: "/blog/:slug", getPath: (doc) => "/blog/" + doc.uid },
  ],
});

UID and URL field mapping

Use uidField when the route key lives in a custom nested CMS field. Use urlField when the CMS stores the public permalink. Both read dotted paths from document.data.

cms: {
  provider: "wordpress",
  contentTypes: [
    {
      type: "post",
      endpoint: "posts",
      uidField: "acf.handle",
      urlField: "acf.permalink",
    },
  ],
}

CI command

npx @cms-lab/cli doctor
npx @cms-lab/cli scan --ci --report --fail-on error

Provider caveats

• The adapter reads WordPress REST API pages/posts by default and supports custom endpoints.
• Scheduled, draft, pending, and private statuses are treated as draft.
• Custom fields must be exposed through REST before cms-lab can read them.

Check the adapter maturity matrix before using this provider as a strict deploy gate.