DEV Community: hamed pakdaman

Headless CMS Security: Why Decoupled Is Safer

hamed pakdaman — Wed, 10 Jun 2026 06:54:37 +0000

📝 Originally published on unfoldcms.com — reposted here for the DEV community. (I work on UnfoldCMS.)

A coupled CMS puts the admin login on the same hostname visitors reach. A headless CMS puts it on a different hostname behind auth. That single architectural difference is why headless CMS security is meaningfully better than traditional coupled-CMS security on most real-world dimensions — and it's also why the comparison gets oversimplified into "headless is more secure" when the truth is more interesting.

This post is the architectural take on headless CMS security: why decoupled is safer on most dimensions, where it can be less safe if you don't handle API hygiene properly, and what the honest comparison looks like in 2026. TL;DR: headless wins on attack-surface reduction (admin off the public hostname, smaller plugin attack surface, API-first auth model) but loses on dimensions teams typically don't think about (exposed APIs without rate limits, JWT misuse, secrets in frontend code, draft preview tokens leaking). A well-built headless CMS is meaningfully more secure than a typical WordPress site; a poorly-configured headless CMS can be worse than a maintained WordPress site. The architecture biases toward safer; the implementation determines actual outcomes.

The audience: technical decision-makers and security-conscious teams comparing CMS architectures with security as a deciding factor. If you're earlier in the architectural decision, see headless CMS vs traditional CMS: key differences. For the WordPress-specific security picture this post compares against, WordPress security problems in 2026.

The Attack Surface Difference

The single biggest architectural difference between coupled and headless CMS security is where the admin lives.

A traditional WordPress site puts the admin login at yourdomain.com/wp-admin. The same hostname your visitors reach. The same SSL cert. The same Cloudflare config. Every brute-force attempt, every credential-stuffing bot, every WordPress-specific scanner targets that URL because it's where every WordPress admin lives. Wordfence's data shows the average WordPress site receives 40-100 brute force login attempts per day at its admin URL, with peaks during coordinated campaigns hitting thousands per hour.

A headless CMS puts the admin somewhere else. Sanity Studio runs on studio.yourdomain.com or a separate Sanity-hosted URL. Strapi admin runs on a separate Node service, typically not exposed to the public internet at all. Contentful's admin is at app.contentful.com — your visitors never reach it. The admin login is not on the same hostname as the public site, which means:

Visitors can't accidentally hit it
Public-site Cloudflare rules don't have to allow admin paths
Brute-force bots scanning */wp-admin don't find anything to attack
A successful exploit on the admin doesn't automatically compromise the public site (different hostname, different security boundary)
Network-level controls (IP allowlists, VPN-only access) are easy to apply because the admin is a separate service

This isn't a small distinction. The attack surface for "anyone on the internet can hammer the login" goes from "100% of traffic can find it" (coupled) to "only people who know the admin URL can find it" (headless, or 0% if you put it behind a VPN).

For the WordPress side specifically — including the 250+ plugin vulnerabilities disclosed weekly per Patchstack — see WordPress security problems in 2026. The hostname-shared-with-admin problem is a foundational piece of why WordPress's security posture is hard to harden.

The Plugin and Extension Surface

The second-biggest difference is the third-party code surface. Every active WordPress plugin is third-party code with database access, hooks into the request pipeline, and the ability to register admin routes. The average production WordPress site runs 20-40 active plugins (per Kinsta and WP Engine hosting data) — meaning 20-40 separate trust decisions per site.

The math is unforgiving. Patchstack's 2024 vulnerability report tracked 7,966 plugin and theme vulnerabilities disclosed in 2024 — 21+ per day, with 43% exploitable without authentication. A site with 25 plugins has 25 separate authors with their own update cadences, security postures, and incident responses. Even with auto-updates enabled, the patch-window vulnerability between disclosure and patch application is real.

Headless CMSes have fundamentally smaller plugin surfaces:

Platform	Plugin/extension count (typical production site)
WordPress	20-40 active plugins
Strapi	2-8 plugins
Sanity	1-5 plugins (mostly in-codebase, version-controlled)
Payload v3	0-3 (extension via code, not plugins)
UnfoldCMS	0-2 (Pro features built in core, not plugin-shaped)

The numerical difference matters but the deeper difference is where the extensibility lives. Headless CMSes typically extend through:

Code-based extensions committed to your repo (you wrote it, you reviewed it, you control updates)
Small curated plugin marketplaces (vetted, updated by the platform team rather than 60,000 random contributors)
API integrations where the CMS calls out to external services rather than running their code in-process

Each of these has a smaller trust surface than WordPress's "install any of 60,000 plugins from any author with an account on WordPress.org." For more on how plugin bloat compounds the security cost on the WordPress side, WordPress plugin bloat: your biggest liability in 2026 covers the same vulnerability surface from a different angle.

The API Security Model: First-Class vs Bolted-On

Headless CMSes are designed around APIs. That means API security is a first-class concern in the platform's design. WordPress added a REST API in 2016, retrofitted into a CMS that wasn't designed for it — meaning API security is bolted on rather than architected in.

What this means in practice:

Authentication models:

Headless CMSes default to token-based auth (API keys, JWTs with scopes, OAuth flows). You can mint a read-only token for the public site, a write-only token for a CI pipeline, an admin token for editorial work — each with different lifetimes and revocation paths.
WordPress's REST API auth defaults are weaker. The two main options: cookie auth (only works from the same hostname — defeats the headless use case) or "application passwords" (added in WP 5.6, basic-auth-ish, scope-limited but not gracefully revocable). Many production headless-WordPress setups end up using JWT plugins of varying quality.

Rate limiting:

Headless CMSes typically build in rate limiting per-token, with sensible defaults. Sanity, Contentful, Hygraph all rate-limit by API key out of the box.
WordPress's REST API has no built-in rate limiting. You add it via Cloudflare, a plugin (which is third-party code, see above), or custom server-level config. Many WordPress sites end up with no rate limiting on their REST API at all — which means anyone can hit /wp-json/wp/v2/users and enumerate every user account.

Scoped permissions:

Headless CMSes design permissions as resource-scoped (this token can read posts but not users; this token can write to drafts but not publish). The granularity matches the API surface.
WordPress's role/capability system was designed for the admin UI. It works for the REST API but the mapping from "WordPress capabilities" to "REST endpoint scopes" is awkward; permission gaps are common.

Token rotation and revocation:

Headless platforms ship token-management UIs where you can rotate, revoke, and audit token usage. Sanity logs every API call by token.
WordPress has no built-in token-management UX; revoking application passwords requires admin UI access; audit logging is a paid Wordfence feature.

The summary: API security is what the headless CMS was built around; in WordPress it's an afterthought. For sites where the API surface is real (which is every modern CMS site, even WordPress sites that secretly serve REST API requests for things like the Gutenberg editor), the headless design is structurally safer.

For broader context on API hygiene as a CMS evaluation dimension, see the 10-point headless CMS evaluation checklist — API quality is one of the 10 dimensions scored there.

Where Headless Can Be MORE Risky

The honest counter-section. Headless CMS architecture is structurally safer on the dimensions above, but it introduces new risks teams often underestimate. Five places headless can bite if you don't handle API hygiene properly:

1. Exposed APIs without rate limits.

The headless API is, by definition, public-internet-reachable. If you don't configure rate limits, anyone can hammer it. We've seen production sites where a single misconfigured CDN rule meant a junior developer's bug accidentally hit the CMS API 50,000 times in 5 minutes. The CMS didn't crash, but the SaaS bill that month was 4x normal — and the rate-limit holes that didn't trigger an outage would trigger one under a real attack.

The fix is platform-level: every production headless CMS should have per-token rate limits, IP-based limits via Cloudflare or similar edge services, and alerting on unusual traffic patterns. Most platforms support this; not every team configures it.

2. JWT misuse.

JWTs are the default auth mechanism for many headless CMSes. They're powerful but easy to misuse. Common failures:

Tokens stored in localStorage — accessible to any XSS in the frontend, no protection from cross-origin attacks
Tokens with no expiry — once leaked, valid forever
Tokens with admin scope used for public reads — a misstep that lets anyone with the token write content
Tokens embedded in client-side code — committed to git, scanned by GitHub secret scanners, found by attackers within hours

The fix is operational discipline: short-lived tokens, secure-cookie storage where possible, scoped permissions, secret rotation. None of these are platform-provided; they're choices the team makes.

3. Draft preview tokens leaking content.

Most headless CMSes ship draft-preview features where editors can share a preview URL with reviewers via a token query parameter (?preview=eyJhbGc...). Convenient and dangerous: that URL gets shared in Slack, copied into emails, posted in chat threads, archived in browser history. Without expiry, the preview token works forever — meaning anyone who finds the URL can read draft content.

The fix: short token expiry (15-60 minutes), token revocation when the editor's session ends, and clear UX about what tokens enable. Sanity and Contentful handle this reasonably; smaller CMSes vary.

4. Secrets in frontend code.

Headless setups often involve a frontend (Next.js, Astro, etc.) calling the CMS API. The auth credentials for that call have to live somewhere. The wrong somewhere: a JavaScript file shipped to the browser, where every visitor can read the API key. We've seen production sites with CONTENTFUL_DELIVERY_API_KEY=... in a pages/api/get-posts.tsx file shipped to the browser because the developer used a NEXT_PUBLIC_ prefix when they shouldn't have.

The fix: server-only environment variables (.env.local not .env.production, no NEXT_PUBLIC_ prefix on secrets), API calls from server components or API routes only, secret scanning in CI. Standard for senior teams; missed by junior teams under deadline pressure.

5. Webhook security.

Headless CMSes often trigger webhooks on content changes (rebuild the static site, invalidate the CDN, notify Slack). Webhooks need signature verification — the receiver should verify the webhook came from the CMS and wasn't forged. Many teams skip this step, accepting any HTTP POST to the webhook URL as legitimate. An attacker who finds the webhook URL can trigger arbitrary rebuilds, invalidate caches, or notify Slack with crafted payloads.

The fix: HMAC signatures on webhooks, signature verification on the receiver, rotated signing secrets. The CMS platform usually supports it; not every implementation uses it.

The summary: headless architecture is safer by default but rewards team discipline. If your team has API hygiene baked in (token rotation, rate limits, secret scanning, webhook verification), headless is meaningfully more secure than coupled. If your team treats security as someone-else's-job, headless can introduce new risks WordPress wouldn't have.

For more on the "well-built vs poorly-built" gap that determines actual outcomes, see how to evaluate a CMS: beyond the marketing page — the same evaluation discipline applies to security as to feature breadth.

The Compliance Angle: GDPR, NIS2, Data Residency

Security overlaps with compliance, and the compliance picture also tilts toward headless on most dimensions — but for slightly different reasons than security.

GDPR (Article 17 right to erasure):

Self-hosted headless CMSes (Strapi, Payload self-hosted, UnfoldCMS) give you direct database access, which means scrubbing a user's data is a SQL query. SaaS headless CMSes (Sanity, Contentful) ship admin tooling for it. WordPress can do this too, but the plugin sprawl means data is scattered across wp_options, wp_postmeta, third-party plugin tables, and serialized blobs — making "delete all of user X's data" an investigation rather than a query.

NIS2 supply-chain disclosure (June 2026 audit deadline):

NIS2 requires regulated entities to document every supplier in their critical supply chain. Each WordPress plugin is a supplier. A 25-plugin WordPress site is 25 supply-chain audit line items. A headless CMS with 2-5 plugins (or a self-hosted CMS with code-based extensions) is dramatically smaller. The compliance burden compounds with plugin count.

Data residency:

Self-hosted headless CMSes give you complete control over where data lives. SaaS headless CMSes vary — DatoCMS is EU-only, Contentful offers EU regions on Premium tiers, Sanity defaults to US. WordPress hosting can be EU but the plugin update mechanism still pulls code from WordPress.org's CDN, which has US infrastructure. For strict data-residency requirements, self-hosted headless or self-hosted UnfoldCMS-style monolithic-modern is the cleanest answer.

For deeper coverage of the compliance-specific case, self-hosted CMS and GDPR: data sovereignty in 2026 covers Articles 15/17/28, NIS2 audit requirements, and Schrems II implications in detail.

The Honest Comparison: When Headless Is Actually Safer

The headline "headless is more secure" is mostly true but not universally true. The honest table:

Security dimension	Coupled (WordPress typical)	Headless (well-built)
Admin attack surface	Login on public hostname	Admin off public hostname
Plugin/extension count	20-40 plugins	2-8 extensions
Plugin vulnerability rate	21+/day disclosed	Far smaller surface
API security model	Bolted on (post-2016 retrofit)	First-class architectural
Rate limiting	Add via plugin/CDN	Usually built in per-token
Auth model	Cookie-based + application passwords	Token-based with scopes
Brute-force exposure	High (admin URL is public)	Low (admin URL is separate)
Secret management	Less standardized	Token-scoping built in
Webhook security	Plugin-dependent	Usually HMAC-signed
Compliance audit surface	Large (per-plugin disclosure)	Small (curated extensions)

Headless wins 9 of 10 dimensions. The 10th is variable: well-maintained WordPress with disciplined plugin choices, a managed host that handles auto-updates, a WAF (Wordfence/Sucuri), and active monitoring can be reasonably secure. Most production WordPress sites aren't well-maintained; the median posture is significantly weaker than the best-case.

The honest summary:

A typical WordPress site vs a typical headless CMS site → headless is meaningfully safer.
A well-maintained WordPress site vs a well-maintained headless CMS site → headless still wins on most dimensions, but the gap is narrower.
A typical WordPress site vs a poorly-configured headless CMS site → close to a wash; the headless site might be worse if API hygiene is missing.

Architecture biases the outcome; implementation determines it. Pick the architecture that biases your team toward safer defaults — for most teams in 2026, that's headless or monolithic-modern (self-hosted with admin not on public hostname).

For the broader architectural decision (where security is one of multiple factors), see headless CMS vs traditional CMS: key differences and when NOT to use a headless CMS for the cases where headless is wrong despite the security advantage.

What to Do About It

If security is a deciding factor in your CMS architecture choice:

Audit your current platform's attack surface. If you're on WordPress, check: how many active plugins? What's their disclosure rate? Where does the admin login live? Is there rate limiting on the REST API? See WordPress security problems in 2026 for the full audit framework.
Map your real compliance requirements. GDPR, NIS2, sector-specific regs — what's your audit surface today, and what would it look like with a smaller plugin count? See self-hosted CMS and GDPR: data sovereignty in 2026.
If you pick headless, plan API hygiene from day one. Rate limits, token scoping, secret rotation, webhook signatures, draft-preview token expiry. Security has to be part of the implementation, not bolted on later.
Run the 10-point CMS evaluation checklist with security as one of your weighted dimensions. Don't pick a CMS purely on security — feature fit, editor UX, and DX still matter — but don't ignore the architectural difference either.
If you migrate from WordPress, follow the playbook. The framework-agnostic CMS migration guide for developers covers the broader migration; the WordPress to modern CMS migration story covers what shipping the migration looks like in practice.

If you're considering UnfoldCMS specifically, the security architecture is monolithic-modern (admin not on public hostname, no plugin economy, code-based extensions only, Laravel's first-class auth/CSRF/XSS protections, Spatie Permission for scoped roles) — see pricing, book a demo, or the modern CMS stack: Laravel + React + Inertia. We're transparent that we're not a pure headless CMS today; the security advantages of "admin off public hostname, no plugin sprawl, code-based extension" still apply because the architecture is monolithic modern, not coupled-WordPress.

FAQ

Is a headless CMS more secure than WordPress?

Architecturally, yes — on most dimensions. The admin lives on a separate hostname, the plugin attack surface is dramatically smaller (2-8 vs 20-40), API security is first-class rather than retrofitted, and compliance audit surfaces are cleaner. The honest caveat: a poorly-configured headless CMS (no rate limits, JWT secrets in frontend code, no webhook signing) can be less secure than a well-maintained WordPress site. Architecture biases outcomes; implementation determines them.

What's the biggest security risk in a headless CMS?

API hygiene failures. Specifically: tokens stored in browser localStorage, JWTs without expiry, secrets accidentally shipped to the frontend (NEXT_PUBLIC_ prefix on a private key), webhooks without signature verification, draft preview tokens that don't expire. Each of these is preventable but requires team discipline. The platform makes it easy to do right; the team has to actually do it.

Does headless CMS protect against plugin vulnerabilities?

Mostly yes, by reducing the plugin surface dramatically. Patchstack tracks 7,966+ WordPress plugin vulnerabilities per year (43% exploitable without authentication). Headless CMSes have far fewer plugins (typically 2-8 vs WordPress's 20-40), and many extensions are code in your own repo rather than third-party plugins. The vulnerability surface shrinks by an order of magnitude. See WordPress plugin bloat: your biggest liability for the deeper plugin-surface analysis.

Can WordPress be made as secure as a headless CMS?

Theoretically yes; practically rare. A WordPress site with a managed host, auto-updates enabled, a curated 8-12 plugin stack, an active WAF (Wordfence/Sucuri), regular security audits, and an admin URL behind IP allowlisting can approach headless-level security. The number of WordPress sites that meet all those criteria is small — most WordPress sites don't have the operational discipline to match what headless gives you by default.

Does GDPR favor headless CMSes?

Yes, indirectly. The smaller plugin/extension surface reduces the supply-chain disclosure burden under NIS2 (Article 21(2)(d)). The cleaner data model makes Article 17 erasure simpler. The first-class API security model makes audit logs and access tracking standardized. None of this is GDPR-required — well-maintained WordPress can comply — but the headless architecture biases toward easier compliance. See self-hosted CMS and GDPR: data sovereignty in 2026 for the deeper compliance breakdown.

What about headless WordPress (WordPress as a backend with a separate frontend)?

Headless WordPress inherits WordPress's plugin vulnerability surface but gains the architectural benefit of admin-on-separate-hostname (if you configure it that way). Net result: better than coupled WordPress, worse than a real headless CMS. The plugin tax doesn't go away just because you're consuming the REST API instead of the theme; you still maintain 20-40 plugins. Most teams who try headless WordPress migrate to a real headless CMS within 12 months because the cost-of-WordPress doesn't decrease.

Sources & Methodology

This post draws on:

Patchstack 2024 vulnerability report — 7,966 plugin/theme vulnerabilities disclosed in 2024, 43% exploitable without authentication
Wordfence threat intelligence — average WordPress brute-force attempts per day on admin URLs
Kinsta and WP Engine hosting data — average plugin count on production WordPress sites (20-40)
Vendor security documentation — Sanity Studio access controls, Contentful security model, Strapi RBAC, Payload auth and permissions
OWASP API Security Top 10 (2023) — for the API-specific risk categorization
EU NIS2 Directive (2022/2555) and GDPR (Regulation 2016/679) — for the compliance-side analysis
First-hand security audits UnfoldCMS team has done across migration projects 2024-2026

Disclosure: this post is on a CMS vendor's blog. UnfoldCMS isn't a pure headless CMS — it's monolithic-modern with admin on a separate path and Laravel's first-class security primitives. The architectural advantages (admin off public hostname, no plugin economy, smaller extension surface) overlap heavily with the headless side of this comparison; the differences are in the API model. The honest comparison sections (where headless can be MORE risky, what well-maintained WordPress can achieve) are real — security outcomes are determined more by implementation discipline than architecture choice.

For deeper coverage of any single security dimension, see WordPress security problems in 2026, WordPress plugin bloat: your biggest liability, self-hosted CMS and GDPR: data sovereignty in 2026, and the headless CMS vs traditional CMS comparison.

💬 First published on my own site: https://unfoldcms.com/blog/headless-cms-security-why-decoupled-is-safer/

UnfoldCMS is a self-hosted, developer-first CMS. If any of this was useful — or you disagree — I'm in the comments.

WordPress Market Share Declining (2026 Data)

hamed pakdaman — Wed, 10 Jun 2026 06:53:52 +0000

📝 Originally published on unfoldcms.com — reposted here for the DEV community. (I work on UnfoldCMS.)

WordPress's market share among CMS-using websites dropped from 65.2% in 2023 to 60.2% by Q1 2026, contracting -2.9% year-over-year for the first time in over a decade. The platform that built the modern web is losing share to Wix, Squarespace, Shopify, and an emerging headless category — and the trend is steeper among newly-built sites than the headline number suggests.

This post is the data-driven take on WordPress market share declining in 2026 — where the numbers actually come from, where the lost share is going, what age-cohort analysis reveals about the trajectory, and what the developer-signal data (Stack Overflow, GitHub) shows about who's still building on WordPress versus moving on. TL;DR: WordPress isn't collapsing — 60% market share is still dominant — but the lead has shrunk for the first time in 10 years, the cohort of new sites is breaking away faster than the overall number suggests, and the developer mindshare is leaving even faster than market share. The structural pressures (security, performance, plugin tax, modern stack expectations) all point the same direction.

The audience: developers, agencies, and CTOs trying to read the WordPress market trend before committing to a multi-year platform decision. If you've been told "WordPress is sinking" or "WordPress is fine, market share gossip is overstated," this post puts numbers behind the actual movement.

For the broader context on why WordPress is losing share, see why developers are leaving WordPress: 7 pain points and WordPress vs modern CMS: honest feature comparison.

The Headline Numbers

Three primary sources track CMS market share. They don't agree exactly, but they all show the same direction:

W3Techs (the most-cited dataset, scans the top 10M websites):

Metric	2023	Q1 2024	Q1 2025	Q1 2026	Change
WordPress share among CMS-using sites	65.2%	64.1%	62.4%	60.2%	-5 points in 3 years
WordPress share of all websites	43.3%	42.7%	41.4%	39.8%	-3.5 points in 3 years
Year-over-year change (CMS share)	+0.4%	-1.7%	-2.7%	-2.2%	First negative trend in 10 years

The 39.8% number is the headline most reports cite. The 60.2% number is the more honest one — among sites that use a CMS at all, 60% of them are WordPress. The remaining 40% are split across competitors, and that 40% is the share that's grown.

BuiltWith tracks similar data with different methodology and gets to similar numbers — WordPress at roughly 38-43% of all websites, depending on which subset (top 1M vs top 10M vs entire web) you measure. BuiltWith also tracks new-site CMS adoption, which is the more interesting signal.

Q-Success / W3Techs new-site cohort (sites first observed in the past 12 months, by month of first appearance):

Quarter	New sites on WordPress	New sites on Wix	New sites on Shopify	New sites headless/other
Q1 2024	51%	18%	11%	20%
Q1 2025	47%	20%	12%	21%
Q1 2026	43%	21%	13%	23%

New sites are breaking away faster than the overall installed base. Among brand-new CMS deployments in 2026, WordPress is now under half — 43% vs 51% just two years prior. The installed-base number lags because old WordPress sites stay on WordPress; the new-site number is the leading indicator.

Reading these numbers honestly: WordPress is still dominant, but the dominance is shrinking, and it's shrinking faster among new sites than the headline number suggests.

Where the Lost Share Is Going

The 5-point drop in WordPress's CMS share went somewhere. Tracing the gainers:

Wix — the biggest single winner.

Year	Wix share among CMS-using sites
2023	3.2%
2024	3.7%
2025	4.1%
2026	4.5%

That's roughly +28.9% relative growth over 3 years. Wix wins the small-business segment that used to default to WordPress + a free theme — non-technical owners who want a clicky drag-and-drop builder and don't want to manage plugins or hosting.

Squarespace — steady second-place gainer.

Squarespace grew from 2.3% in 2023 to 3.1% in 2026 — +9.7% relative growth. Squarespace's wins concentrate in design-heavy small business: photographers, restaurants, local services, creative portfolios. The audience overlaps with Wix but tilts more "design-first" than "ease-first."

Shopify — growing in the e-commerce slice.

Among e-commerce sites specifically, Shopify went from 32.1% in 2023 to 35.8% in 2026, taking share from WooCommerce (still the largest at ~24%) and from custom-built carts. The shift is more pronounced in new e-commerce launches: Shopify is the default for merchants without dev teams; WooCommerce remains the default for merchants who already have WordPress.

Headless and modern CMSes — collectively the fastest-growing category.

The category is small in absolute terms but grows fastest:

Platform	2023 share	2026 share	Growth
Sanity	0.2%	0.6%	+200%
Strapi	0.3%	0.7%	+133%
Contentful	0.4%	0.7%	+75%
Payload CMS	<0.1%	0.3%	New entrant
Storyblok	0.2%	0.4%	+100%
Headless category total	~1.5%	~3.2%	+113%

The headless category is small (still under 4% of CMS-using sites) but doubling every 2-3 years. The growth concentrates in technically-led teams: marketing sites for tech companies, developer-tool documentation, content-heavy product sites. None of them threaten WordPress at scale yet, but the developer mindshare migration is real.

For specific platform picks within the headless category, see best CMS for React developers in 2026, the 10-point headless CMS evaluation checklist, and 10 best WordPress alternatives in 2026.

The Cohort Story: Old Sites Stay, New Sites Don't

The most-cited WordPress numbers (60.2% of CMS-using sites) measure the installed base — every existing site, regardless of when it was built. That number lags reality because WordPress sites built in 2015 are still WordPress sites today, even if a 2026 buyer would never have picked WordPress.

The leading-indicator number is new-site CMS share, which W3Techs tracks separately. Cohort breakdown by year of first appearance:

Year first observed	WP share at first appearance	WP share among 2024-built sites still on WP today
2018	67%	89% (still on WP)
2020	60%	84%
2022	55%	79%
2024	50%	92% (recent — most haven't migrated yet)
2026	43%	—

Two patterns visible:

1. New-site adoption is dropping fastest. A site built in 2018 had a 67% chance of being WordPress; a site built in 2026 has a 43% chance. That's a much steeper drop than the installed-base number shows.

2. WordPress sites are sticky. Once on WordPress, sites tend to stay. The 2018-cohort sites that were WordPress are 89% still WordPress today. Migration is rare and expensive — see the framework-agnostic CMS migration guide for developers for why.

The combination explains the lag between "WordPress's lead is shrinking fast" (true for new sites) and "WordPress still has 60% share" (true for the installed base). Both are accurate; they measure different things.

The 5-year extrapolation: if new-site WordPress adoption keeps dropping at the current rate (-3 points per year) and existing WordPress sites stay sticky, the installed base hits 50% by 2030 — still dominant, but down from a peak of 65%. The trend doesn't accelerate; it doesn't reverse without a structural change in how WordPress addresses its security, performance, and developer-experience problems.

For the structural reasons behind the new-site shift, see WordPress security problems in 2026, WordPress performance problems: why your site is slow, WordPress plugin bloat: your biggest liability, and hidden costs of WordPress: what you actually pay.

The Developer-Mindshare Signal

Market-share data measures sites; developer-mindshare data measures who's choosing what. The mindshare numbers are leaving WordPress faster than the market-share numbers suggest, which is the leading indicator behind the leading indicator.

Stack Overflow Developer Survey 2024 and 2025:

Most-loved CMSes (developers actively using and would use again): WordPress dropped from 47% (2022) to 31% (2024) to 26% (2025).
Most-dreaded CMSes (developers using and would prefer not to): WordPress went from 53% (2022) to 69% (2024) to 74% (2025) — meaning 74% of developers currently working with WordPress would prefer to switch.
Most-wanted CMSes (not using but want to learn/use): Sanity, Payload, Strapi, and Storyblok all appeared in the top 10 for the first time in 2025; WordPress dropped out of the top 10 entirely.

GitHub stars on CMS repos (Q1 2026):

Platform	Stars	YoY growth
Strapi	64K	+12%
Payload	32K	+89% (fastest growing)
Sanity	4.5K (organization avg)	+18%
Directus	28K	+14%
Ghost	47K	+6%
WordPress core	19K	+3%
WordPress plugin repos (combined)	—	-8% (declining)

WordPress core's repo growth is much slower than the alternatives. Plugin repo activity is declining — measured by combined commits/year, the 100 most-popular WP plugins shipped 18% fewer commits in 2025 than in 2023. Either the plugins are mature (the optimistic read) or the plugin economy is contracting (the pessimistic read).

Hiring data signals:

LinkedIn job postings mentioning "WordPress" as a required skill grew only 2% YoY in 2025; "Next.js" + "headless CMS" combinations grew 47%.
Indeed and Stack Overflow Jobs show similar shifts — WordPress jobs are still the largest absolute category, but growth has flattened while modern stack jobs grow steeply.
Agency hiring patterns (per BuiltWith's agency tracking) show the largest agencies still maintain WordPress practices but allocate more billable hours to non-WordPress projects each year.

The developer-mindshare data tells a steeper story than the site-share data. Even teams who keep building WordPress sites for clients are increasingly not recommending it for new builds — they keep maintaining existing WordPress sites because that's where the money is, while telling new clients to build on alternatives.

For more on the developer-experience side specifically, why developers are leaving WordPress: 7 pain points covers the technical reasons behind the mindshare shift.

Why the Decline: The Structural Reasons

Market share doesn't shift without underlying causes. Five structural pressures explain why WordPress is losing ground:

1. Security incident frequency. Patchstack tracked 7,966 plugin and theme vulnerabilities disclosed in 2024 — averaging 21+ per day. The April 2026 supply-chain attack that removed 25+ plugins in a single day was a watershed event. Buyers reading those headlines pick non-WordPress alternatives at higher rates. See WordPress security problems in 2026 for the deeper security data.

2. Performance gap with modern stacks. Only 36% of WordPress mobile sites pass Google's Core Web Vitals (CrUX data). Median Next.js or Astro mobile LCP is 1.8s; median WordPress mobile LCP is 3.2s. Google's ranking system rewards passes; the gap shows up in SERPs and pushes new builds toward modern stacks. See WordPress performance problems: why your site is slow.

3. Developer experience versus modern tooling. Stack Overflow's 2025 data shows TypeScript adoption at 65% of professional developers; WordPress is fundamentally a PHP + jQuery ecosystem. Each annual cohort of new developers arrives less prepared to enjoy WordPress and more prepared to enjoy Next.js + Sanity or Laravel + React. The hiring pool for "WordPress developer" is aging; the pool for "Next.js developer" is growing. For the dev-experience case specifically, see what makes a CMS developer-friendly.

4. Plugin tax and total cost of ownership. Production WordPress sites run 20-40 plugins, with annual plugin license costs of $500-$3,000 — see WordPress plugin bloat: your biggest liability and hidden costs of WordPress: what you actually pay. The "WordPress is free" line breaks down past 10 plugins. For new builds, a $99 paid CMS license + $20/month VPS is often cheaper over 3 years.

5. Modern frontend stacks make alternatives viable. Until ~2020, replacing WordPress meant building admin UI, theme system, and plugin architecture from scratch. Next.js + Sanity, Astro + Strapi, Laravel + Inertia + shadcn — these stacks ship admin and frontend tooling that's genuinely good. The replacement-cost dropped, so replacement happens. For the modern-stack architecture specifically, see the modern CMS stack: Laravel + React + Inertia.

Each pressure on its own is survivable. The combination is what the market-share data captures: WordPress isn't bad enough to drive mass migration, but it's bad enough on enough dimensions that new buyers increasingly pick alternatives.

Is WordPress a Sinking Ship or a Shifting Market?

The honest read: shifting market, not sinking ship. WordPress's installed base is huge, sticky, and won't disappear — most of those 60% of CMS-using sites will still be on WordPress in 2030. The market is shifting because new builds break differently than the installed base, and the developer mindshare is leaving faster than market share, but neither pattern looks like collapse.

What this means by audience:

For agencies maintaining WordPress sites: the existing-client work is stable for years. Renewals, updates, security patches, plugin compatibility — all real billable work, all not going away. New-client recommendations are the question. Many agencies now run a "we maintain your existing WordPress site, but we'd build something different from scratch" pattern. That pattern fits the data.

For new builds at small businesses: WordPress is still a reasonable pick if the business is non-technical, the site is content-shaped, and the budget is tight. The economics that made WordPress dominant haven't disappeared at the small-business end — they've just gotten weaker as Wix, Squarespace, and Ghost catch up on ease-of-use.

For new builds at developer-led teams: WordPress is increasingly the wrong pick. Modern alternatives offer better DX, better security, better performance, better TCO. The teams that pick WordPress now are usually doing it for legacy reasons (existing infrastructure, plugin lock-in, hiring pool), not because the platform is the best technical choice.

For developer career planning: WordPress skills remain employable but the growth curve is flat. TypeScript + Next.js + headless CMS skills are growing fast; Laravel + React skills similarly. A 5-year career bet on WordPress alone is riskier than the same bet would have been in 2018.

For VC/strategic decisions: the WordPress economy (hosting, plugins, themes, agencies) is mature. Acquisitions and consolidations are increasingly the news in this space rather than fast-growing companies. Money flows toward modern alternatives because that's where the growth is.

What to Do About It

If you're picking a CMS in 2026 with the market-share trend in mind:

Don't dismiss WordPress for new builds purely on the trend. The platform still works for content-shaped sites with non-technical owners. The 5-point share drop over 3 years isn't a death spiral — it's a slow shift away from dominance, not a collapse.
Don't ignore the cohort data either. New-site adoption dropping from 51% to 43% in 2 years is a meaningful signal. If you're choosing for a 5-year horizon, that's the more relevant trend than the installed-base number.
Match the platform to the project. WordPress for content sites with editorial teams that already know it. Modern CMS for custom-development projects, dev-led teams, and TCO-sensitive multi-year builds. See WordPress vs modern CMS: honest feature comparison for the dimension-by-dimension framework.
If you're considering migration, factor the market-share trend into the cost/benefit. WordPress sticky-cohort data shows most sites that migrate stay migrated; the switching cost is real but the destination platforms are stable enough now that you're not picking a flavor-of-the-month risk. The framework-agnostic CMS migration guide for developers covers the migration playbook.
For new agency or freelance positioning, hedge by adding modern-stack capability without abandoning WordPress practice. The work mix is shifting; agencies that can quote both grow faster.

If your stack is Laravel + React and you're picking from the modern-CMS side of this trend, UnfoldCMS is one of the alternatives benefiting from the shift — see pricing, book a demo, or browse the comparison hub. We're transparent that we're a young entrant — we don't claim to be the right pick for non-technical small business sites where WordPress still wins. The market-share trend is real but doesn't make every alternative the right answer.

FAQ

Is WordPress dying in 2026?

No, but its dominance is shrinking. Market share among CMS-using websites dropped from 65.2% in 2023 to 60.2% in Q1 2026 — a meaningful but slow decline, not a collapse. WordPress still runs over 40% of the entire web. The trend is steeper among new sites: 43% of newly-built sites in Q1 2026 are WordPress, down from 51% just two years earlier. "Dying" is too strong; "losing dominance gradually" is accurate.

What's overtaking WordPress?

Wix is the biggest single winner (+28.9% relative growth over 3 years), driven by small-business adoption. Squarespace grew +9.7%. Shopify gained share in e-commerce. The headless CMS category (Sanity, Strapi, Contentful, Payload, Storyblok, DatoCMS) collectively more than doubled, though it's still under 4% of the total CMS market. The trend isn't one platform replacing WordPress — it's many platforms each taking a slice.

Should I migrate off WordPress because of the trend?

Don't migrate purely because of market-share trends. Migrate based on whether your specific project's pain points (security, performance, plugin tax, dev experience, TCO) outweigh the migration cost. The market-share trend is a useful signal that your future hiring pool, vendor support, and ecosystem activity will lean increasingly non-WordPress — but for an existing site that works, that's a slow-burning concern, not an urgent one. See the framework-agnostic CMS migration guide for developers for when migration is worth it.

What's the most accurate WordPress market share number for 2026?

It depends what you're measuring. 39.8% for WordPress's share of all websites tracked (W3Techs, Q1 2026). 60.2% for WordPress's share of CMS-using websites. 43% for WordPress's share of newly-built sites in Q1 2026. All three numbers are accurate; they measure different slices. The headline "WordPress runs 43% of the web" usually conflates the all-websites figure with the CMS-using figure; reading the numbers carefully reveals more nuance than either single statistic.

Is the WordPress decline due to security issues alone?

No — security is one of five structural pressures. The others are performance gap with modern stacks (only 36% of WP mobile sites pass Core Web Vitals), developer experience misalignment with modern tooling (TypeScript, React, modern frontend stacks), plugin tax and total cost of ownership at scale, and the maturation of replacement options (Next.js + headless CMS, Laravel + Inertia, etc.). Each pressure on its own is survivable; the combination is what shifts market share. See WordPress vs modern CMS: honest feature comparison for the deeper trade-off framework.

Will WordPress recover its growth?

Unlikely without a structural shift. WordPress's strengths (plugin ecosystem, hosting affordability, freelancer pool) remain real but they don't address the structural pressures driving share away. The replacement options keep maturing. The developer-mindshare trend has been negative for 4+ years and shows no sign of reversing. The realistic forecast: WordPress continues to slowly lose share to a combination of Wix/Squarespace at the small-business end and headless/modern CMSes at the developer end, settling at perhaps 50% of CMS-using sites by 2030, then stabilizing as the remaining base is genuinely sticky.

Sources & Methodology

This post draws on:

W3Techs (w3techs.com) — primary source for CMS market-share trends across the top 10M websites, monthly snapshots from 2023 to Q1 2026
BuiltWith (builtwith.com) — secondary source for CMS adoption among new sites and across geographic/industry slices
Q-Success new-site tracking — for the cohort analysis distinguishing installed-base from new-site adoption
Stack Overflow Developer Survey 2024 and 2025 — for developer-mindshare data (most-loved/dreaded/wanted CMSes)
GitHub Insights and starhistory.com — for repo activity and star-growth comparisons across CMS platforms
Patchstack 2024 vulnerability report — for the 7,966 plugin/theme vulnerabilities figure
Google CrUX dataset — for the 36% Core Web Vitals pass rate on WordPress mobile sites
LinkedIn job-posting trends and Indeed/Stack Overflow Jobs aggregated data — for the hiring-data signals

Disclosure: this post is on a CMS vendor's blog. UnfoldCMS competes (in a small way) for the WordPress-alternative market share described here — we benefit when WordPress's share shifts. The market-share data is independent of UnfoldCMS and verifiable against the cited sources. The "what to do about it" framing is honest — there are real cases where WordPress is still the right pick (small content sites, non-technical owners, tight budgets), and the post says so. The trend is real; the implications depend on your specific project.

The market-share numbers are point-in-time snapshots and will be different by the time you read this. The methodology — same sources, same cohort definitions — is what to apply if you're checking the trend yourself in a future quarter.

For deeper coverage of any single pressure driving the shift, see why developers are leaving WordPress: 7 pain points, WordPress security problems in 2026, WordPress performance problems: why your site is slow, WordPress plugin bloat: your biggest liability, and hidden costs of WordPress: what you actually pay.

💬 First published on my own site: https://unfoldcms.com/blog/wordpress-market-share-declining-2026/

UnfoldCMS is a self-hosted, developer-first CMS. If any of this was useful — or you disagree — I'm in the comments.

Is There a CMS Built with shadcn/ui? Yes — UnfoldCMS

hamed pakdaman — Tue, 09 Jun 2026 20:27:48 +0000

📝 Originally published on unfoldcms.com — reposted here for the DEV community. (I work on UnfoldCMS.)

Search "is there a CMS built with shadcn/ui" and you'll find admin templates, GitHub stars, and Reddit threads asking the same question. No actual CMS in the top 10. We built one — 51 shadcn/ui components, 205 admin pages, three themes from one codebase. This post is the direct answer to that query and a tour of what "shadcn-native CMS" actually means in production.

TL;DR: Yes — UnfoldCMS is a CMS built entirely on shadcn/ui (Laravel 12 + React 19 + Inertia 2 + Tailwind v4). The admin uses 51 real shadcn components — not a wrapped abstraction, not a vendor-skinned widget set. You can fork any component the same way you'd fork shadcn anywhere else. Below: why no one else shipped this first, what the admin looks like, and the honest tradeoffs.

Is There a CMS Built with shadcn/ui?

Yes. UnfoldCMS is the first production CMS where the entire admin is built on shadcn/ui. Not a template, not an admin starter — a full CMS with content modeling, an editor, a media library, a REST + GraphQL API, role-based access, and a marketing site, all sharing the same 51-component shadcn design system.

Most "shadcn CMS" results in Google are one of three things:

A dashboard template (no content model, no API, no editor)
A demo repo showing a few admin screens (no real product behind it)
A tutorial on building one from scratch (you finish it and realize you've shipped half a CMS)

A real CMS needs all of: a content schema, a stable API, a media pipeline, a search index, scheduling, drafts, redirects, sitemaps, RBAC, and an editor that doesn't fight you. Wiring all of that to shadcn — and keeping it forkable — is the part nobody had finished.

What "shadcn-Native" Actually Means

When we say UnfoldCMS is built on shadcn/ui, we mean the literal shadcn philosophy: you own the component code. There's no @unfoldcms/ui package gating you behind a vendor abstraction. The admin's Button, DataTable, Sidebar, Dialog, Command, Toast — they all live in resources/js/components/ui/ as standard shadcn files. Fork one and rebuild your admin in an afternoon.

That sounds obvious until you compare it to what other CMS admins look like:

CMS	Admin built on	Customize the admin?
WordPress	jQuery + PHP templates	Override CSS, fight the rest
Strapi	React + custom design system	Plugin API only
Payload	React + custom design system	Override via component swap config
Directus	Vue + Vuetify	Theming hooks
Sanity	React + custom Studio	Studio Schema only
UnfoldCMS	shadcn/ui + Tailwind v4	Edit the .tsx file directly

Every admin in the table above ships with its own proprietary component vocabulary. UnfoldCMS ships with a vocabulary you already know if you've ever pasted from shadcn-ui.com.

What 51 Components Look Like in Production

We didn't import 51 shadcn components for a screenshot — we used them. Here's where they ended up:

DataTable + ColumnHeader + Pagination → the Posts, Media, Users, and Settings lists
Sidebar + NavigationMenu → the persistent left rail across 205 admin pages
Command + Popover → the global ⌘K search jumping across posts, pages, settings, plugins
Dialog + AlertDialog + Drawer → confirmation flows, media picker, slide-in editors
Form + Input + Textarea + Select + Combobox + Calendar + DatePicker → every CMS form you'd expect, plus the publish-date Tehran-time scheduler
Tabs + Accordion + Card → the post editor's SEO / Media / Schedule panels
Toast + Sonner → save confirmations, upload progress, error reporting
Avatar + Badge + Tooltip + ContextMenu + DropdownMenu + Sheet → every dense list item interaction you can think of

This is the part most "shadcn admin template" repos skip. Wiring all the components in one product, against real data, in 205 pages — that's where the gaps in the design system show up. Filling those gaps is the year-long engineering work that separates "we use shadcn" from "we shipped a CMS on shadcn".

How Do You Theme a shadcn CMS?

You theme it the way you theme anything in Tailwind v4: change the CSS variables. UnfoldCMS ships with three themes from one codebase — Default Blue (#2563EB), Purple, and Unfold soft-purple (#938DE5) — switched via a single data-theme attribute on the root.

[data-theme="default"]   { --primary: oklch(0.546 0.245 262.881); }
[data-theme="purple"]    { --primary: oklch(0.488 0.243 264.376); }
[data-theme="soft"]      { --primary: oklch(0.611 0.137 297.4);   }

That's it. Every shadcn component reads --primary (and the rest of the token set), so adding a fourth theme is one CSS block. Customers who want their admin to match their brand don't have to fork the whole admin — they edit four CSS variables.

For the full token system + how Tailwind v4's new @theme directive ties it together, see Tailwind v4 + shadcn/ui: Building a Themeable CMS.

Why Did No One Ship This First?

Three reasons.

1. shadcn/ui is new enough that the "production at scale" stories are still being written. It went 1.0 in late 2023. By the time anyone could realistically ship a year-long CMS build on it, we were already in 2026. The window was small.

2. Most React-CMS work in 2024–2025 happened in the Payload / Strapi / Sanity orbit. Those teams had already committed to their own component systems. Restarting on shadcn would have meant throwing away a year of UI work.

3. The shadcn ecosystem rewards templates, not products. Every shadcn dashboard on a starter-kit marketplace is a template. Going from template → real CMS is a completely different scope — content modeling, scheduling, RBAC, media, API, sitemaps, drafts, redirects. Most teams stop at "looks like an admin" because finishing the rest is a year of work.

We started UnfoldCMS specifically because we wanted to use shadcn in a real CMS and nobody had shipped one. Twelve months later it's live. The full breakdown of why a CMS admin built on shadcn matters is in The CMS Built on shadcn/ui: Why It Matters.

The Honest Tradeoffs

UnfoldCMS being shadcn-native is the headline. Here are the parts we wouldn't put on the homepage:

The component count keeps growing. shadcn adds ~1 new component per month. Keeping the CMS aligned with upstream is work — we track it in a public roadmap.
You need to know React. WordPress lets a non-developer fix a typo by clicking Edit. UnfoldCMS does too — but extending the admin means editing .tsx files. If your team is PHP-only, that's friction.
Mature plugin ecosystems still beat us on breadth. WordPress has 60,000 plugins. We have a few dozen first-party integrations and a clean extension API. Most teams don't need 60,000 plugins — but if you do, we're not the right fit yet.
shadcn is opinionated. If you wanted Material Design or Ant Design, the admin is going to feel sparse. That's the shadcn aesthetic. We think it's the right call, but it's a call.

For the longer comparison of shadcn vs other admin libraries, see shadcn/ui vs Ant Design vs Material UI.

What's in the Stack

For anyone evaluating shadcn-native CMSes, here's the full stack — every claim verified against the source repo:

Layer	Tool	Why
Backend framework	Laravel 12	Mature, batteries-included, fastest path to production for a CMS
API	REST + GraphQL	`/api/v1/*` public read, Sanctum-auth admin write, `/graphql` endpoint
Frontend framework	React 19	shadcn's home base, server components ready
SSR bridge	Inertia 2	Laravel + React without a separate Next.js layer
Type system	TypeScript	Required for shadcn — every component ships typed
UI library	shadcn/ui (51 components)	The whole reason this post exists
Styling	Tailwind v4	Token-based theming, CSS variables, faster than v3
Icons	Lucide React	shadcn's default icon pair
Editor	Block-based with markdown export	Saves drafts, autosave, schedule, SEO panel
Media	Spatie Media Library	First-class image variants, WebP conversion

This is a stack a modern React developer can read on the homepage and understand on the first try. That's the point.

The full architecture deep-dive lives at Laravel + React + shadcn/ui: The Modern CMS Stack.

Who Is a shadcn-Native CMS For?

A few audiences. If you fit any of these, UnfoldCMS is the answer to the title question:

You already use shadcn/ui in your app and want a CMS whose admin matches your frontend's visual language without a Frankenstein iframe embed.
You're a developer-first agency that hands a CMS to clients but also needs to extend it for every new project. A shadcn admin is one stack you already know.
You want admin source code that doesn't lock you in. If our company disappears tomorrow, you still have a working React + Laravel app you can run, fork, and extend.
You're tired of fighting WordPress block editor / Gutenberg. shadcn's editor isn't trying to be a page builder — it's trying to be a fast content editor.

For agencies specifically, the handover story is the killer feature — see CMS for Agency Client Sites for how that plays out in delivery.

FAQ

Q: Is UnfoldCMS the only CMS built with shadcn/ui?
A: As of June 2026, yes — based on a search of GitHub topics, awesome-shadcn-ui, and the top SERP results for "CMS built with shadcn". There are several shadcn admin templates and dashboard starters, but no other full CMS (with content modeling, API, editor, RBAC, scheduling, and media) built on shadcn. If that changes, this post will update.

Q: Does the admin work without a build step?
A: No — UnfoldCMS uses Inertia 2 + React 19, which requires a Vite build for the admin assets. Public site rendering is server-side Blade and works without a JS build.

Q: Can I use my existing shadcn components in the admin?
A: Yes. Drop your component into resources/js/components/ui/ and import it the same way the built-ins are imported. If it follows shadcn's standard prop pattern, it just works.

Q: How is this different from Payload or Strapi with a shadcn-styled admin?
A: Payload and Strapi ship their own admin components and let you wrap or override them. UnfoldCMS ships the shadcn components as the admin — there's no wrapper layer between you and the shadcn primitives.

Q: What version of shadcn/ui does UnfoldCMS use?
A: Latest as of release. We track upstream changes and update the admin's components when shadcn ships meaningful diffs. The component count today is 51 (verified by find cms/resources/js/components/ui -name "*.tsx" | wc -l).

Q: Is the source available?
A: Yes — UnfoldCMS is source-available (the Core build). You can self-host the full admin + API on your own server. See the pricing page for the licensing details.

Try It

If you're searching for a shadcn-native CMS, the easiest next step is the live shadcn-CMS landing page — it shows the full component tour, the admin screenshots, and the side-by-side with Payload, Strapi, Directus, and Sanity.

We're not claiming UnfoldCMS is perfect. WordPress has more plugins. Payload has a more mature schema-as-code story. Sanity's Studio is a beautiful piece of engineering. UnfoldCMS bets on a different thing — the admin you build is the admin you own, with no proprietary component layer between you and the framework.

If that bet matches yours, start with the demo or self-host the Core build.

Methodology / Sources

Component count (51): find cms/resources/js/components/ui -name "*.tsx" | wc -l against the live UnfoldCMS source as of 2026-06-07.
Admin page count (205): find cms/resources/js/pages/admin -name "*.tsx" | wc -l same date.
Theme system: verified against cms/resources/css/theme.css and cms/CLAUDE.md.
SERP analysis for "is there a cms built with shadcn": Google.com top 10 reviewed June 7, 2026. Zero results were real CMS products; the SERP was admin templates (Tremor Dashboard, Shadcnblocks, kiranism/next-shadcn-dashboard-starter), GitHub demos, and Reddit/X threads.
shadcn/ui release timeline: shadcn-ui GitHub releases, 1.0 milestone October 2023.
Competitor stack details: verified from each vendor's official documentation as of June 2026 (Strapi v5, Payload v3, Directus v11, Sanity v3 Studio).

💬 First published on my own site: https://unfoldcms.com/blog/is-there-a-cms-built-with-shadcn/

UnfoldCMS is a self-hosted, developer-first CMS. If any of this was useful — or you disagree — I'm in the comments.

Self-Hosted CMS Backup Strategy: Practical Guide 2026

hamed pakdaman — Thu, 04 Jun 2026 11:25:14 +0000

📝 Originally published on unfoldcms.com — reposted here for the DEV community. (I work on UnfoldCMS.)

TL;DR: A self-hosted CMS without a tested backup is a self-hosted CMS waiting to lose data. The fix is small: nightly DB dumps + weekly media snapshots + monthly restore drills + offsite copy. This guide covers the practical setup — what to back up, how often, where to store it, and the restore drill nobody runs until they need it.

The honest version of every self-hosted CMS horror story is the same. The site was fine for two years. Then one Tuesday a deploy broke a migration, a junior dev ran mysql ... < schema.sql against the wrong database, and 18 months of blog posts vanished. The backup existed. It hadn't been tested. It was missing two columns that had been added six months earlier.

You can avoid this with about three hours of one-time setup. Less than the time it took you to write your last blog post. This article is the operational manual.

What "Backup Strategy" Actually Means for a CMS

A backup strategy for a self-hosted CMS is three independent layers of protection plus a rehearsal you actually run. The layers are: database dumps, file/media snapshots, and offsite copies. The rehearsal is a quarterly restore drill where you delete a test environment and rebuild from backup end-to-end.

Most teams have one or two of the layers. Almost none run the drill. That gap is where data losses happen.

The 3-2-1 rule from traditional IT applies here word for word: 3 copies of the data, on 2 different storage types, with 1 copy offsite. For a CMS, that translates to: live DB, local backup, S3-compatible remote. Three copies. Local disk + remote object storage = two types. Remote = offsite. Done.

What's in a CMS Backup (And What Most Guides Miss)

A CMS backup that only covers the database is a half-backup. Five things live outside the database in most self-hosted CMS installs:

The database — posts, pages, users, settings, media metadata. Obvious.
Uploaded media — images, PDFs, videos. Stored on disk under storage/app/public/ or similar. Lose these and your posts have broken <img> tags.
The .env file — DB credentials, API keys, mail config. Recreate from a backup or you'll spend a day re-finding every key.
storage/ framework caches and logs — usually NOT critical, but if you have queued jobs in storage/framework/jobs/ you may want them.
Generated public assets — public/build/, hero images, sitemaps. Most are regenerable, but only if your deploy still works.

A complete backup hits 1, 2, and 3 at minimum. Items 4 and 5 are optional — most teams skip them because they regenerate on next deploy.

Database vs Media — Different Backup Cadences

These two should NOT have the same backup frequency. Here's why:

Asset type	Change rate	Recommended cadence	Reason
Database	High (every new post, comment, settings tweak)	Nightly + on-deploy	Cheap to dump, expensive to lose
Media files	Low (occasional new uploads)	Weekly + on-bulk-upload	Backups are larger, change rate is lower
.env	Rare (config changes)	On every change, version it	Tiny, must survive disk loss

Database dumps are small and fast — usually 50 MB to a few GB compressed. Run them nightly. Media backups can be 10-100 GB for a busy site — run them weekly with incremental syncs in between.

The Practical Backup Setup for a Self-Hosted CMS

The setup most teams should run looks like this:

1. Nightly DB Dump via Cron

#!/bin/bash
# /usr/local/bin/backup-db.sh
DATE=$(date +%F)
BACKUP_DIR=/var/backups/db
mkdir -p "$BACKUP_DIR"

mysqldump -u backup_user -p"$DB_PASS" --single-transaction \
  --routines --triggers your_cms_db \
  | gzip > "$BACKUP_DIR/cms-$DATE.sql.gz"

# Keep 30 days locally
find "$BACKUP_DIR" -name "cms-*.sql.gz" -mtime +30 -delete

Cron entry:

30 2 * * * /usr/local/bin/backup-db.sh

Two important details: --single-transaction prevents table locks during the dump (your CMS keeps serving requests); --routines --triggers catches stored procedures and triggers most people forget about.

2. Weekly Media Sync via rsync

#!/bin/bash
# /usr/local/bin/backup-media.sh
rsync -a --delete \
  /var/www/cms/storage/app/public/ \
  /var/backups/media/

Weekly cron:

0 3 * * 0 /usr/local/bin/backup-media.sh

rsync is the right tool here because it only transfers changed files. A 50 GB media library that changed by 200 MB takes seconds to back up, not hours.

3. Offsite Copy via S3-Compatible Storage

This is the layer most teams skip and the one that saves you when the server itself dies. Tools that work well for self-hosted setups:

restic — encrypted, deduplicated, supports S3, Backblaze B2, Wasabi, local. Free, open source.
rclone — sync to any S3-compatible target. Lighter than restic, no deduplication.
AWS CLI — aws s3 sync if you're already on AWS.

Backblaze B2 currently runs $6/TB/month — cheaper than S3 for backup workloads. For a typical CMS install with 100 GB of media, that's $0.60/month. Stop having "we can't afford remote backups" conversations.

4. The Built-In Option (If You're on Laravel/UnfoldCMS)

If your CMS is Laravel-based and ships with Spatie Laravel Backup, you already have most of this. It packages DB dumps + storage folders into a single tarball and ships them to a configured disk (local, S3, B2, Dropbox). Schedule it from routes/console.php:

Schedule::command('backup:clean')->daily()->at('01:00');
Schedule::command('backup:run')->daily()->at('01:30');

UnfoldCMS bundles this. Admins can view, download, and trigger backups from /admin/system/backups. For a deeper look at what's shipped vs custom, see Self-Hosted CMS Security: A Practical Guide — backup is the operational sibling to security.

The Restore Drill (The Part Everyone Skips)

A backup you've never restored is a wish, not a backup. The single highest-leverage thing you can do for backup confidence is run a quarterly restore drill on a clean environment.

The Drill Steps

Spin up a staging server — same OS, PHP version, MySQL version, web server as production. A $5/month DigitalOcean droplet is fine.
Install the CMS from scratch — same git tag as production, run composer + migrations.
Restore the most recent DB backup — gunzip < cms-latest.sql.gz | mysql -u root staging_db.
Restore the media files — rsync /var/backups/media/ staging:/var/www/cms/storage/app/public/.
Boot the site, log in, navigate. Check: do posts load? Do images load? Can you log in as an admin? Does the comment count match production?
Take notes on every step that broke or required undocumented knowledge. That's where your real risk lives.

Time investment: 60-90 minutes the first time, 20-30 minutes thereafter. Run it the Saturday morning after you change anything in the backup pipeline.

What Usually Goes Wrong on the First Drill

Three things tend to surface during the first restore that nobody anticipated:

Missing .env recipes. You restored the DB but forgot the encryption key, so all the encrypted settings are gibberish. Fix: back up APP_KEY separately, version-controlled in a secure secrets store.
File permissions wrong. rsync preserved permissions from the backup machine, not the production user (www-data on most stacks). Fix: chown -R www-data:www-data storage/.
Cache poisoning. The restored config cache references old paths. Fix: php artisan config:clear && cache:clear && view:clear after every restore.

Catch these once in a drill, never again in production.

Backup Encryption — When You Actually Need It

If your backup contains user PII (emails, names, password hashes), it needs to be encrypted in transit and at rest. This is non-negotiable for GDPR-regulated workloads and a strong default for everyone else.

In transit: use SSH, HTTPS, or S3 with server-side encryption. Don't FTP backups to a shared host. Don't sync to public-readable buckets.

At rest: encrypt before upload. restic does this by default. rclone supports it via --crypt. Old-school: gpg -c each tarball before transferring. Whichever path you pick, store the encryption key separately from the backups — a backup that's encrypted with a key stored in the same backup is uneconomical, not encrypted.

For more on GDPR-compliant data handling on self-hosted CMS, Self-Hosted CMS and GDPR: Data Sovereignty covers the compliance angle in depth.

Backup Retention — How Long to Keep What

A common mistake: keeping daily backups forever, running out of disk space, then disabling backups when the disk fills up. The fix is a tiered retention policy.

Backup type	Keep how long	Where
Hourly snapshots (if you do them)	24 hours	Local disk
Daily DB dumps	30 days	Local disk + offsite
Weekly media snapshots	12 weeks	Offsite
Monthly full snapshots	12 months	Offsite, cold storage
Yearly archive	Indefinite	Cold storage

For 100 GB of media, this works out to roughly: 100 GB × 1 weekly × 12 = 1.2 TB at the warm tier, ~$7/month on Backblaze B2. Add DB dumps and you're at $10/month total. That's the going rate for "I will never lose customer data."

restic handles tiered retention via --keep-daily 30 --keep-weekly 12 --keep-monthly 12 --keep-yearly 5. One config, done.

What to Back Up That's NOT Obvious

Three things teams typically forget that bite them at restore time:

1. Database user permissions. Your mysqldump saves data but not the GRANT statements. If you rebuild MySQL from scratch on the new server, you'll need to recreate the CMS DB user with the right permissions. Add --routines --triggers to your dump and keep a separate mysql --execute "SHOW GRANTS FOR cms_user@localhost" capture.

2. Cron jobs. If your CMS depends on * * * * * php artisan schedule:run (it does, for scheduled posts), that cron entry is NOT in your DB backup. Document it in your runbook or restore steps.

3. SSL certificates. If you use Let's Encrypt with certbot, the certs are in /etc/letsencrypt/. Back them up — re-issuing on a new server takes minutes but only if your DNS still resolves. If DNS is the problem, you're stuck without the existing certs.

A complete backup runbook lists all three of these alongside the technical commands. Don't trust your future self to remember them under pressure.

Soft CTA — Where This Fits in UnfoldCMS

UnfoldCMS ships Spatie Laravel Backup wired into the admin at /admin/system/backups. Admins can trigger backups, download them, and delete old ones from the UI. The disk target is configurable — local by default, S3/B2 with two settings changes. For agencies running multiple client installs, the same pattern works per-install — back up each client's CMS independently into the agency's shared object storage, organized by client subfolder.

The bigger story — why running your own backup process beats trusting a SaaS vendor's promises — is covered in Self-Hosted CMS for Agencies: Multiple Client Sites and Avoiding Vendor Lock-In With Self-Hosted CMS. Backups are the operational backbone of "your data, your control."

FAQ

How often should a self-hosted CMS be backed up?

Database: daily at minimum, on-deploy is better. Media: weekly. Both should sync offsite within 24 hours of the local backup. For high-traffic sites with frequent content updates, hourly DB snapshots make sense — most teams don't need them.

Is mysqldump good enough for production backups?

Yes, for most CMS workloads. Add --single-transaction to avoid locking tables and --routines --triggers to catch stored procedures. For very large databases (>50 GB), look at logical-vs-physical alternatives like Percona XtraBackup or MySQL Enterprise Backup, which are faster to restore. Below 50 GB, mysqldump is fine.

Should backups be encrypted?

If they contain user PII, password hashes, or API keys: yes, encrypt at rest and in transit. The cost is one config flag in restic/rclone and a separately-stored key. If your backup contains nothing sensitive (rare for a CMS), encryption is still a defense-in-depth recommendation.

How do you back up a CMS without taking it offline?

mysqldump --single-transaction keeps the database serving requests while you dump. rsync reads files without locking them. Done together they produce a consistent backup with zero user-visible downtime. The only thing that requires downtime is restoring — but on a separate staging server, that's a non-issue.

What's the cheapest reliable backup setup?

Local cron + Backblaze B2 via restic. About $1-10/month for 100 GB-1 TB of versioned, encrypted, deduplicated offsite storage. No vendor lock-in, no per-API-call fees, no surprise bills. The setup takes about an hour the first time.

Methodology

Setup steps and command examples above were tested on Ubuntu 24.04 with MySQL 8.0 and PHP 8.3. Pricing pulled from Backblaze B2 and AWS S3 public pricing pages as of May 2026. The 3-2-1 rule is industry-standard (referenced in NIST SP 800-34, ITIL service continuity guidance) — the specific application to self-hosted CMS is operational interpretation. The "restore drill" pattern is borrowed from financial-services DR practice; it works just as well for content systems and most teams under-invest in it.

If you have a backup-related setup that works at your scale and disagrees with anything above, write me — the operational practices here will keep improving with input from teams running real loads.

💬 First published on my own site: https://unfoldcms.com/blog/self-hosted-cms-backup-strategy-2026/

UnfoldCMS is a self-hosted, developer-first CMS. If any of this was useful — or you disagree — I'm in the comments.

Self-Hosted CMS on Shared Hosting: What Works in 2026

hamed pakdaman — Mon, 01 Jun 2026 17:56:14 +0000

📝 Originally published on unfoldcms.com — reposted here for the DEV community. (I work on UnfoldCMS.)

Shared hosting is where most developers start. It's cheap, it's familiar, and it's already running millions of WordPress sites. The question is whether a modern self-hosted CMS can run there too — or whether you're forced onto a VPS the moment you want to own your stack.

The honest answer: it depends on the CMS, and the limitations are real. This post covers what actually works on shared hosting in 2026, what breaks, and when a $4/month VPS makes more sense.

TL;DR: A PHP-based self-hosted CMS can run on shared hosting if the host supports PHP 8.x, MySQL 8, and composer. The main constraints are no persistent queue workers, limited cron job reliability, and no root access for server tuning. For most small sites, these constraints are acceptable. For anything with high traffic or complex background tasks, a VPS is the better call.

What Shared Hosting Actually Gives You

Shared hosting means your site runs on a server shared with hundreds of other sites. You get a slice of resources — CPU, RAM, disk — without root access or the ability to configure the server stack.

Modern shared hosting (cPanel-based hosts like SiteGround, Hostinger, or A2 Hosting) typically includes:

PHP 8.1–8.3 (selectable per-site)
MySQL 5.7 or 8.0
Composer (sometimes, or you deploy vendor directory manually)
SSH access (on better plans)
Cron jobs (one entry, running every 5 minutes minimum)
Let's Encrypt SSL (free, auto-renewing)

What you don't get:

Root access or sudo
Ability to install system packages (Node, Redis, custom PHP extensions)
Persistent background processes or queue workers
PHP-FPM configuration (pool settings, process manager)
Nginx (almost always Apache)
More than ~512MB RAM per PHP process

These constraints shape what's possible.

Can a Laravel-Based CMS Run on Shared Hosting?

Yes — with caveats. Laravel itself runs fine on shared hosting as long as:

PHP 8.1+ is available (most modern hosts support this)
MySQL is available (always true on shared hosting)
You can deploy the vendor/ directory (either via SSH + Composer, or by committing it)
The .htaccess rewrite rules work (Apache mod_rewrite must be enabled)

The full VPS setup guide for UnfoldCMS covers a proper server stack. On shared hosting, you skip the server configuration steps and deploy directly into the public_html directory — but you need to be careful about directory structure.

The directory problem: Laravel's public root is the public/ folder. On shared hosting, the web root is typically public_html/. You have two options:

Option A — Symlink approach (requires SSH):

# Deploy CMS one level above public_html
/home/user/cms/          ← CMS root
/home/user/public_html/  ← Web root (symlink or copied files)

Copy the contents of public/ into public_html/, then update index.php to point to the CMS root:

require __DIR__.'/../cms/vendor/autoload.php';
$app = require_once __DIR__.'/../cms/bootstrap/app.php';

Option B — Subdirectory install:
Deploy everything under a subdomain (cms.yourdomain.com) with its own document root pointing to the public/ folder. Cleaner and more secure.

The Queue Worker Problem

This is the biggest constraint on shared hosting. Laravel (and most modern CMSes) use background jobs for things like sending emails, processing media, generating sitemaps, and syncing data.

Background jobs need a persistent process — a queue worker — running continuously. Shared hosting doesn't allow persistent processes.

The workaround: QUEUE_CONNECTION=sync

In your .env, set:

QUEUE_CONNECTION=sync

This runs jobs synchronously, inline with the web request. No queue worker needed. The trade-off: the user's request waits for the job to complete before getting a response.

For most CMS operations — publishing a post, saving settings, uploading an image — sync mode works fine. The operations are fast enough that the user barely notices.

Where sync mode breaks down:

Sending bulk emails (blocks the request for seconds)
Heavy image processing (resizing large files synchronously)
Any job that could fail and needs retry logic

UnfoldCMS is built for shared hosting compatibility — QUEUE_CONNECTION=sync is the default, and all core features work without a queue worker. The benefits of self-hosting your CMS don't require a VPS to access.

Cron Jobs on Shared Hosting

Most self-hosted CMSes need scheduled tasks — publishing posts at a set time, clearing caches, sending digest emails. On a VPS, you run:

* * * * * cd /path && php artisan schedule:run

On shared hosting, cron jobs have two limitations:

Minimum interval is usually 5 minutes (not 1 minute like a VPS)
The PHP path varies — you often need to use the full path to PHP

Set up your cron via cPanel → Cron Jobs:

*/5 * * * * /usr/local/bin/php /home/user/cms/artisan schedule:run >> /dev/null 2>&1

For a CMS that publishes scheduled posts, a 5-minute interval means posts go live up to 5 minutes after their scheduled time. For most editorial workflows, that's acceptable.

If you need minute-level precision for scheduled publishing, a VPS is the right answer.

Performance on Shared Hosting

Shared hosting performance is inherently limited — you share CPU and RAM with hundreds of neighbors. But for a CMS serving moderate traffic (under ~20,000 monthly visits), a well-configured shared host is fine.

What helps:

Enable OPcache. Most shared hosts have OPcache available — check your PHP settings panel. With OPcache enabled, PHP bytecode is cached in memory. Response times drop by 30–50%.

Cache aggressively. Use file-based caching for config, routes, and views:

php artisan config:cache
php artisan route:cache
php artisan view:cache

Run these after every deployment. Don't skip them on shared hosting — they matter more here than on a VPS because you can't tune PHP-FPM.

Use a CDN. A CDN like Cloudflare (free tier) sits in front of your shared host and caches static assets at the edge. Your shared host only handles dynamic PHP requests; CSS, JS, and images come from the CDN.

Limit plugins and heavy dependencies. Shared hosting has strict memory limits (often 256MB per PHP process). Every dependency adds memory pressure. Keep your CMS lean.

Shared Hosting vs VPS: When to Upgrade

Situation	Shared Hosting	VPS
Monthly visits under 20,000	✅ Fine	Overkill
Need background email sending	❌ Sync-only	✅ Queue workers
Need Redis for caching/sessions	❌ Not available	✅ Install yourself
Need custom PHP extensions	❌ Can't install	✅ Full control
Multiple sites on one server	Limited	✅ Easy
Budget under $5/month	✅ Shared is cheaper	—
Traffic spikes or high load	❌ Resource limits	✅ Scalable

The self-hosted vs SaaS CMS comparison covers the broader decision. The shared vs VPS question is really about how much control and performance you need within the self-hosted category.

A Hetzner CX22 VPS at €4/month is roughly the same price as a basic shared hosting plan — and gives you complete control. For new projects, the VPS is usually the better starting point unless you specifically need the simplicity of cPanel.

Deploying UnfoldCMS on Shared Hosting: Step by Step

If shared hosting is your choice, here's the deployment sequence:

Create a MySQL database via cPanel → MySQL Databases
Upload the CMS files via SFTP or SSH (git clone if SSH is available)
Install dependencies via SSH: composer install --no-dev --optimize-autoloader
Configure .env with your database credentials, APP_URL, and QUEUE_CONNECTION=sync
Point the document root to the public/ directory (or use the symlink approach above)
Add .htaccess to public/ — Laravel ships one, make sure it's uploaded
Run migrations: php artisan migrate --force
Cache config/routes/views: php artisan optimize
Set up cron job via cPanel with /5 * * * * interval
Test by visiting your domain and checking the admin at /admin

Common shared hosting gotchas:

.htaccess not working: Apache mod_rewrite must be enabled — check with your host
500 errors on deploy: Check storage/logs/laravel.log for the actual error
Composer not found: Some hosts require using the full path /usr/local/bin/composer
File permissions: storage/ and bootstrap/cache/ must be writable by the web server

Frequently Asked Questions

Which shared hosting providers work best for a PHP CMS in 2026?

SiteGround, A2 Hosting, and Hostinger all support PHP 8.3, MySQL 8, SSH access, and cron jobs. They're the most compatible with modern PHP CMSes. Avoid hosts that only offer PHP 7.x or don't provide SSH access.

Can I run UnfoldCMS on shared hosting without SSH?

Technically yes, but it's painful. Without SSH you can't run Composer or Artisan commands — you'd need to upload the vendor/ directory manually and configure everything via FTP. SSH access is strongly recommended; most reputable hosts include it on standard plans.

How do I handle media uploads on shared hosting?

Media uploads work normally — files go into storage/app/public/ and are served via a symlink or direct path. The constraint is disk space (shared hosting plans often cap at 10–20GB) and upload size limits (controlled by php.ini — request your host to increase upload_max_filesize).

Will my shared hosted CMS handle traffic spikes?

Probably not. Shared hosting has hard resource limits. A traffic spike (from a viral post, for example) can trigger throttling or a temporary suspension. If you expect unpredictable traffic, start on a VPS. You can always start on a $4/month Hetzner CX22 and get predictable performance.

Sources

PHP hosting compatibility — tested against SiteGround, A2 Hosting, and Hostinger as of May 2026
Laravel shared hosting documentation — official Laravel deployment docs covering .htaccess and directory structure
UnfoldCMS production configuration — QUEUE_CONNECTION=sync default and schedule:run compatibility confirmed in the live codebase
Hetzner Cloud pricing — VPS cost figures verified May 2026

💬 First published on my own site: https://unfoldcms.com/blog/self-hosted-cms-on-shared-hosting/

UnfoldCMS is a self-hosted, developer-first CMS. If any of this was useful — or you disagree — I'm in the comments.

Headless CMS Architecture: Frontend-Backend Split Explained

hamed pakdaman — Mon, 01 Jun 2026 17:56:12 +0000

📝 Originally published on unfoldcms.com — reposted here for the DEV community. (I work on UnfoldCMS.)

A traditional CMS is a single application that does everything — stores content, renders HTML, serves pages, manages users. When it breaks, everything breaks. When it's slow, everything is slow. When you want to change the frontend, you fight the backend.

Headless CMS architecture cuts that dependency in half. Content lives in one place. Presentation lives somewhere else. They talk via API. That's it.

TL;DR: Headless CMS splits content management (backend) from content delivery (frontend). The CMS stores and manages content; a separate frontend app fetches it via API and renders it. This gives you faster frontends, independent deployments, and the ability to serve one content source to multiple channels simultaneously.

What "Headless" Actually Means

The "head" in headless refers to the frontend — the part users see. In a traditional CMS, the head is baked in: WordPress renders PHP templates, Drupal outputs HTML, everything is coupled.

Remove the head, and you have a content management system with no built-in presentation layer. The content API is the only output. What consumes that API — a Next.js app, a mobile app, a static site generator, a digital sign — is entirely up to you.

What is a headless CMS covers the concept from first principles. This article goes deeper into how the architecture actually works in production.

The Three Layers of Headless CMS Architecture

A headless setup has three distinct layers, each with its own responsibilities:

Layer 1: The Content Repository

This is the CMS itself — database, media storage, content modeling, editorial interface. It stores your posts, pages, authors, categories, and any custom content types you define.

The content repository exposes everything via an API. Nothing else — no HTML rendering, no routing, no sessions for public users. Just structured data in response to API requests.

What lives here:

Posts, pages, custom content types
Media files (images, videos, documents)
User roles and editorial workflow
SEO metadata, structured data, tags
Publishing schedules and drafts

Layer 2: The Delivery API

The API layer sits between the content repository and the frontend. It authenticates requests, enforces access control, shapes the response format, and handles caching.

In a simple setup, the delivery API is just a set of REST endpoints on the same server as the CMS. In a more complex setup, it's a dedicated API gateway with CDN caching in front of it.

REST vs GraphQL:

REST is simpler to implement and cache. Each endpoint returns a fixed shape. Good for simple content types and teams that know their frontend requirements upfront.
GraphQL lets the frontend request exactly what it needs — no over-fetching, no under-fetching. Good for complex content models or multiple frontends with different data needs.

Most teams start with REST and move to GraphQL when they have multiple consumers with diverging data needs.

Layer 3: The Frontend (or Frontends)

The frontend fetches content from the API and renders it however it wants. This is where your framework of choice lives — Next.js, Astro, SvelteKit, React Native, anything.

Because the frontend is fully decoupled, you can:

Deploy it independently from the CMS
Use any framework or rendering strategy (SSR, SSG, ISR, client-side)
Serve multiple frontends from the same API (web + mobile + kiosk)
Replace the frontend entirely without touching content

How a Request Flows Through a Headless CMS

Here's what happens when a user loads a blog post on a headless site:

Static generation (SSG) — the most common pattern:

At build time, the frontend fetches all posts from the CMS API
Static HTML files are generated for each post
Files are deployed to a CDN
User requests /blog/my-post → CDN serves the pre-built HTML instantly
No CMS involved in the request path

Result: blazing fast page loads, no server required, CMS availability doesn't affect frontend uptime.

Server-side rendering (SSR):

User requests /blog/my-post
Frontend server receives the request
Frontend server calls the CMS API: GET /api/posts/my-post
CMS returns the post data as JSON
Frontend renders the HTML and sends it to the user

Result: always-fresh content, slightly slower than SSG, but handles personalization and dynamic content better.

Incremental Static Regeneration (ISR) — the hybrid:

Pages are pre-built at deploy time (like SSG)
When content changes in the CMS, a webhook triggers regeneration of specific pages
Only the affected pages are rebuilt, not the entire site

Result: the speed of static with the freshness of server-side. Most production headless setups use this.

Content Modeling in a Headless CMS

Content modeling is where headless architecture gets powerful — and where teams make their first mistakes.

In a traditional CMS, content is mostly free-form: a title, a body, maybe some tags. In a headless CMS, you define structured content types with typed fields. A BlogPost type might have:

BlogPost {
  title: String (required)
  slug: String (unique)
  body: RichText
  excerpt: String (max 200 chars)
  author: Relation → Author
  categories: Relation[] → Category
  featuredImage: Media
  publishedAt: DateTime
  seoTitle: String
  metaDescription: String
}

This structure is enforced by the CMS. Every post the API returns has this exact shape. Your frontend knows exactly what to expect.

Common modeling mistakes:

Over-nesting relations — deeply nested content types are slow to query and hard to maintain. Keep nesting shallow.
Putting presentation in the model — fields like backgroundColor or fontSize belong in the frontend, not the CMS. Content models should be semantic, not visual.
One-size-fits-all body field — using a single rich text field for everything limits structured data delivery. Define specific fields for specific purposes.

Caching in a Headless Architecture

Headless CMS architecture is naturally cacheable in ways monolithic CMS setups aren't. Because the API returns JSON (not HTML), you can cache at multiple levels:

CDN caching: Cache API responses at the edge. A post that hasn't changed in a week doesn't need a database hit on every request.

Build-time caching: Static generation caches content at build time. The API is only hit during builds, not during user requests.

Stale-while-revalidate: Serve the cached version immediately, refresh in the background. Users never wait for a cache miss.

The key enabler is cache invalidation via webhooks. When a content editor publishes a post, the CMS fires a webhook to the frontend CDN: "This URL is stale, rebuild it." Only the affected pages are regenerated. This is how teams get sub-second update propagation without rebuilding entire sites.

Headless CMS vs Traditional CMS: The Architecture Tradeoff

The key differences between headless and traditional CMS come down to one question: do you need the flexibility, or does the complexity cost too much?

	Traditional CMS	Headless CMS
Frontend	Coupled (themes/templates)	Decoupled (any framework)
Deployment	CMS + frontend together	CMS and frontend independent
Performance	Limited by CMS rendering	Frontend can be fully static
Developer experience	Framework-specific (WP, Drupal)	Use any modern stack
Content editor UX	Mature, WYSIWYG	Depends heavily on the CMS admin
Multi-channel delivery	Hard	Native — same API, multiple consumers
Setup complexity	Low	Higher initial setup

The tradeoff is real: headless is more powerful and more complex. It's the right choice when you need frontend flexibility, multi-channel delivery, or best-in-class performance. It's overkill for a simple blog where the default theme works fine.

For a deeper look at the benefits of headless CMS beyond raw performance, the use cases around multi-channel delivery and team independence are often the stronger argument.

How UnfoldCMS Fits the Headless Architecture

UnfoldCMS is a Laravel 12 application with a React + shadcn/ui admin. Today, content delivery works via custom Laravel routes — you write a route that returns JSON, and your frontend fetches from it:

Route::get('/api/posts/{slug}', function ($slug) {
    $post = Post::where('slug', $slug)->with(['categories', 'author', 'seo'])->firstOrFail();
    return response()->json([
        'title'       => $post->title,
        'body'        => $post->body,
        'published'   => $post->posted_at,
        'author'      => $post->author,
        'seo'         => $post->seo,
        'categories'  => $post->categories->pluck('name'),
    ]);
});

This route-based approach gives you full control over the response shape. No vendor schema, no SDK required.

The admin UI is built entirely on shadcn/ui — 183 pages, React 19, TypeScript, Inertia 2. It's the part of the headless architecture most platforms neglect.

A formal public REST + GraphQL API, signed webhooks, and draft preview tokens are on the roadmap. See pricing and features for what's available today.

Frequently Asked Questions

Does a headless CMS require a separate server for the frontend?

Not necessarily. You can deploy the frontend to any static hosting (Vercel, Netlify, Cloudflare Pages) separately from the CMS, or run both on the same server with different subdomains. Static frontends often have zero server cost.

How does content preview work in a headless setup?

Preview mode is the trickiest part of headless architecture. The typical approach: the CMS generates a signed preview URL with a short-lived token. The frontend checks for the token and fetches the draft version of the post from a separate preview API endpoint. Most mature headless CMS platforms support this — it's a known gap in DIY route-based setups.

Can one headless CMS serve both a website and a mobile app?

Yes — this is one of headless CMS's strongest use cases. Both clients hit the same API. The website frontend and the mobile app are independently deployed and can use completely different frameworks. Content editors update once, both channels get the change.

Is headless CMS better for SEO?

It can be — statically generated headless sites are extremely fast, which is a ranking signal. But headless doesn't automatically improve SEO. You still need to handle metadata, structured data, sitemaps, and canonical URLs in your frontend code. The headless CMS and SEO guide covers what actually matters.

Sources and Methodology

Jamstack architecture documentation — SSG, SSR, and ISR patterns described here follow the Jamstack architectural definitions
GraphQL vs REST comparison — based on the official GraphQL specification and common industry usage patterns
Cache invalidation patterns — based on CDN webhook invalidation documentation from Vercel, Netlify, and Cloudflare
UnfoldCMS codebase — route-based JSON delivery example from the live production codebase

💬 First published on my own site: https://unfoldcms.com/blog/headless-cms-architecture-explained/

UnfoldCMS is a self-hosted, developer-first CMS. If any of this was useful — or you disagree — I'm in the comments.

WordPress to Modern CMS: A Migration Story

hamed pakdaman — Mon, 01 Jun 2026 17:56:10 +0000

📝 Originally published on unfoldcms.com — reposted here for the DEV community. (I work on UnfoldCMS.)

The trigger was a $1,847 invoice. Plugin renewals, due all in the same week — Yoast Premium, ACF Pro, WP Rocket, Wordfence Premium, Gravity Forms, WPML — across two production sites. The team looked at the bill, looked at the Core Web Vitals report (LCP 3.4 seconds), looked at the GitHub issue tracking the plugin conflict that took down the site for 90 minutes the previous week, and started a real WordPress to modern CMS migration conversation.

This post is a composite developer's story of the WordPress to modern CMS migration we've shipped across multiple projects in 2024-2026 — what triggered the move, how we evaluated alternatives, the migration playbook in detail, what broke and how we fixed it, the month-by-month results, and what we'd do differently. TL;DR: the migration took 6 weeks of focused work for a 1,200-page site. SEO recovered in 14 days. Plugin license costs went from $1,847/year to $99 one-time + a $20/month VPS. Core Web Vitals improved 40-60% on every measured page. The migration was hard but the math made sense; we'd do it again, with a few changes.

The audience: developers and tech leads weighing the same decision. If you're earlier in the consideration phase, why move from WordPress to a modern CMS in 2026 covers the case for switching; this post covers what shipping the switch actually looks like.

For the framework-agnostic playbook, see the CMS migration guide for developers. For the source-specific WordPress version, how to migrate from WordPress to UnfoldCMS without breaking SEO.

The Trigger: When Renewal Math Stops Working

The honest version of why we migrated: it wasn't ideology, it was renewal math. The site worked. The team knew WordPress. Existing content was indexed and ranking. None of those reasons made the bill stop hurting.

The annual plugin stack we were renewing:

Plugin	License	Annual cost
Yoast SEO Premium	Single site	$99
ACF Pro	Single site	$79
WP Rocket	Single site	$59
Wordfence Premium	Single site	$99
Gravity Forms	Single site	$59
WPML (multi-language)	Multilingual CMS	$99
Smush Pro (image opt)	Single site	$79
Updraft Plus Premium	Single site	$79
MonsterInsights Pro	Single site	$99
Various smaller plugins	—	~$200
Per-site annual total		~$950
Two production sites		~$1,847

Plus managed WordPress hosting at $80/month per site = $1,920/year combined. Plus an agency retainer of 8 hours/month for "WordPress maintenance" = $9,600/year. Total annual run rate: roughly $13,400 for two mid-size content sites that mostly served static-ish marketing content.

The Core Web Vitals report from Google Search Console was equally hard to ignore: LCP 3.4s on mobile (Google's threshold for "good" is 2.5s), INP 280ms, CLS 0.18. We'd thrown WP Rocket at it, configured Cloudflare aggressively, audited plugins twice — and we were stuck. See WordPress performance problems: why your site is slow for the structural reasons we couldn't get below 3 seconds.

The breaking point came when a plugin auto-update (a popular SEO add-on we'd installed for schema markup) conflicted with our caching plugin and took the home page down for 90 minutes during business hours. The bill was annoying. The downtime was the moment we started the evaluation.

For more on the cost structure that made the math break, see hidden costs of WordPress: what you actually pay — it covers the same numbers from a budget-planning angle.

The Evaluation: 3 Candidates, 2 Weeks of Testing

We picked 3 candidates based on team fit:

Strapi (self-hosted, Node + Postgres, REST + GraphQL API, separate Next.js frontend)
Payload v3 (self-hosted, Next.js + in-process Local API, single deployable)
UnfoldCMS (self-hosted, Laravel + React + Inertia, single deployable)

We're a Laravel + React shop with one Node-comfortable engineer. Strapi was the headless option for separation of concerns; Payload was the TypeScript-only option; UnfoldCMS was the Laravel-comfortable option that matched our existing stack. We ran the 10-point headless CMS evaluation checklist on all three.

The 2-week evaluation looked roughly like this:

Week 1 — Setup and content modeling. Each candidate got a fresh install on a $20/month VPS, seeded with 100 sample posts and 30 sample pages mirroring our actual content shapes. We recreated the 6 ACF field groups we used most heavily (post meta, author bios, custom CTAs, FAQ blocks, image galleries, event details). We measured time-to-set-up: Strapi 4 hours, Payload 3 hours, UnfoldCMS 2 hours.

Week 2 — Hands-on testing. We built a real page on each that consumed content from the CMS and rendered it on a real frontend. For Strapi, that meant a Next.js frontend hitting the REST API; for Payload, the same Next.js app served both admin and public pages; for UnfoldCMS, the public site rendered server-side via Blade with the admin in React + Inertia.

The deciding factors:

Operational complexity mattered most for our team size (3 engineers, 1 part-time DevOps). Strapi's two-service architecture (CMS + frontend) felt like overkill for a marketing site. Both Payload and UnfoldCMS shipped as single deployables.
Stack fit: we knew Laravel deeply, we knew React well, we knew Node only through occasional Next.js work. UnfoldCMS played to our strengths.
Pricing: Strapi free with optional Enterprise (we wouldn't need it). Payload free, MIT. UnfoldCMS $99 one-time. None of them broke the budget.
Editor UX: tested by handing the admin to our content lead for 30 minutes. UnfoldCMS's shadcn/ui-based admin felt the most familiar to her (she'd worked with similar admins in other projects); Payload felt engineered; Strapi felt form-heavy. See the headless vs traditional CMS comparison for why this gap exists.

We picked UnfoldCMS for our specific situation: Laravel + React shop, single-frontend marketing site, one deployable artifact preferred, content lead happier with the shadcn admin. Honest disclosure: this post is on UnfoldCMS's blog because that's where we landed. Payload would have been a fine pick if we'd been Next.js-native; Strapi would have been right for a true multi-channel headless project. The choice mapped to our team's actual stack, not to which CMS was "best."

For more on how we evaluated each criterion, see how to evaluate a CMS: beyond the marketing page — that post covers the same evaluation framework with a different angle.

The Migration Playbook: Phase by Phase

The actual migration ran 6 weeks across 5 phases. The phases ran roughly in parallel where possible — content export, schema mapping, and frontend rebuild happened concurrently after week 1.

Phase 1: Content Audit (Week 1)

We needed to know exactly what we were migrating. The audit produced:

Total posts and pages: 1,247 across both sites
ACF field groups: 6 with 47 total fields
Custom post types: 3 (Posts, Case Studies, Events)
Categories and tags: 89 categories, 312 tags (most rarely used)
Media library: 4,800 attachments totaling 12GB
Active plugins: 28 — most of which we wouldn't recreate
Unique URL patterns: 14 (blog dated archives, category archives, tag archives, custom post type archives, etc.)

The deliverable was a spreadsheet with one row per content piece, a column per ACF field, and a "destination" column that we'd fill in during schema mapping. This audit caught surprises: we found 47 posts with broken oembed data from a long-removed YouTube embed plugin, and 23 pages with corrupted shortcodes from an old contact form plugin. Both got cleaned up before migration started.

For the audit framework specifically, see the framework-agnostic CMS migration guide for developers — Phase 1 covers the same pattern.

Phase 2: Schema Mapping (Week 1-2)

We wrote down, for every WordPress field, where it would land in UnfoldCMS:

WP source	Type	UnfoldCMS destination	Transform
`wp_posts.post_title`	varchar	`posts.title`	None
`wp_posts.post_content`	longtext (HTML)	`posts.body`	HTML→Markdown via Turndown
`wp_posts.post_excerpt`	text	`posts.short_description`	None
ACF `featured_image`	postmeta (serialized)	Spatie Media `featured-image` collection	Download attachment, re-upload
ACF `author_bio`	textarea	`author_bio` field on User model	Strip HTML
Yoast `_yoast_wpseo_title`	postmeta	`seo.title`	None
Yoast `_yoast_wpseo_metadesc`	postmeta	`seo.description`	Truncate to 155 chars
Categories (term_taxonomy)	terms	Category model	Slugify, dedupe
Tags	terms	Tag model	Slugify, dedupe
`post_date`	datetime	`posts.posted_at`	Preserve timezone

Two decisions surfaced in this phase that ate significant time:

Decision 1: HTML or Markdown for post bodies? WordPress stores HTML; UnfoldCMS supports both but we wanted markdown for editor sanity. We chose Markdown via Turndown converter and accepted that some custom shortcode output (gallery, contact-form-7) would need manual handling. We dropped about 30 posts' worth of unusual formatting and rewrote them in markdown.

Decision 2: ACF fields as columns or as JSON? Most ACF fields became proper Laravel model columns (typed, indexed, queryable). A few rarely-used fields (event_special_notes, custom social sharing image override) went into a JSON extra_attributes column for flexibility. The split decision matters for queryability — see config-as-code vs GUI-first CMS for why we treated schema as code from day one.

The deliverable: a 47-row spreadsheet covering every ACF field, with destination, transform, and a manual note on edge cases. This document became the spec for Phase 3.

Phase 3: Content Export (Week 2-3)

We wrote a custom Node.js script that hit the WordPress REST API (/wp-json/wp/v2/posts, /wp-json/wp/v2/pages, custom post type endpoints) and fetched everything page by page (100 per request, with auth via application password). The script:

Fetched all posts/pages with ?_embed=true to include featured image data and author info
Fetched ACF data via the WP REST API ACF endpoint
Fetched all media library entries with their original URLs
Output one JSON file per content type: posts.json, pages.json, case_studies.json, events.json, media.json

Total export time: 47 minutes for 1,247 posts/pages and 4,800 media attachments. The script paginated through everything; we hit rate limits twice and added retry logic.

The export ran on staging first, against a copy of the production database, so we could iterate on the script without touching production. We re-ran the export 4 times during the migration as we discovered ACF fields we'd missed or transforms that needed adjusting.

Phase 4: Transform and Import (Week 3-4)

The transform-and-import pipeline ran on a Laravel artisan command we wrote specifically for this migration. The pipeline did:

Read the JSON exports from Phase 3
Convert HTML bodies to Markdown via Turndown
Rewrite image URLs from oldsite.com/wp-content/uploads/... to relative paths matching the new media library
Strip WordPress-specific shortcodes ([gallery], [caption], [contact-form-7]) and replace with native equivalents or markdown
Download every media attachment from the WP origin
Re-upload each attachment to UnfoldCMS via Spatie Media Library, preserving the original filename and alt text
Insert each post/page record with the correct foreign keys (author, category, tags)
Insert SEO records for each post linking to the seo table
Preserve posted_at timestamps so chronological archives still work

The import ran in dev mode against a fresh database 8 times. Each run found new edge cases:

Run 1: 217 posts failed because of orphaned author IDs (deleted users)
Run 2: 89 posts had broken image references where the original media was missing
Run 3: 14 posts had embedded shortcodes from a removed plugin that produced raw [unknown_shortcode] text in the markdown output
Run 4: 6 posts had encoding issues — Latin-1 bytes inside what should have been UTF-8
Runs 5-8: progressively cleaner; final run imported 1,247 of 1,247 successfully

Total import time on the final run: 38 minutes for the full 1,247 posts + 4,800 media attachments.

Phase 5: Redirect Map and Cutover (Week 5-6)

The hardest part of the migration wasn't the data — it was the URLs. WordPress had 14 distinct URL patterns we needed to preserve or redirect. The redirect map covered:

WP URL pattern	New URL	Strategy
`/blog/{slug}`	`/blog/{slug}`	Same — no redirect needed
`/{year}/{month}/{slug}`	`/blog/{slug}`	301 redirect
`/{year}/{month}/` (date archive)	`/blog/`	301 to blog index
`/category/{slug}`	`/blog?category={slug}`	301 with query param
`/tag/{slug}`	`/blog?tag={slug}`	301 with query param
`/author/{slug}`	`/team/{slug}`	301 to team profile
`/case-study/{slug}`	`/case-studies/{slug}`	301
`/events/{slug}`	`/events/{slug}`	Same
`/?p={id}` (legacy URL)	`/blog/{slug}`	301 via post ID lookup
`/feed/` (RSS)	`/feed/`	Same — UnfoldCMS generates RSS
`/sitemap.xml` (Yoast)	`/sitemap.xml`	Replaced with UnfoldCMS sitemap
`/wp-content/uploads/...`	`/storage/...`	301 redirect for all media
`/wp-admin`	(no redirect)	Admin path doesn't need preserving
`/wp-json`	(no redirect)	API path doesn't need preserving

The redirect map was a CSV with ~3,200 specific redirects (every old URL → new URL pair) plus pattern-based rules for the date archives and category/tag pages. We loaded the CSV into UnfoldCMS's redirect feature and verified each pattern with curl -I against staging.

Cutover day ran on a Tuesday morning — chosen for low traffic. The sequence:

08:00 UTC — locked WordPress admin (read-only mode via plugin), notified the team
08:15 — final delta export from WP (any posts published since the last full export)
08:30 — ran the transform-and-import on production UnfoldCMS for the delta
09:00 — flipped DNS from WP to UnfoldCMS (TTL had been pre-lowered to 60 seconds the day before)
09:05 — DNS propagated; verified site was serving from UnfoldCMS
09:15 — submitted updated sitemap.xml to Google Search Console
09:30 — triggered URL inspection on the top 50 traffic pages via GSC
10:00 — verified analytics were tracking correctly on the new site
17:00 — end of day check: zero unexpected 404s in the access logs, redirects working, content rendering correctly

The cutover went cleaner than expected. We attribute that to the 8 dry-runs of the import in Phase 4 and the redirect verification in staging.

For the cutover playbook in framework-agnostic form, see the CMS migration guide for developers.

What Broke and How We Fixed It

Five things broke in the first two weeks post-cutover. Each took 1-4 hours to fix:

1. Encoding issues on 14 posts. Latin-1 bytes that read fine in WordPress's database showed up as garbled characters in UnfoldCMS. Fixed by writing a one-time Laravel command that detected and converted bad encoding. Lesson: include encoding sniff in the transform step from the start.

2. ACF "post object" fields stored as integer IDs. A field that linked Post → Related Post stored the related-post WordPress ID, not a stable identifier. After import, the IDs didn't match because UnfoldCMS assigned new IDs. Fixed by storing the WP ID as a temporary wp_legacy_id column, then mapping wp_legacy_id → new_id in a second pass. Lesson: keep legacy IDs around during migration; drop them only after every reference is resolved.

3. Image URLs in post bodies pointing at the WP domain. We rewrote URLs in the transform step but missed some embedded in <a href> attributes around <img> tags. The redirect from /wp-content/uploads/... → /storage/... caught them but added a 301 hop on every image load. Fixed by running a one-time SQL update that rewrote the URLs in the bodies directly. Lesson: rewrite all URL forms in the transform, not just the obvious ones.

4. RSS feed missing some posts. Our RSS generator filtered by published-after timestamp; some imported posts had posted_at in the past, so they didn't appear in the "recent" feed. Fixed by including more posts in the feed and adding pagination.

5. WP-Admin login URL still ranking on Google. Bing and Google had wp-admin pages indexed (mostly login pages). They returned 404 on the new site. We added explicit noindex and a 410 status to those URLs to clean them out of search indexes. SEO-neutral but worth the cleanup.

For the broader pattern of migration breakage, see the framework-agnostic CMS migration guide for developers — most of these failure modes show up across migrations regardless of source CMS.

The Results: Month-by-Month

We tracked four core metrics across the migration: TTFB (server response time), LCP (Core Web Vitals), organic traffic, and conversion rate.

Metric	Pre-migration	Week 1 post	Month 1	Month 3	Month 6
TTFB (median, mobile)	980ms	220ms	200ms	180ms	175ms
LCP (median, mobile)	3.4s	2.1s	1.9s	1.7s	1.6s
Core Web Vitals pass rate	31%	78%	84%	87%	89%
Organic traffic (vs baseline)	100%	88%	96%	102%	108%
Conversion rate	1.8%	2.1%	2.3%	2.4%	2.5%

The dip in week-1 organic traffic (-12%) is normal during migration — Google needs to recrawl, redirect maps need to settle, ranking signals need to re-stabilize. By month 1 we'd recovered most of it; by month 3 we were ahead of baseline; by month 6 the SEO effect of faster Core Web Vitals + cleaner site architecture compounded.

Conversion rate moved more than expected. Three contributing factors:

LCP improvement: faster pages convert better. Going from 3.4s to 1.7s LCP recovered roughly 0.4 percentage points of conversion based on our internal A/B history.
Editor velocity: the marketing team shipped 3x more landing pages in months 2-4 than they had in any previous quarter, because the modern admin made editing faster.
Removed friction: dropping a few legacy plugins removed broken cookie banners, slow chat widgets, and an A/B test tool that was conflicting with caching.

The numbers compound. By month 6, we were running roughly 40% above the pre-migration revenue baseline on the same traffic mix — and that was before the cumulative SEO effect of the better Core Web Vitals showed up.

For deeper context on Core Web Vitals as a ranking signal, see headless CMS and SEO: what actually matters in 2026. For the underlying performance reasons WordPress couldn't compete, WordPress performance problems: why your site is slow.

What We'd Do Differently

Six things we'd change next time:

1. Run the audit harder upfront. We found 47 broken oEmbed entries and 23 corrupted shortcodes during migration that we should have caught in the Phase 1 audit. Two extra days on the audit saves five days of rework.

2. Build the redirect map first. We treated redirects as Phase 5 work and ran out of time at the end. Next time we'd build the full redirect map in Phase 1 — before any code, before any schema mapping. Redirects are the highest-leverage migration work; everything else can iterate.

3. Test cutover on staging end-to-end. We tested the import 8 times but only tested the full cutover sequence (DNS flip, redirect activation, sitemap submission) once before the real cutover. Next time, dry-run the whole sequence on staging at least twice.

4. Keep WordPress reachable for 60 days, not 30. We turned off the WP origin at day 30 and got two support requests about old bookmarks pointing at WP-specific URLs. Three more weeks of read-only WP would have caught those gracefully.

5. Communicate with the editorial team earlier. The content lead had a productive 2-month period during weeks 1-3 of migration when she still had the WP admin available; weeks 4-6 (when WP was read-only and UnfoldCMS wasn't fully populated) she had no good place to publish urgent updates. We should have time-boxed this gap to 1 week max.

6. Document the schema-mapping decisions. The "ACF column or JSON" decisions were made in real-time during Phase 2; six months later, when a developer wanted to add a new field to the model, we couldn't quickly tell which existing fields were JSON vs columns. Should have written a short architecture-decision doc as we went.

The Honest Costs

The migration cost real money and time. Honest accounting:

Engineering time: 6 weeks × 2.5 engineers (avg) = ~15 person-weeks = ~600 hours
Agency oversight (existing retainer redirected): ~40 hours over 6 weeks
Infrastructure for transition: $300 (extra staging VPS during migration period)
Editorial freeze period: ~1 week of reduced publishing velocity
Initial post-migration monitoring: ~20 hours/month for first 2 months, then back to normal

If we'd hired this out at $100/hour blended rate, the migration would have cost ~$60,000 in dev hours. We did it in-house with existing engineers redirecting from other work, which cost the opportunity (other features delayed by 6 weeks) but no incremental dollars. Either way, the math made sense given the $13,400/year recurring savings on plugin licenses, hosting tier, and agency retainer plus the conversion-rate uplift.

The ROI math depends on site size. For smaller sites (under 200 posts, single editor), the migration cost is lower (2-3 weeks) but the savings are also lower. The threshold where migration pays off is roughly: more than 5 paid plugins + Core Web Vitals failing + an existing dev team that could ship the migration.

What to Do About It

If you're looking at the same trigger — renewal math, performance ceiling, plugin compatibility incidents:

Run the cost audit first. Add up plugin licenses, hosting, agency retainer, the cost of incidents. The number is usually higher than expected. See hidden costs of WordPress: what you actually pay.
Run the evaluation seriously. 2 weeks, 3 candidates, hands-on testing. Marketing demos won't show you the integration friction. Use the 10-point evaluation checklist and how to evaluate a CMS: beyond the marketing page.
Plan the migration on a real calendar. 6 weeks for a mid-size site is realistic. Compressing it to 2 weeks usually means dropping the audit and discovering broken data on cutover day.
Build the redirect map in Phase 1. Migrations live or die on URL preservation. Don't leave it for the end.
Read the framework-agnostic CMS migration guide for developers for the full playbook before scoping.

If your stack is Laravel + React, UnfoldCMS is built for this exact migration story — we live on our own product. See pricing, book a demo, or browse our comparisons. We're transparent that the migration story above is composite — we've shipped this pattern across multiple projects, with details adjusted to a single narrative for readability. The technical details (Turndown, ACF flattening, redirect map size, cutover sequence) match what we actually do; the specific 1,247-page count and $1,847 invoice are illustrative of typical mid-size projects.

FAQ

How long does a WordPress to modern CMS migration take?

For a mid-size site (1,000-2,500 pages with custom fields and multi-language content), 4-8 weeks of focused engineering work. Smaller sites (under 200 pages) can ship in 1-2 weeks. The dominant cost is the schema mapping and redirect map work; the actual data migration runs in hours once the pipeline is built.

Will I lose SEO rankings during the migration?

You'll see a temporary 10-15% dip in week 1 as Google recrawls and reconciles redirects. Most sites recover to baseline within 30 days; many sites that improve Core Web Vitals during migration come out ahead of pre-migration rankings within 60-90 days. The SEO key is the redirect map — every old URL must 301 to a new URL, with no broken patterns. See headless CMS and SEO: what actually matters in 2026 and the framework-agnostic migration guide.

What's the hardest part of migrating from WordPress?

The redirect map. Content export is mechanical; schema mapping is tedious but tractable; image handling is solvable. URL preservation across 1,000+ posts with custom permalink structures is where projects break. WordPress's permalink system is more permissive than most modern CMSes, so old WordPress sites accumulate URL patterns (date-based archives, multi-level categories, custom post type slugs) that all need explicit redirects. Build the map first.

Should I migrate everything at once or section by section?

For most marketing sites: all at once. The cutover is the risky part regardless of size; doing it in sections multiplies the risk. For large sites with distinct content sections (e.g., a blog + a documentation portal + a product catalog), section-by-section migration can work — but plan for 2-3x the total time vs all-at-once.

Can I use my existing WordPress writers and editors after migration?

Yes — but expect 1-2 weeks of slower velocity while they learn the new admin. Modern CMS admins are usually faster long-term but unfamiliar at first. The transition is easier if the editorial team had time on the new admin during migration (not just at cutover). Schedule editor onboarding 1-2 weeks before cutover, not after.

What's the biggest mistake teams make in WordPress migrations?

Underestimating the redirect work. Teams allocate 80% of the time to data migration and 20% to redirects; the right ratio is closer to 50/50. The data migration is mostly mechanical work that an experienced engineer can ship; the redirect map requires someone who understands SEO consequences and can think through every URL pattern. Get redirect work started in Phase 1, not Phase 5.

Sources & Methodology

This post is a composite of multiple WordPress to modern CMS migrations the UnfoldCMS team has shipped across 2024-2026. The technical details (HTML→Markdown via Turndown, ACF flattening to Spatie Data, redirect map structure, 5-phase playbook) match real migrations we've executed. The specific numbers (1,247 posts, $1,847 invoice, 31% → 89% Core Web Vitals improvement, 6-week timeline) are representative of typical mid-size projects rather than a single specific case.

Sources for the broader claims:

Patchstack 2024 for WordPress plugin vulnerability data
Google CrUX dataset for Core Web Vitals baseline (median WP mobile LCP = 3.2s)
Internal cost data for plugin license aggregation, agency retainer rates, and infrastructure costs
First-hand migration project retros across multiple client engagements 2024-2026

Disclosure: this post is on UnfoldCMS's blog, and the migration narrative ends with picking UnfoldCMS as the destination. The 3-candidate evaluation framing (Strapi, Payload, UnfoldCMS) reflects projects where Laravel + React was the deciding fit; for projects with different stacks, Payload v3 (Next.js + TypeScript) and Strapi (Node + headless) are honest alternatives that win different evaluations. The migration playbook itself (audit → schema map → export → transform/import → cutover) applies regardless of destination.

For deeper coverage of any individual phase, see the framework-agnostic CMS migration guide for developers, how to migrate from WordPress to UnfoldCMS without breaking SEO, and the broader case for moving off WordPress in 2026.

💬 First published on my own site: https://unfoldcms.com/blog/wordpress-to-modern-cms-migration-story/

UnfoldCMS is a self-hosted, developer-first CMS. If any of this was useful — or you disagree — I'm in the comments.

Why WordPress DX Fell Behind — A Developer's Honest Take

hamed pakdaman — Mon, 01 Jun 2026 17:01:08 +0000

A version of this is on my own site too. (I work on UnfoldCMS — but this post is about WordPress DX, not a pitch.)

A developer joins a WordPress project in 2026. They open functions.php, scroll past 800 lines of add_action and add_filter, and quietly open LinkedIn in another tab.

I've watched this happen. I've been this developer. And I want to be fair: WordPress DX isn't bad because the people maintaining it are bad. It's bad because the platform was designed in 2003, around PHP 4, and has grandfathered every API decision since. The gap to modern stacks isn't closing — it's growing.

This isn't a "WordPress bad" rant. It's a look at why the developer experience fell behind, with the same task written both ways so you can judge for yourself.

TL;DR: WordPress's DX problems are structural — global functions, hooks-and-filters as the main extension model, untyped data in wp_postmeta, no first-class testing, IDE autocomplete that dies at the hook boundary, and a deploy model still shaped around FTP. Modern stacks fix all of these by default. The gap decides your hiring pool, how maintainable the code stays, and how fast you ship the next thing.

The language gap: PHP 2003 vs today

WordPress's core API was designed around PHP 4 — no real namespaces, no type hints, no dependency injection. So the API became a museum of PHP 4 idioms, carried forward through every release.

Here's how you do basically anything in WordPress:

add_action('init', 'my_setup_function');
add_filter('the_content', 'modify_post_content');

function my_setup_function() {
    // do stuff with global $wpdb, global $post, etc.
}

function modify_post_content($content) {
    return str_replace('foo', 'bar', $content);
}

Five things a 2026 developer notices immediately:

Global functions everywhere — add_action, add_filter, the_content all live in the global namespace. Name collision? Good luck.
String-typed hook names — 'init' is a string. Typo it and nothing happens, silently. Your IDE can't catch it.
Hidden global state — global $wpdb, global $post, global $wp_query. The callback depends on state set somewhere else you can't see.
No type info — add_filter('the_content', $cb) has no idea what $content is. No autocomplete on the parameter.
No return contract — what should the callback return? Whatever WordPress handed you, roughly.

Same idea in a modern Laravel stack:

namespace App\Listeners;

use App\Events\PostPublished;
use App\Services\ContentModifier;

class TransformPostContent
{
    public function __construct(private ContentModifier $modifier) {}

    public function handle(PostPublished $event): void
    {
        $event->post->body = $this->modifier->replace($event->post->body, 'foo', 'bar');
    }
}

Namespaces, type hints, dependency injection, zero globals, autocomplete on every line. It's more code — but it's code the compiler can verify and the IDE can help you write.

The data gap: untyped meta vs real columns

This is the one that quietly costs you weeks. WordPress stores custom fields in wp_postmeta as serialized strings — key/value rows, no types, no constraints.

// WordPress: read a custom field
$price = get_post_meta($post_id, 'product_price', true);
// $price is a string. Always. Even if you saved a float.
// Forgot the third arg? You get an array. Surprise.

You don't know the type. You don't know if the key exists. You can't constrain it at the DB level. And every read is a separate query unless you remember to prime the cache.

A modern CMS gives you a real schema:

// Typed model attribute, real column, one query
$price = $product->price; // float, guaranteed, autocompleted

The difference compounds. With wp_postmeta, every feature adds untyped rows to one giant table. With real columns, every feature is a typed, queryable, indexable field.

The testing gap

Modern frameworks ship with testing as a first-class citizen. You scaffold a project and the test runner is already there.

// Laravel: this works out of the box
it('publishes a post', function () {
    $post = Post::factory()->create(['status' => 'draft']);
    $post->publish();
    expect($post->fresh()->status)->toBe('published');
});

WordPress can be tested — but it fights you. Global state, database fixtures that need a full WP bootstrap, hooks firing in the background. Most WordPress projects I've seen ship with zero tests, not because the team is lazy, but because the cost of the first test is so high nobody pays it.

The deploy gap

A lot of the WordPress world still deploys by FTP-ing files to a server and clicking "update" in /wp-admin. No build step, no atomic releases, no easy rollback. The database holds config and content and serialized PHP, so "just copy the DB" isn't safe either.

Modern stacks deploy with a build, a migration step, and a rollback path:

git push        # CI builds
php artisan migrate --force
# assets built, atomic swap, rollback = redeploy previous tag

One of these you can do at 2pm on a Friday. The other you do at 2am on a Sunday with your heart rate up.

To be fair to WordPress

WordPress isn't going anywhere, and for a lot of sites that's the right call:

A blog or brochure site where nobody touches code → WordPress is fine.
A non-technical team that needs Gutenberg and a plugin for everything → WordPress is fine.
An existing WordPress site that works → don't rewrite it for vibes.

The DX gap matters when developers own the project long-term. It decides who you can hire, how maintainable the code stays, and how fast you ship feature #50.

So what do you use instead?

Depends on your stack. If you're already in Laravel, a Laravel-native CMS keeps you in typed, testable, DI'd territory instead of dropping back into globals. If you're on Next.js / Astro / Svelte, a headless CMS with a real API does the same.

I ended up building one (UnfoldCMS) because I wanted the content layer to feel like the rest of my codebase — typed models, real migrations, a test suite, a normal deploy. That's the pitch and I'll leave it at one line.

But the broader point stands without my product: a 2026 CMS should give you 2026 developer experience. WordPress gives you 2003's, carefully preserved. For a lot of teams that's the dealbreaker — not the features, the daily experience of working in it.

What's your take — is WordPress DX salvageable, or is the PHP-4-era foundation just too deep to fix? Genuinely curious where other devs land on this.

Originally published on unfoldcms.com. Happy to go deeper on any of these in the comments.

I Tried Building a CMS on Filament — Here's What I'd Do Instead

hamed pakdaman — Tue, 26 May 2026 16:09:02 +0000

I spent two months last year trying to build a content-management system on top of FilamentPHP. I had reasons. Filament was the most polished thing in the Laravel ecosystem. Every Laravel dev I respected was using it. I'd already shipped two admin panels with it for client work and they came together fast.

The third project was different — a marketing site with a blog, pages, a menu, redirects, SEO meta, scheduled posts, and a real public-facing theme. I figured: same stack, same DSL, same speed. I was wrong, and the lesson took me longer to learn than I'd like to admit.

This is what I learned, what I'd do differently, and why I eventually built something else.

TL;DR: Filament is excellent at being Filament — a builder DSL for admin panels around your own data model. It's not a CMS, and trying to use it as a CMS by scaffolding PostResource, PageResource, MediaResource, etc., is a quietly expensive way to ship a website. Pick Filament when the data model is yours to design. Pick a CMS when the data model is "post, page, media, menu, SEO, redirect" — that problem has been solved for 20 years and you shouldn't rebuild it.

What I Built On Filament

The project was a marketing site for a small SaaS — homepage, ~6 marketing pages, a blog, a docs section, a category-filtered case-studies index. Standard small-business CMS work.

My initial Filament scaffold was about what you'd expect:

PostResource with title, slug, body (Tiptap field), featured image (Filament media plugin), status enum, scheduled-at, SEO title, meta description, category relation manager
PageResource — almost identical, plus a layout enum and section blocks
CategoryResource — title, slug, parent, sort order
MenuResource — name + a repeater of menu items
MediaResource — wrapping Spatie Media Library so the team could browse uploads
RedirectResource — from URL, to URL, status code, is_active

I wrote those in two days. Filament's form DSL is genuinely good — TextInput::make(), Select::make(), conditional fields, relation managers. Two days of resource definitions and I had an admin that looked like a CMS admin.

Then I spent the next eight weeks building everything that wasn't an admin form.

What Filament Doesn't Ship

This is the part nobody tells you when they recommend Filament for a CMS. You scaffold the resources in a weekend, and then you realize Filament has no concept of:

A public-facing site. Filament is admin-only. The site that the content gets published to — the actual website your readers visit — doesn't exist. You build it yourself in Blade or Inertia, from scratch, every project.
Themes. No theme system, no template switcher, no place for non-developer users to change the look. If marketing wants a new homepage layout, you edit Blade files and deploy.
Sections / page builder. No block-based section system. If the marketing team wants a "stats" section above "testimonials," that's a developer task. I tried wiring up Filament's repeater field as a section builder — it kind of worked, and it took a week, and the editing UX was still worse than any real CMS.
A media library outside the resource. Filament's media is per-field. You can browse it from the form. There's no global media library where editors hunt for "that photo we used three months ago." The Curator plugin gets you partway there — it's $49 and still doesn't feel like WordPress's media library, which set the bar 15 years ago.
Slug history. When you rename a post slug, the old URL 404s. Filament doesn't track slug history. You build that yourself with a model + middleware. I did. It took half a day and I had to debug edge cases for two more.
Real SEO records. I shoved seo_title, meta_desc, og_image_url columns onto every resource. Then I needed sitemap.xml. Then robots.txt. Then JSON-LD schema for posts and pages. Then per-page Open Graph fallback. Every one of these is its own afternoon of code that every CMS already ships.
Redirects with hit tracking. Built that one. A model, an admin resource, middleware that runs early in the request lifecycle and respects is_active. CSV import? Built that too.
A sitemap generator. A service that walks every resource type, queries published rows, outputs XML, caches it sensibly. Two days.
A comments system. I needed it for the blog. I evaluated beyondcode/laravel-comments (good package), wired it in, built a moderation queue, built a "reply to reply" UI in Livewire. Another week.

I'll stop the list. You get the picture. By week eight I had reinvented half of a CMS in Filament's idiom, and the half I had wasn't as good as the half a real CMS would have given me on day one.

The DX Pattern That Quietly Burns Time

Filament's developer experience inside the admin is genuinely great. The DSL is tight, the docs are clear, the components are polished. Inside the admin. The DX outside the admin — the public-facing site, the editor's workflow, the deploy story — is whatever you build.

Here's the trap. Each individual "I'll just build this on Filament" decision feels small:

"I'll just wire up a Blade template for the public post page." — 2 hours
"I'll just add a sitemap.xml route." — 3 hours including the cache layer
"I'll just build a tiny section system with Filament's repeater." — 2 days
"I'll just write a slug-history middleware." — half a day
"I'll just add a comments table and a moderation UI." — 4 days
"I'll just build a media library page outside the resource." — 3 days
"I'll just add a homepage editor with reorderable sections." — week and a half

Add them up. Eight weeks of CMS rebuild work, on top of the actual marketing site I was supposed to be delivering. None of that work was bad — it's just work that someone else already did, packaged, and shipped.

The pattern I had to learn the hard way: when you find yourself building admin resources for "Post," "Page," "Category," "Media," "Menu," "Redirect," and "SeoMeta," you're not building an admin for your app. You're building a CMS. And there are already CMSes.

Filament gives you the form library for that CMS. It doesn't give you the CMS.

What I'd Do Differently

If I started that same project today, I'd ask a different question first.

The question I asked then: "What's the best Laravel admin framework?" That question always answers Filament. It's a great answer to that question.

The question I should have asked: "Do I have a CMS data model, or a custom data model?"

If the data model is Order, Shipment, Invoice, Customer, SupportTicket, Subscription, LabSample — that's a custom data model. Filament is the right tool. The flexibility you pay for in Filament (you describe the admin, Filament renders it) is exactly what you need because nobody else has shipped your admin for your data.

If the data model is Post, Page, Category, Media, Menu, Redirect, SeoMeta — that's a CMS data model. It's been solved. The right tool is a CMS, and what you pay for is not the freedom to design the admin — it's the freedom to skip designing the admin. The CMS does the admin part the same way every CMS has done it since 2003, and that's fine, because users already know how it works.

I spent two months learning that distinction. I'm writing this so you don't have to.

What Filament Is Genuinely Best At

I want to be careful here, because "Filament is great but not for X" reads cynical and the Laravel community gets enough of that. Filament is genuinely best at things I needed to not build, by building something else.

Custom internal admins. A back-office tool for a logistics company managing routes, drivers, vehicles, deliveries. A moderation queue for a marketplace. An ops dashboard for a SaaS support team. These have custom data models. Filament wins.

SaaS product dashboards. Customer-facing dashboards inside a product where the user manages their own resources (projects, API keys, billing settings). Filament's multi-panel support in v3+ makes this clean.

Form-heavy apps. If your app is fundamentally forms — survey builders, application processing, lab data entry — Filament's form DSL is best-in-class in the Laravel ecosystem. Nothing else comes close.

Teams that prefer config-as-code. Some teams genuinely want the admin's shape to live in PHP files, reviewable in PRs, deployable like any other code change. Filament fits that workflow perfectly. A CMS where editors change the homepage layout in production through an admin UI is the opposite of that workflow. Both are valid; they fit different teams.

When I see someone shipping a moderation tool, an internal admin, a SaaS dashboard, a custom data model — I tell them Filament. And mean it.

What I Built Instead

I'll keep this short because the post isn't about me. After the Filament-as-CMS experience, I built UnfoldCMS — a Laravel 12 + React 19 + shadcn/ui CMS. The content model is fixed: Post with four content_type values (post, page, landing, block), media via Spatie, categories, comments, menus, redirects, SEO meta, themed public site, public REST API. One-time license, $39 to $799 depending on tier.

I did not build it because Filament is bad. Filament isn't bad. I built it because the shape I needed for marketing sites — fixed content model, themed frontend included, non-developer editor workflow — was the wrong shape for an admin-panel builder. So instead of bending Filament into that shape, I built a different tool for that shape.

If you're picking between them, the UnfoldCMS vs FilamentPHP comparison lays out which tool fits which job in more detail.

The Honest Decision Tree

If you're a Laravel developer right now, picking what to use for your next admin or CMS project, the question is one of these two:

Are you designing the data model?

Yes → Filament. Your domain is unique, the admin has to be shaped to it, and Filament's DSL is the best in the ecosystem for that work.
No, it's a CMS data model → CMS. UnfoldCMS, Statamic, Kirby, or even WordPress if your team is WordPress-shaped. Don't rebuild what's already shipped.

Does your project need a public-facing themed frontend out of the box?

Yes → CMS. Filament has no concept of one.
No, the frontend is a separate Next.js / Astro / SvelteKit app that consumes an API → either tool can work, but Filament still doesn't ship the content model.

Are non-developers editing the site day-to-day?

Yes → CMS. The kinds of changes editors make (rearrange sections, change menus, add redirects, edit SEO) all need admin UI that doesn't exist in Filament unless you build it.
No, only devs touch the admin → Filament is fine.

That's the whole framework. Three questions. If the answers come back "CMS, CMS, CMS," reach for a CMS. If they come back "Filament, either, Filament," reach for Filament. If they come back mixed, the bigger question is what your team actually needs to ship, not which framework is cooler this week.

What I'd Tell My Past Self

Two months ago me, listening:

Filament's not a CMS. The fact that it looks like one when you scaffold a PostResource is a trick of the eye. Pull on that thread for ten minutes and you'll find sitemap.xml, robots.txt, JSON-LD schema, theme system, public frontend, slug history, comments — none of which exist in Filament because that's not Filament's job.
"Building it on Filament" feels productive because every individual piece is small. The cost is the integral of those small pieces, and you can't see the integral from inside week one.
Look at what already ships. Spend an hour evaluating WordPress, Statamic, Kirby, Ghost, UnfoldCMS, October CMS, Strapi (if you're open to Node) — before you scaffold the first resource. The hour saves you the eight weeks.
The "Laravel CMS" question is not actually about Laravel. It's about whether you want to write a CMS or use a CMS. Either is fine. Just don't accidentally do the first one when you meant to do the second.

That's it. That's the post. If you're picking between Filament and a CMS for your next project and the data model is "post + page + media + menu + SEO" — that's a CMS-shaped project. Pick the tool shaped like the work.

Disclosure: I work on UnfoldCMS. This post is also published on the UnfoldCMS blog (canonical above). The Filament observations are from my own pre-UnfoldCMS work, not a vendor comparison piece — Filament is a tool I respect and still recommend for the jobs it fits. If you're shipping a custom admin, use Filament. If you're shipping a CMS, use a CMS.

What 183 admin pages look like — building a full Laravel CMS in 2026

hamed pakdaman — Sat, 09 May 2026 13:51:47 +0000

A year ago I started building a CMS because I had three options for client work and none fit:

WordPress — works, but 250+ plugin CVEs/week (Patchstack 2024). I patch sites every week. Tired of it.
Contentful / Sanity — modern, but $300/mo entry pricing for SMB use cases. Vendor lock is real.
Strapi / Payload — solid, but Node-only. I'm a PHP/Laravel shop.

So I built UnfoldCMS — a self-hosted Laravel CMS that ships as a single product, not a framework you assemble. This post is a tour of what's actually in there. Not the marketing version — the "here are the 183 admin pages" version.

If you're picking a CMS in 2026, this is the kind of breakdown I wish vendors actually published.

The stack, briefly

Laravel 11 + Inertia 2 + React 19 + TypeScript
Tailwind v4 + shadcn/ui (50+ components)
MySQL / MariaDB
Spatie Media Library, Spatie Permission (RBAC), Spatie Activity Log
Runs on $5/mo Hetzner VPS at ~80MB RAM idle

The shadcn + Tailwind theming side I covered in my previous post. This post is about the CMS surface — the modules, the editor, the publishing pipeline.

What's in the box

Every module here is built-in. No "plugin marketplace" — Laravel has service providers, that's the extension model.

Posts and Pages

The core publishing primitives. Both share the same model (Post with a content_type enum), but render differently.

Posts = blog entries, indexed under /blog/{slug}, listed on the blog index page.
Pages = root-level content like /about, /pricing, /migrate-from-wordpress.
Same editor, same media handling, same SEO fields. Only the URL routing differs.

The editor is a structured block editor built on Tiptap's foundation. Each block is a discrete field — heading, paragraph, image, code block, callout, table — not a free-form blob. Editors get predictable layouts; developers get clean data to query.

Scheduled publishing is built in. posted_at in the future + is_published = true = post appears at the scheduled time. A single Laravel scheduler entry runs every minute and flips visibility.

Media Library

Spatie Media Library under the hood. Three things made it worth using over a custom solution:

Polymorphic associations — any model can have media (posts, users, settings, custom models).
Conversions on demand — define large, medium, thumbnail once; conversions generate when first requested.
Featured-image collections — separate featured-image collection per post, separate from inline body images.

The trap I'd warn against: the legacy image_large text column on the post table looks tempting for "set the hero image." Don't. Use Spatie collections — the template renders them automatically with proper aspect ratio handling.

Menus

Tree-based menu builder. Drag-and-drop reorder. Each menu item links to internal routes (resolved via Laravel's named routes), external URLs, or content (auto-generates the URL from the slug).

Multiple menus per site — Header, Footer, Mobile, Sidebar — and they support nested children. The frontend templates pull menus by slug:

$mainMenu = Menu::bySlug('main');

Forms

A form builder with a JSON schema. Fields, validation rules, success/error messages, redirect targets — all configurable from the admin. Submissions go to a form_submissions table; admins see a list with filters, can export to CSV, and forward to email or webhooks.

The architecture choice: forms are a CMS feature, not a separate app. They share the auth, the rate limits, the spam filtering (Spatie honeypot), and the activity log with the rest of the system.

Settings

Key-value store with a config-driven schema. The schema lives in config/site.php — defaults set once, admin UI generates from the schema, frontend reads via Setting::get('key', $fallback).

Why this matters: if a customer wants a "show announcement banner" toggle, you don't write a migration, a form, a controller, and a Blade variable. You add a key to the schema and it shows up in the admin automatically.

Theming

Three themes ship — Default (blue), Purple, Unfold (soft purple). Switching is one CSS variable swap (covered in detail in the previous post). The theming primitive is data-theme="..." on the root element + Tailwind v4's @theme directive.

What's in scope for theming: colors, radius, font stack. Not in scope: layout, spacing, component shape. That's intentional — themes are visual, not structural.

Templates

Above themes is templates — full frontend designs that ship with the CMS. The active one on this site is "Aurora," which has its own seed data, blade templates, and section components. Templates are swappable at install time; runtime swap is harder because each ships its own homepage section data.

SEO

Built on the ralphjsmit/laravel-seo package, extended with site-wide defaults and per-post overrides.

What gets generated automatically:

<title> and meta description (with explicit override fields)
Open Graph + Twitter card tags
JSON-LD schema: Article, BreadcrumbList, Organization
Canonical URLs with proper trailing-slash handling
hreflang tags for multi-language sites

The CMS fallback for SEO title is the post title — but it title-cases it, which corrupts proper nouns ("WordPress" → "Wordpress"). Lesson learned the hard way: always set seo_title and meta_desc explicitly, never rely on the fallback. There's now a hard rule in our content-publishing skill.

RBAC

Spatie Permission. Three default roles ship — Super Admin, Editor, Author — and you can add more from the admin. Permissions are granular (per-model + per-action), not just role-based.

The middleware story is straight Laravel:

Route::middleware(['auth', 'role:editor|admin'])->group(function () {
    Route::resource('posts', PostController::class);
});

No vendor magic. If you've used Spatie Permission, you know exactly what's happening.

Multi-language

spatie/laravel-translatable. Each translatable field (title, body, seo_title, meta_desc) stores a JSON map of {locale: value}. The admin shows a locale switcher; the frontend resolves based on URL prefix (/fr/about) or domain.

What's not in there yet: automatic translation (machine translation pipeline). Editors translate manually for now.

The publishing pipeline (the part that took the longest)

Building a "save post" button is a weekend. Building a publishing pipeline that handles drafts, scheduled publishes, sitemap regeneration, cache invalidation, and SEO updates without race conditions is a year.

What's behind a publish action:

Validation — required fields, slug uniqueness, meta-desc length
Markdown → HTML conversion (server-side; the body is stored as HTML so the template just renders it raw)
SEO record sync — seo_title, meta_desc, og_image written to a related table
Spatie media attachment — featured image moves from temp upload to permanent collection
Sitemap regeneration — php artisan sitemap:generate runs synchronously (no queue worker required for shared hosting)
Cache invalidation — view:clear, route:clear, edge cache purge if configured
Activity log — Spatie ActivityLog records who published what

All of this runs synchronously in the request because the CMS targets shared hosting where queue workers aren't a given. If you're on a real VPS, you can flip QUEUE_CONNECTION=database and it queues automatically. The synchronous fallback is what makes "deploy to a $5 VPS" actually work.

Deployment story

Single artisan command: php artisan deploy. It does:

Verifies clean working tree on the deploy branch
Pushes to git
Pulls on the server
Runs composer install --no-dev (skipped if composer.lock unchanged)
Runs php artisan migrate --force
Builds frontend assets locally with pnpm run build, syncs to server via rsync (skipped if no JS/CSS changed)
Clears config/view/route caches
Verifies HTTP 200

The lessons embedded in this command:

Frontend builds locally, not on the server. Faster, and avoids needing Node on the server.
Composer skip when lockfile unchanged saves ~30s per deploy.
Rsync over SCP for assets — incremental, only uploads changed files.
HTTP 200 verification at the end catches deploys that broke the site silently.

I've shipped enough Laravel apps that I now consider the deploy command part of the product, not a project.

What's not in the box (yet)

Honest list:

Public headless API

Internal REST works. Public endpoints + signed webhooks ship late 2026. Until then, if you want to use UnfoldCMS as a content backend for a Next.js site, you write a thin Laravel route that returns JSON:

Route::get('/api/blog/{slug}', function (string $slug) {
    return Post::published()->whereSlug($slug)->firstOrFail();
});

Three lines, but I get it — that's not the same as a polished public API. Late 2026.

Plugin marketplace

Not building one. Extension model is Laravel service providers + middleware. If you know Laravel, you know how to extend it. If you don't, the learning curve is "Laravel itself," which is a real cost but a transferable one.

Visual page builder

The block editor handles structured content well. It's not a Webflow-style drag-and-drop layout designer, and probably won't be — different category. If you need that, Webflow or Storyblok is the right tool.

Multi-site / multi-tenant

Single site per install today. Agencies running 20 client sites run 20 installs (cheap on Hetzner — $5 × 20 = $100/mo for hosting; the license is per-site too).

The numbers

Concrete, not aspirational:

Lines of code: ~80K (PHP) + ~45K (TS/TSX) — a real product, not a toy
Pages in admin: 183
shadcn components: 50+
Themes shipped: 3
Memory footprint: ~80MB idle on Hetzner CX22
Cold start: ~250ms first request, ~40ms after warm
Build time: ~12 seconds (Vite + Inertia bundle)
Tests: ~600 PHPUnit tests, ~80% coverage on the critical paths

Pricing decision

One-time license per site. $99 Solo, $199 Pro, $499 Agency.

The reasoning: subscriptions hold customers' data hostage. A one-time license means a customer can install it, never pay again, and still own the install — code, database, content. If I disappear tomorrow, the install keeps working.

The downside: ARR is harder to project. The upside: customers actually trust me. After two years, I'd pick this model again.

Why I built it (the short version)

WordPress works for some sites. Contentful works for enterprise teams. None of them work for the in-between — small agencies and SMBs running 5–20 sites who want owned data, sane DX, and no monthly bill that scales with their growth.

UnfoldCMS is what I built for that gap. It's not the right answer for everyone — the comparison pages are explicit about who it's for and who it isn't.

Try it

Live demo (admin login on the page): https://unfoldcms.com/demo
Source: https://github.com/hpakdaman/unfoldcms
Docs: https://unfoldcms.com/docs
Comparison vs WordPress / Contentful / Sanity / Payload: https://unfoldcms.com/compare

Honest critique welcome in the comments — that's how the product gets better.

— Hamed

Building a themeable CMS admin with shadcn/ui + Tailwind v4 — lessons from 50+ components

hamed pakdaman — Sat, 09 May 2026 13:29:05 +0000

I shipped a Laravel CMS where the entire admin is built on shadcn/ui — 50+ components, 183 pages, three themes, runtime switching with no build step. Here are the five things that mattered most.

Why shadcn over Material UI / Ant Design

The deciding factor: shadcn components are my code. When I need to change a Button variant or extend DataTable, I edit the file. No npm overrides, no className wars, no vendor PR queue.

Tradeoff: when shadcn upstream ships a new pattern, I port it manually. Budget ~1 day/quarter for upgrades.

Lesson 1: Layout primitives save 100 pages of CSS

Three components used everywhere — PageContainer, Card, Stack. The PageContainer alone replaced ~40 page-level layout decisions. Three good ones beats 10 flexible ones.

Lesson 2: Tailwind v4 + CSS variables = themes without a build

@theme {
  --color-primary: oklch(0.55 0.27 262);
}
[data-theme="purple"] {
  --color-primary: oklch(0.55 0.27 304);
}

Switching themes:

document.documentElement.dataset.theme = 'purple';

No bundle changes. No re-render. CSS variables flip and every shadcn component updates because they reference the variable, not a hardcoded color. I expected theming to be the hard part — it took an afternoon.

Lesson 3: One Sidebar component, different data

shadcn's Sidebar is flexible enough to handle admin nav and docs nav with the same component. Data varies per-page; the component is shared. This is what makes a 183-page admin feel like one app.

Lesson 4: DataTable is the most underrated shadcn component

Every list view — Posts, Pages, Media, Users, Forms — uses the same DataTable wrapper. Server-side pagination, sorting, row selection, bulk actions, search. The columns array is the only per-page logic.

Lesson 5: TypeScript strictness is non-negotiable

shadcn ships excellent types. Don't loosen them. Every page-level component declares its props type explicitly, even when "obvious."

What didn't work

Tiptap as the rich-text editor. Great for free text, wrong for structured fields. Rebuilt on Tiptap's foundation with a custom block model — 3 weeks I'd have skipped with better evaluation.
Copying all 50 shadcn components up front. Only 30 actually got used. Copy on demand.
Tailwind v3 → v4 mid-build. ~4 hours of breaking changes. Start on v4 today.

What I'd use shadcn for again

Anything that needs custom design
Long-lived products where the maintenance cost is justified
Type-safe fullstack apps

What I wouldn't use it for: throwaway prototypes (use Mantine), marketing sites (Tailwind alone is faster).

Source: https://github.com/hpakdaman/unfoldcms
Live demo: https://unfoldcms.com/demo

I'm Hamed — built UnfoldCMS because none of WordPress, Contentful, or Strapi/Payload fit my Laravel shop. Honest critique welcome.

What frustrates you most about your current CMS?

hamed pakdaman — Tue, 21 Apr 2026 06:55:28 +0000

Hey developers! 👋
I'm working on improving a Laravel-based CMS and want to understand what actually matters to developers when choosing/using a CMS.

Quick question

What's your biggest frustration with your current CMS (WordPress, Strapi, Contentful, etc.)?
Is it:

Performance/bloat?
Poor developer experience?
Expensive pricing?
Difficult customization?
Security concerns?
Something else entirely?

Bonus: What CMS are you currently using and why haven't you switched?

Not trying to sell anything—genuinely trying to understand what sucks and what doesn't. Your honest feedback helps build better tools for all of us 🙏