WordPress Development Frameworks: The Four Categories

Search for WordPress development frameworks and you get the same list every time: Genesis, Divi, Redux, Gantry, Sage, maybe Bootstrap for no reason at all. Presented as alternatives. They are not alternatives. They do not compete, they do not overlap, and three of them will not help you with the problem the fourth solves.

That confusion has a cost. People choose a theme framework when they needed a build stack, or a page builder when they needed structured content, and then spend two years fighting the thing they installed in an afternoon.

This post splits the term into the four categories it actually contains, says which options in each are still maintained in 2026 and which are quietly dead, and shows why full site editing has removed the need for a theme framework on a large share of projects.

What a WordPress development framework actually is

A framework is a pre-built layer that removes decisions you would otherwise make yourself, and the word gets applied to four layers of the WordPress stack that have nothing in common except that description.

• Theme layer. Starter themes and theme frameworks: a parent theme or scaffold you build a design on top of. Genesis, Sage, GeneratePress, Astra.
• Native layer. Block themes plus theme.json: the design system WordPress core now ships with, no third party involved.
• Stack layer. Composer, Bedrock, wp-env, WP-CLI, build tooling. What “framework” means to a team that deploys from git.
• Data layer. Options and custom-field frameworks: ACF, CMB2, Carbon Fields, Redux. These define how editors enter structured content.

You can use all four at once. A Bedrock project running a Sage theme with ACF field groups is a perfectly normal build. So the real question is never “which framework”, it is “which layer is my problem in”.

Category 1: starter themes and theme frameworks

This category is the oldest meaning of the term and it is the one that has shrunk most, because the thing it existed to provide is now in core. The category also splits cleanly into two groups that people keep treating as one.

The ones that are still moving

Sage from Roots is the developer-facing option that is genuinely current. Version 11 shipped with Acorn v6, a PHP 8.3 minimum and Vite as the build tool, and releases have continued through 2026. It gives you Blade templating and a real asset pipeline. It also assumes you are comfortable with Composer and npm, and it is a bad fit for anything a non-developer will maintain.

GeneratePress, Kadence, Blocksy and Astra are the commercial classic themes that absorbed most of what Genesis used to do. All four ship a free version on WordPress.org and sell a premium add-on. All four are classic themes with block editor support rather than full block themes, which matters more than the marketing suggests: none of them carries the full-site-editing tag in the theme directory.

The ones that are effectively legacy

Underscores (_s), the starter theme half the WordPress world learned on, is finished. Automattic archived the repository on 5 September 2025 with a note saying the project is all-in on block themes and _s will not be actively updated. It is read-only. Any tutorial that still opens with “start by downloading Underscores” was written for a WordPress that no longer exists.

Genesis is a subtler case. It is not abandoned: WP Engine open-sourced the framework, made it free, and the changelog shows a 3.6.x release in 2026 handling PHP and core compatibility. But compatibility releases are not development. Genesis Pro sits at $360 per year, and you are paying that to stay on a hook-and-filter architecture that core has moved away from. If you already run twenty Genesis sites, keep them. Starting a new one in 2026 is a choice you will have to justify to whoever inherits it.

Option	Licence and price	Actively developed	Block editor / FSE	Learning curve	Lock-in risk
Block theme + theme.json	GPL, free	Yes, in core	Native FSE	Moderate, JSON and template syntax	None. Markup is core blocks
Sage (Roots)	MIT, free	Yes, v11.2.x in 2026	Block editor yes, FSE not the model	Steep. Composer, Blade, Vite	Low, but only a dev can maintain it
Underscores (_s)	GPL, free	No. Archived Sep 2025	Classic only	Low	Low, it is just a scaffold
Genesis	GPL, free; Genesis Pro $360/yr	Maintenance-level only	Classic with block support	Moderate, hook-driven	High. Child themes are Genesis-specific
GeneratePress	Free theme; GP Premium $59/yr, GeneratePress One $149/yr	Yes	Classic theme, block editor support	Low	Moderate, premium modules
Kadence	Free theme; plans from $99/yr per site	Yes, theme 1.5.x Jul 2026	Classic theme, block editor support	Low	Moderate, Kadence Blocks content
Blocksy	Free theme; Pro $69-$149/yr, lifetime $199-$499	Yes, 2.1.x Aug 2026	Classic theme, block editor support	Low	Moderate
Astra	Free theme; Pro from $99/yr, lifetime from $279	Yes, 4.13.x Aug 2026	Classic theme, block editor support	Low	Moderate

Category 2: block themes and theme.json

Block themes with a theme.json file are the native replacement for what a theme framework used to sell you, and for a large share of projects they remove the need for one entirely. The handbook is blunt that block themes are the modern method of building for WordPress.

Look at what a theme framework’s options panel actually gave you: colour palette, font sizes, spacing scale, content and wide widths, per-element style overrides, and a way to stop clients breaking any of it. Every one of those is now a key in a JSON file that core reads. The version 3 schema is current and works with WordPress 6.6 and later.

{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 3,
  "settings": {
    "appearanceTools": true,
    "layout": { "contentSize": "680px", "wideSize": "1180px" },
    "color": {
      "custom": false,
      "defaultPalette": false,
      "palette": [
        { "slug": "base",     "color": "#ffffff", "name": "Base" },
        { "slug": "contrast", "color": "#1a1a1a", "name": "Contrast" },
        { "slug": "accent",   "color": "#c8462a", "name": "Accent" }
      ]
    },
    "spacing": {
      "defaultSpacingSizes": false,
      "spacingSizes": [
        { "slug": "30", "size": "clamp(1rem, 2vw, 1.5rem)",   "name": "S" },
        { "slug": "50", "size": "clamp(2rem, 4vw, 3rem)",     "name": "M" },
        { "slug": "70", "size": "clamp(3.5rem, 7vw, 6rem)",   "name": "L" }
      ]
    },
    "typography": { "fluid": true, "customFontSize": false }
  },
  "styles": {
    "spacing": { "blockGap": "var(--wp--preset--spacing--50)" },
    "blocks": {
      "core/button": {
        "color":  { "background": "var(--wp--preset--color--accent)" },
        "border": { "radius": "3px" }
      }
    }
  }
}

Two lines in there do most of the governance work. "custom": false removes the arbitrary colour picker, and "customFontSize": false removes the arbitrary font size box. Editors get your palette and your scale, nothing else. That is the client-proofing a premium theme framework used to charge for, expressed as four words of JSON.

If your framework’s main selling point is a settings panel, core already has it, and core will still have it in ten years.

Where block themes still struggle: heavily custom archive logic, complex conditional layouts, and any design that needs markup core blocks do not produce. Those are real, and they are the honest argument for staying on a classic theme with PHP templates.

Category 3: development stacks and tooling

To a professional team, “framework” means the stack around WordPress rather than anything inside wp-content, and this is the category where the tooling has improved most in the last five years.

• Bedrock restructures WordPress as a Composer project: core, plugins and themes become dependencies, config moves to environment variables, and web/app/ replaces wp-content. Actively released, with 1.31.4 tracking WordPress 7.1 in August 2026.
• wp-env is the official Docker-based local environment, maintained inside the Gutenberg repo. One config file, one command, identical for everyone on the team.
• Local is the GUI alternative from WP Engine, free including the features that used to sit behind Local Pro. It is the right answer for anyone who does not want Docker in their life.
• @wordpress/scripts is the official build config: build, start, lint-js, lint-style, test-unit-js, plugin-zip. It exists so you never hand-write a webpack config for a block again.
• WP-CLI is the piece that makes everything else scriptable, from scaffolding to search-replace to database exports.

None of this touches how your site looks. That is the point. If your actual complaint is “deploys are manual and staging does not match production”, no theme framework on earth fixes it, and this is the layer to spend your effort on. The wider WordPress development toolset is worth a pass before you commit to a stack.

Category 4: plugin and options frameworks

These frameworks define how structured content gets entered and stored, which makes them the hardest of the four to change your mind about later. Their current status varies wildly and the differences are not obvious from their marketing.

• ACF remains the commercial default. ACF PRO is $49/year for one site, $149 for ten and $249 for unlimited, annual renewal, no lifetime tier. Since the 2024 WordPress.org dispute the free version distributed through the repository is the forked Secure Custom Fields, currently at 6.9.x, which deactivates ACF and ACF PRO on install to avoid function collisions. Decide which one you are on deliberately.
• CMB2 is free, GPL, code-defined rather than UI-defined, and still shipping. Version 2.12.0, around 300,000 active installs. Good for plugin authors who need fields without a paid dependency.
• Carbon Fields is alive but explicitly feature-complete. The maintainers have said publicly that the block editor makes it unnecessary for most CMS use cases and that it is maintained for their own needs. That is a fine reason to keep an existing site on it and a poor reason to start a new one.
• Redux is still updated (4.5.x, 900,000+ active installs) but it solves a problem that mostly evaporated. It is an options framework for theme settings panels, and theme settings panels are what theme.json replaced.

The lock-in bill that arrives three years later

Framework lock-in is not felt when you build the site, it is felt when someone else has to change it, and the severity depends entirely on where your content physically lives in the database.

A theme framework has mild lock-in. Genesis child themes call Genesis hooks, so moving off Genesis means rewriting templates, but post_content is still readable HTML. Annoying, bounded, quotable as a job.

Builder lock-in is a different order of problem, and it has a specific mechanism. Shortcode-based builders write their layout into post_content as nested shortcodes. Deactivate the builder and the page does not revert to plain content; it renders the raw shortcode text to visitors. Elegant Themes admitted this directly when explaining why Divi 5 moved away from shortcodes, listing leftover shortcodes in post content after moving away from Divi as one of the problems the new format fixes.

The other failure mode is worse. Builders that store layout as serialised or JSON data in wp_postmeta put your content outside post_content altogether. Search and replace across a serialised blob breaks the byte-length prefixes PHP uses, so a naive SQL find-replace during a domain migration silently corrupts pages. And because the visible text lives in a private meta field, there is no clean export: migrating means rebuilding every page by hand.

What actually makes a WordPress development framework slow

Frameworks are slow for mechanical reasons you can inspect in a browser, not for mystical ones, and four patterns account for most of it.

1. Unconditional enqueues. The theme loads its slider CSS, icon font and carousel JS on every page including ones with no slider, because the enqueue is not gated on whether the module is used.
2. jQuery as a hard dependency. Anything still built on jQuery pulls core’s copy plus its own plugins, and those are render-affecting scripts on pages that need no JavaScript at all.
3. Inline CSS per section. Builders that emit a style block for every row and column inflate the HTML document itself. That weight is uncacheable at the CSS layer because it is part of the page.
4. Asset count. Twelve small stylesheets cost more than one, and a framework with a modular architecture often ships exactly that.

You can test any candidate yourself in ten minutes without trusting anyone’s benchmark. Install the free theme on a clean site, build one representative page, then open the network panel and count requests and total transferred bytes. Repeat on a page that uses none of the fancy modules. If the numbers barely move, the theme is enqueuing unconditionally and it will not get faster later.

Then check that your caching layers are actually engaging on the result, which is what Cache Inspector in our toolbox is for, and work through the basic steps that make a site run faster before you blame the framework for something your stack is doing.

When a framework is the wrong choice

A framework is overhead that pays for itself across repetition, so it is the wrong choice whenever there is no repetition to spread it over. Four situations where reaching for one makes things worse:

• A single-page or brochure site. A block theme and four patterns will beat a framework you have to learn, configure and license.
• A site the client will never edit. Most of a theme framework’s price is the editing UI. If nobody opens wp-admin after launch, you are paying for a control panel with no user.
• A team that already knows one tool well. Fluency in a mediocre tool beats a better tool nobody has used. Switch on a project you can afford to be slow on, not a deadline.
• Anything being handed to another developer in two years. The next person knows core WordPress. They may not know your framework’s hook names, and they will bill for learning them.

Three specific mistakes worth naming. Editing a parent theme directly, which an update erases: build a child theme in two minutes instead, and if you need to replace a parent function, learn how pluggable functions and hook removal actually work rather than commenting things out. Stacking a page builder on top of a theme framework, which gives you two competing layout systems and two sets of CSS to unpick. And buying a lifetime licence as a hedge against abandonment: a lifetime licence guarantees you access to the files, not that anyone is still writing them.

How to start without over-committing

Start with core tooling and a block theme, prove the design works, and only add a framework when you hit something core genuinely cannot do. Here is the whole path in commands.

Spin up a disposable local environment. wp-env needs Node and a running Docker Desktop, and lands on http://localhost:8888 with admin/password.

npm -g install @wordpress/env
cd my-project
wp-env start
wp-env clean all      # reset the database
wp-env destroy        # tear the whole thing down

Create a child theme properly. WP-CLI writes the Template: header for you, which is the part people get wrong by hand.

wp scaffold child-theme colt-child \
  --parent_theme=twentytwentyfive \
  --theme_name="Colt Child" \
  --activate

Then copy the parent’s theme.json into the child, cut it down to the settings you care about, and iterate there. Overrides merge onto the parent, so a twenty-line child theme.json is normal and correct.

For custom blocks, note that the scaffold command family has moved on: wp scaffold block is deprecated and the supported route is the official create-block package.

npx @wordpress/create-block colt-pricing-table
cd colt-pricing-table
npm start

Verdict: which WordPress development framework to pick

For most projects in 2026 the correct answer is no theme framework at all: a block theme, a disciplined theme.json, and effort spent on the stack layer instead. The exceptions are real but narrower than the listicles suggest.

Project type	Recommended approach	Why	Rough cost	Main risk
One-off small business site	Block theme plus theme.json, no framework	Nothing here needs a settings panel core does not already provide	$0 in licences	You hit a layout core blocks cannot produce and have to write a block
Client site an agency maintains for years	Custom block theme, or a classic theme you wrote, under version control	Handover cost dominates. Core knowledge transfers, framework knowledge does not	More build hours, no recurring fee	Higher up-front hours to justify to the client
High-traffic publisher	Lean custom theme plus Bedrock and a real deploy pipeline	Asset count and cache behaviour matter more than editing UI	Engineering time, hosting	Over-engineering a site whose real bottleneck is caching
Product or plugin business	@wordpress/scripts, wp-env, WP-CLI, CMB2 if you need fields	You ship to other people’s sites, so a paid field dependency is a support burden	$0 in licences	Free field libraries move slowly; check status before you depend on one
Headless build	Core plus ACF or SCF, REST or GraphQL, no theme layer	The theme is a rendering layer you are not using	ACF PRO from $49/yr if you use it	Editors lose live preview unless you build it back

If you build one or two sites a year and want them fast, take GeneratePress or Blocksy, buy the cheapest tier, and stop reading comparison posts. If you are a developer building for clients, learn block themes and theme.json properly; it is the only skill on this page guaranteed to still be relevant in five years. If you already have a Genesis or Sage practice that works, keep it and do not migrate for fashion.

And if you are choosing a page builder as your framework, choose one that stores content in a format you can read without it. That single constraint will save someone a rebuild.

Frequently asked questions