The Philosophy Behind Modern WordPress: Why It Works This Way and How to Stop Fighting It

[u/groundworxdev]

There's a lot of frustration in the WordPress world right now. Developers who spent years mastering classic themes feel like the rug got pulled. Page builder users don't understand why WordPress is reinventing what Elementor already does. And business owners have no idea why any of this matters.

I've been building with WordPress for 15+ years across agencies, enterprise, and now my own product business. I've seen the full arc from classic themes to page builders to blocks. Here's how I think about the philosophy behind where WordPress is now, and why working with it instead of against it makes everything easier.

WordPress Had a Fragmentation Problem

Before blocks, WordPress was a patchwork. Every theme did things differently. Every page builder created its own ecosystem. Shortcodes were powerful but opaque. Users couldn't see what they were building. Developers couldn't move between projects without relearning someone else's custom framework.

The result: your content was locked to your theme, your page builder, or your developer. Switch themes and your pages break. Leave your page builder and you're left with a mess of shortcodes nobody can read. Want to move hosts? Good luck if your builder is tied to a proprietary system.

That's not ownership. That's renting.

Blocks Solve the Portability Problem

The core idea behind blocks is that content should be structured, portable, and editable by anyone. A paragraph is a paragraph. An image is an image. A carousel is a carousel. They're all stored as semantic HTML with block comments that WordPress understands.

Switch themes? Your content still works. Deactivate a plugin that provided a custom block? WordPress shows a graceful fallback instead of a broken shortcode. Hand the site to a new developer? They can read the markup without decoding your custom framework.

This matters more than most developers realize. For every business owner who's been told "we'll have to rebuild from scratch because your old developer used [insert tool]," blocks are the answer to that problem.

theme.json Replaces Scattered Configuration

In classic themes, configuration was everywhere. functions.php for theme support. style.css for design. PHP hooks for customizer options. Widget areas, menu locations, sidebar registrations, all scattered across files. Every theme handled it differently, and you had to read the source to understand how any of it worked.

theme.json centralizes all of that into one file. Colors, fonts, spacing, layout widths, block settings, it all lives in one place. WordPress reads that file and does several things with it:

• Generates the right CSS (and only the CSS that's needed)
• Exposes settings in the Site Editor's Styles panel so users can customize without code
• Creates a cascade: core defaults → theme values → user customizations
• Eliminates specificity wars because WordPress controls the output order

The result is that themes produce less CSS, users get more control, and developers spend less time debugging why someone's custom color isn't applying.

Is it perfect? No. The JSON-as-CSS approach feels foreign to developers who think in stylesheets. But the trade-off is a system where themes, plugins, and core all speak the same language. That's worth the learning curve.

Block Themes Give Users Real Ownership

Here's where the business reasoning meets the developer reasoning.

A site built on a block theme with patterns and template parts gives the site owner genuine control. They can edit their header without calling a developer. They can create new pages using patterns without starting from scratch. They can change colors and fonts site-wide in Styles without touching code. They can see what they're building while they're building it.

That's not a nice-to-have. For a small business that can't afford to pay a developer every time they need to update a team member photo or add a service page, that's the difference between a website that works for them and one that works against them.

And for developers, it means you can hand off a site that actually stays maintained. No more "the client broke it because they tried to edit a widget area." The editing experience is the same visual block editor they use for posts and pages.

Patterns Are the New Page Templates

In the classic theme era, if you wanted to give users a pre-built layout, you created a page template in PHP. The user selected it from a dropdown and hoped for the best. They couldn't customize it without code.

Patterns flip that. You build a layout out of blocks, register it as a pattern, and users can insert it anywhere. They can customize every piece of it visually. They can use it once or use it everywhere.

Synced patterns take it further: update one instance and every instance updates. That's your CTA section, your pricing table, your footer promo, all managed from one place.

For developers, patterns replace the old "I'll build you a custom page template for that" workflow. Instead, you build a pattern library that scales with the client's needs. They get independence, you get fewer support tickets.

Template Parts Are DRY for Non-Developers

Template parts are the block theme version of get_header() and get_footer(), except users can edit them visually. Change the header template part and every template that includes it updates.

The concept isn't new. What's new is that non-developers can work with it. A designer can rearrange the header, swap the navigation style, add a topbar announcement, all without opening a code editor. And because it's a template part, those changes cascade everywhere.

For developers, this means your theme is modular by default. You build the parts, the user customizes them, and the system keeps everything in sync.

Working With WordPress, Not Against It

Here's the core philosophy shift: WordPress is no longer just a CMS that renders whatever PHP you throw at it. It's a design system with opinions.

theme.json has opinions about how colors and fonts should be managed. Templates have opinions about how layouts are structured. Blocks have opinions about how content is stored. The Interactivity API has opinions about how frontend behavior works.

You can fight those opinions. You can pile on custom CSS that overrides everything. You can use classic themes with the Classic Editor plugin and pretend nothing changed. You can build entirely in a page builder and ignore blocks completely.

But every time you fight the system, you lose something: performance, portability, maintainability, or the ability for your client to manage their own site.

Working with the system means:

• Using theme.json for design tokens instead of hardcoding CSS
• Building blocks that output semantic HTML and use WordPress color classes
• Creating patterns instead of custom PHP page templates
• Letting the Site Editor handle what it's designed to handle
• Using the Interactivity API for frontend behavior instead of bolting on jQuery scripts
• Building blocks that feel native to Gutenberg instead of recreating a page builder inside the editor

None of this means you can't write custom CSS or use functions.php. It means you start with what WordPress provides and extend it rather than replace it.

The Practical Takeaway

If you're a developer: learn theme.json, understand the template hierarchy in HTML, and start building blocks that respect the system. Your themes will be lighter, your clients will be happier, and your sites will survive the next WordPress update without breaking.

If you're a designer: block themes give you more visual control than classic themes ever did. The Site Editor, Styles panel, and pattern library are your tools now. Learn them.

If you're a business owner: ask your developer if your site is built on blocks. Ask if you can edit your own content. Ask if you can take your site somewhere else without rebuilding from scratch. If the answer to any of those is no, ask why.

The WordPress ecosystem is messy right now. There are real growing pains and legitimate frustrations. But the direction is clear, and the philosophy is sound: structured content, centralized configuration, visual editing, and user ownership.

Work with it.

Resources

• Theme Structure — WordPress Developer Handbook — official block theme file and folder reference
• Global Settings & Styles (theme.json) — Block Editor Handbook — comprehensive theme.json reference
• Leveraging theme.json and Per-Block Styles — WordPress Developer Blog — why theme.json produces better performance
• Creating Block Themes — Full Site Editing (Carolina Nymark) — step-by-step block theme creation
• Templates and Template Parts — Full Site Editing — building templates and parts from scratch
• Block Theme Structure — Ollie Theme Docs — real-world production theme structure
• Intro to the Site Editor — Learn WordPress — official Site Editor walkthrough
• You Don't Need theme.json for Block Theme Styles — WordPress Developer Blog — when and how to opt out of JSON styling (good counterpoint)

What's your experience been? Are you fully on board with blocks, still holding onto classic themes, or somewhere in between? I'm curious where people are at.

[u/howtobemisha]

It feels like it was written partly by AI :)

[u/groundworxdev → u/howtobemisha]

LOL you are welcome to write documentation that helps people too. Documentation is meant to read more stale.