The Trouble with WordPress Frameworks

wordpress theme frameworks

This article explains what WordPress frameworks are, and why I generally recommend against relying on them.

In this article, I’ll be looking at WordPress frameworks, including WordPress theme frameworks as the most common category, as well as plugin-based and other kinds of frameworks.

I’ll define what I mean by “WordPress framework,” explain how a framework is different from simply a tool in WordPress, and outline the issues I find with WordPress frameworks that cause me, in general, to recommend against relying on them.

This isn’t an “always/never”-type article: frameworks have their strengths, and their place in the WordPress ecosystem. However, I do consistently have the same kinds of problems, for the same reasons, with WordPress frameworks, and I do steer clear of them when I can. I’ll even make it a point to use only part of a framework I like (for example, Beaver Builder but only the page builder), just to avoid getting roped further in.

My goal is to give you a chance to consider the strengths and liabilities of WordPress theme frameworks and other frameworks, and how you want to approach them in your own WordPress work.

What I Mean by “WordPress Frameworks”

A “WordPress framework” is a piece of software that tries to solve a bunch of problems at once within the WordPress ecosystem.

To define “WordPress framework,” let’s start by defining “framework.” I mean that term in its broadest sense: a framework is a piece of software that tries to solve a bunch of problems at once through a single, central system and approach.

So a framework is like a Swiss Army knife: a corkscrew and a file and a tweezers, not sold separately but all coming off a single common base. Need to do something—anything? Reach for your Swiss Army knife. That’s the idea of a framework.

Adding in the WordPress piece: a “WordPress framework” is a piece of software that tries to solve a bunch of problems at once within the WordPress ecosystem.

What this is different from is a WordPress tool: a piece of software that tries to solve one problem in the WordPress ecosystem.

So that this doesn’t feel too abstract, let me give you some examples.

Examples of WordPress Frameworks

I’ll break these examples down into two categories: WordPress frameworks that are reasonably well-built and okay for what they do, and frameworks that, in my humble but also extremely well-informed opinion, are not.

Good and Okay Frameworks

Some frameworks are good or okay: you can see why someone would benefit from them, why someone put them together the way they are, and so on. A few names in this list include (in no particular order):

  • Genesis.
  • Jetpack.
  • WPMU Dev.
  • BoldGrid.
  • The Beaver Builder ecosystem, which includes Beaver Builder, Beaver Themer, and more.
  • Elementor Pro, which combines the basic Elementor page builder and a feature called Elementor Theme Builder.

Not-Great and Bad Frameworks

And some WordPress frameworks are not great. Some are even bad. Not much more to say about this, but here are a few examples in the not-great to super-not-good range, specifically in the very common category of WordPress theme frameworks:

There also exist many older and less well-maintained theme frameworks that were good at one point but have fallen by the wayside—as well as entire approaches to getting around the basics of WordPress development (such widgetizing everything you can imagine) that no longer exist. That frameworks age out of existence like this is one thing that makes relying on them tricky.

WordPress Theme Frameworks, and Other Kinds

WordPress theme frameworks are the most common type, because the market most often sees themes as the “thing you buy” to “do WordPress.”

In the list above, you’ll notice mostly WordPress theme frameworks: ways of approaching WordPress that use the theme as the starting unit.

In general, this is because—despite the logic that a theme should handle only presentation and not data to prevent theme creep—the broader marketplace is still most likely to see a theme, rather than a plugin or something else, as the “thing you buy” to “do WordPress.” As a result, most “do WordPress”-type framework solutions have been theme-based.

There are exceptions, though: Jetpack and WPMU Dev are plugin-based frameworks that are designed to solve many or most needs a WordPress site might come across. Elementor and Beaver Builder started as page builder plugins and grew from there. And BoldGrid originated as an all-in-one WordPress development solution offered by the hosting company who developed it, InMotion.

Whether it’s a theme framework or something else, the common thread with any WordPress framework is that it finds a way to enter early in the user’s website setup journey, with the logic that “this is how you do WordPress.”

Not All Complex Tools are WordPress Frameworks

Just having a wide range of functionality doesn’t make a tool a “framework,” in the sense I mean in this article. Below are some complex tools that still aren’t frameworks:

  • Yoast, which handles a wide range of SEO tasks on a WordPress site.
  • WooCommerce, which enables a full-featured e-commerce experience in WordPress.
  • Beaver Builder—just the plugin, not the plugin-plus-theme—which greatly improves layout creation in WordPress.

Each of these tools is a significant addition to a WordPress site, but each one has a specific job to do in WordPress. They’re the way you do something in WordPress: it wouldn’t make sense to market them as simply “a better way to do WordPress,” full stop. That’s the difference between a tool and a framework.

Common Properties of WordPress Frameworks

By their nature as projects that try to solve a lot of things at once, WordPress frameworks tend to share some similarities. In general, WordPress frameworks:

  • Describe themselves in very general terms, as the best way to summarize the range of things they try to do. A tool’s quick description might be something like “Quickly regenerate your image thumbnails.” A framework’s might be “WordPress + Framework = Awesome.”
  • Replace one or more existing parts of WordPress, in favor of their own way of doing things. Tools usually add things to WordPress that weren’t there before; frameworks generally add and replace.
  • Carry a training burden, to get you up to speed in the many facets of their own way of thinking about WordPress. A relatively complex tool (such as Yoast) might carry a training burden, but a WordPress framework is almost guaranteed to.
  • Are very difficult to turn off, because you lose a ton of things all at once.

Let’s look at two examples to see these properties in action:

Jetpack

What it is: An all-in-one plugin shop by Automattic designed to make WordPress better.

How it describes itself: “The ideal way to experience WordPress.” Offers “always-on security,” “built-in performance,” “code-free customization,” and “effortless marketing.” “The best way to WordPress is with Jetpack.”

What existing system it replaces: The WordPress plugin repository.

Training burden: Learning to connect to Jetpack using a WordPress.com account, use multiple plugins with separate configuration requirements, debug interactions between Jetpack plugins and other parts of WordPress.

Turn it off and: A potentially wide array of things break at once, from Google Analytics to image optimization to WooCommerce shipping. These things can break even by deactivating and then reactivating the plugin, as doing so can prompt Jetpack to demand that you reauthenticate with WordPress.com.

Divi

What it is: An integrated theme-plus-page-builder.

How it describes itself: “Divi takes WordPress to a whole new level.” “You’ve never built a WordPress website like this before.” “Divi is more than just a WordPress theme, it’s a completely new website building platform.” “Divi isn’t just a WordPress theme, it’s a complete design framework that allows you to design and customize every part of your website from the ground up.”

What existing system it replaces: Various plugins: user role management, mailing list management, marketing automation.

Training burden: Learning the Divi builder’s way of conceptualizing layouts, and the places various theme options.

Turn it off and: Your entire site collapses into a mess of shortcodes. You also lose whatever data you may have added to Divi, from user roles to A/B testing to social media links to whatever else.

We’ll return to these examples through the rest of this article.

Advantages of WordPress Frameworks

Frameworks simplify a large and diverse technical topic into a single, less technical approach.

WordPress theme frameworks, as well as other types of WordPress frameworks, have one advantage: they simplify a large and diverse technical topic into a single, less technical approach.

Without Divi, creating a WordPress website is an intricate job that involves choosing a clean, simple, well-fitting theme, knowing which of a number of narrowly useful plugins meet your goals for the site, making a good relationship with a WordPress page builder, and—yes—even knowing PHP. The documentation for each of these things is spread all over creation, and there’s no good way to know which pieces of knowledge you may be missing.

With Divi, everything is centralized into the Divi way of doing things. The documentation is all within Divi, and the knowledge you need is limited to what Divi teaches.

So the value proposition of frameworks is clear and palpable. If I wanted to build a WordPress website in a weekend with no training—and didn’t really care how it worked under the hood or whether it’d be stable or extendable into the future—then Divi or a framework like it is probably close to the best decision I could make. (To be more specific, the Beaver Builder ecosystem would be my recommendation for people in this position, as it fills a similar role to Divi but is coded much better in my opinion.)

Again, it’s not hard to understand what makes frameworks attractive. Let’s look at the tradeoffs.

Liabilities of WordPress Frameworks

WordPress theme frameworks and WordPress frameworks in general carry significant costs to go along with the range of problems they aim to solve. Let’s look at many of the main ones.

The Framework Recursion Problem

WordPress is, itself, a framework for web development. What happens when you nest frameworks?

To understand this problem, let’s step back a bit and realize that WordPress is, itself, a framework for web development: that is, for creating better, more easily administered websites.

To show that WordPress is indeed a framework, let’s look at WordPress through the lens we’ve developed.

What it is: The world’s most popular content management system (CMS).

How it describes itself: “WordPress is open source software you can use to create a beautiful website, blog, or app.” “Beautiful designs, powerful features, and the freedom to build anything you want. WordPress is both free and priceless at the same time.”

What existing system it replaces: HTML, with database-backed PHP templates.

Training burden: The contents of WPShout and lots more.

Turn it off and: You lose everything.

In other words, just by working in WordPress we’ve already taken on a framework, a way of doing things: the WordPress way.

Now, what happens if we nest frameworks? What if we’re now committing to “the Divi way of doing things the WordPress way”?

We start to run into framework recursion:

wordpress framework problem

Symptoms of framework recursion include:

  • Problems that have multiple, competing solutions—there’s the framework way, and the framework-framework way. The framework way to manage user roles is with a plugin designed to do only that, but the framework-framework way is with a Divi theme feature. Which is better? What happens if you turn both on at the same time? This is an important source of the confusion that marks many WordPress projects.
  • Being prevented from understanding the working of the framework itself because of the heavy overlay of the framework-framework. What is a theme for? How is that different from what a plugin is for, or what a website is for? How should the WordPress template hierarchy work? These things are significantly more difficult to understand working in Divi or the X Theme—or even in Genesis—than they are in vanilla WordPress.
  • Suffering a blurry understanding of the difference between the framework and the framework-framework. Where does one begin and the other end? I uploaded an image through Divi. Do I still get to use that image if I get rid of Divi?

Fundamentally, framework recursion is about the unsteadiness that results when you stack all-in-one solutions on top of other all-in-one solutions. This unstable stacking is at the root of the other framework liabilities discussed below.

The Silo Problem

If you invest deeply in a framework, one result is that you will be limited to one way of thinking about problems.

If you invest deeply in a framework, one result is that you will be limited to one way of thinking about problems. A framework says, “Here’s the approach you’ll take to every problem you come across.” Even if that works, you lose flexibility.

I know what I’m talking about here: once again, WordPress is a framework, and to work as a WordPress developer is to have one’s technical world limited. As a WordPress developer—as distinct from a full-on software engineer, or from someone, like David, who is both—I see constantly how that job description makes it easy to accept limitations in the scope of my technical knowledge, and in the types of problems I’m able to solve.

Working almost entirely within WordPress has given me enormous powers on most kind of website projects. But it’s also made it very easy to stay ignorant on many topics in full-on software development: the kind they used to build Uber, or, for that matter, Uber’s fleet of self-driving cars.

In my opinion, WordPress development is siloed enough without further siloing oneself into one particular approach to it.

Since we’re in WordPress already, the question becomes whether you should be paying a double tax: to limit yourself to being, say, a Divi or Elementor implementer—someone who looks at WordPress only through a Divi or Elementor lens—rather than a full-on WordPress developer.

If I were just starting out, that would be tempting, but having learned WordPress the hard way I’m grateful for the expanded scope. To be limited, within the already limited world of WordPress, to solving only framework-accessible problems is to be restricted from working fully comfortably even within WordPress. WordPress development, in my opinion, is siloed enough without further siloing oneself into one particular approach to it.

The Cruft Problem

Did you ever download an “all-in-one” ThemeForest theme with 20 homepage options? Much like certain kinds of fast food, that seems good until you buy it.

A website only has one homepage. The moment you set up the theme, 19 of those homepage options become cruft: code that is there, but serving no useful purpose.

Cruft is not neutral; it’s bad. Consider that the theme developers had to code the homepage as a massive “if”-statement between those 20 theme options. Your theme will be bulkier, slower, and harder to work with because of the 19 homepage options you aren’t using.

Frameworks are a great source of cruft—stuff you don’t need but can’t get rid of—because they try to do everything at once.

Frameworks are a great source of cruft—stuff you don’t need but can’t get rid of—precisely because they try to do everything all at once.

WordPress itself has a fair amount of cruft. Do you remember the “Press This” bookmarklet, or post formats? In addition to the features nobody uses, some parts of WordPress are situationally cruft. For example, for a simple website with only static Page content, the entire “Post” post type—with its Category and Tag taxonomies and so on—is cruft.

We accept these unneeded parts of WordPress because the bulk of WordPress is so useful in a vast majority of cases. But what about if we now add framework-frameworks? On a given project, do we really need Divi’s:

  • A/B testing feature set (when we have better-designed tools for this)?
  • Proprietary contact form builder (when we have Gravity Forms)?
  • “Over 800 pre-made website layouts”?

These things are sitting in the theme and builder whether we need them or not, making it bulkier and harder to work with: more convoluted theme template files, worse performance, more space on the filesystem and database. This is because frameworks do everything.

Now: what if you’ve got Divi and Jetpack? What if you’ve got the Divi Builder and Jetpack on a Genesis theme? What if you want to use the Divi theme but the WPBakery page builder?

If these solutions were simply tools—like Yoast or WooCommerce—mixing them wouldn’t seem insane. But they’re frameworks, and using them together is not at all fun to imagine because of the massive cruft collisions that would result.

The Lock-In Problem

That frameworks are difficult or impossible to turn off is definitely Not a Good Thing.

As we’ve mentioned, you can’t turn a framework off without losing everything. This is definitely Not a Good Thing, for reasons you could describe in a number of ways.

Each of the frameworks listed above wants your money in one way or another. When you stop paying, you will slowly lose access—most commonly, because when your framework updates your framework-framework doesn’t.

If you’ve ever worked on a site that uses the old Visual Composer, you know that this is to have your sadness compounded. WordPress will update fine from 3.x to 5.x, but buying a new premium license just for the privilege of breaking a Visual Composer site is a testament to the liabilities of framework-framework development.

Frameworks: Do They Really Make the Drame Work?

Again, I’m not saying “No frameworks, none of the time.” But I really do try to stay away from all-in-one solutions when feasible. In the approach I try to take, WordPress itself is the framework: the Swiss Army knife whose various tools solve my needs in web development. I learn each of those tools deeply, use them for what they’re good for, and that’s it: no framework-frameworks needed.

I hope that’s helpful food for thought, and that as you choose how you’d like to approach WordPress development, you have a bit more of a conceptual… you know… framework.

Thanks for reading! As always, if you have any questions or thoughts, leave them below, or we’d love to hear from you in our Facebook group.


18 Responses

Comments

  • Hey Fred, I really enjoyed this article. Thanks fo sharing!
    I had a thought (note: I’m not a developer by any means, this may be a silly comment). Is it possible for a company like WPMU DEV to be both a framework and stand alone product? For example, you don’t need every WPMU DEV plugin to run Smush on your website. Does that make sense? (Full disclosure: I work for WPMU DEV) 😀

    Anyway, thanks again!

  • I really enjoy this post content. Thanks already!
    I thought that the generatepress theme has framework too. If that’s true, why didn’t you feature it as well?

  • Steve says:

    Would have loved to have heard how you think Oxygen Builder compares and ranks as a viable framework.
    It is the only true “site builder” as it is the first solution to disable the WP theme system completely.

  • Kevin Trye says:

    Excellent article. You’ve outline the frustrations we come across every week as a developer who does a lot of site repairs. The worst are those three you mentioned. For me our starting point is genesis, however designers or business people lacking coding skills often want more. For them we’ve used generatepress, wpastra and 18tags themes. For complex page layouts, elementor pro is tolerable although am looking are the latest Gutenberg options too, which have issues, but should improve over time.

  • Anh Tran says:

    There are 2 sides of the Silo problem: one that you described – you probably will have one way to solve a problem. The other side is you might be skilled enough to solve a problem *well*.

    It’s a gray area, since WordPress is trying to be a framework of the web itself. Just see how it tries to do with WooCommerce, bbPress, BuddyPress. The more we use WordPress in general and frameworks, the more familiarity and skill we get. And thus, we do the job better and faster. And in some case, it’s not the best solution.

    It’s always best to evaluate frameworks time to time to find out what are their advantages and disadvantages and see if they’re best for the job. They keep changing, so do we.

  • Guy says:

    I’ve been developing using Divi for a few years and it has made my life easier to churn out rather large jobs in a short amount of time. While it became my tool of choice I have been well aware of some of its niggles and frustrations you mention here and in your review.

    I’m going to give Beaver Builder a try, in part because I’ve definitely noticed while Divi can be pretty easy to use and extremely powerful it doesn’t churn out anything resembling slim code. For my next project I’m doing for a non-profit because on jobs like that I know I’m handing it off to someone who’s going to want their own people working on the site. That’s one of the big goals of frameworks – to eliminate the constant minor updates clients give you.

    There are two things missing from this though, one is I think you left out one of the most used frameworks and that is ACF. Along those same lines is the snobbery that exists in the WP community around frameworks and the “pro way” of custom styles and using something like ACF to give limited control to users. I didn’t get that feeling from your article but I’ve definitely felt it in the community.

    But getting back to the whole concept of frameworks the development community itself is rather hypocritical about this because I’m certain ALL of those pro designers start with a completely blank CSS file and write it all from scratch right? The same thing for those doing the code side, they never pick up snippets of code from here or there and then customize, right? There are frameworks everywhere of varying quality and objective, it’s up to the user to measure up what fits best for them and the project.

    When I sell a job, I’m selling myself and my project. I try to stay away from “I’m this massively awesome WordPress developer who will build you a fully custom site.” I think if we as a community focused a bit on what value we’re delivering and helping each other out and less time on “I’ve got the best toolbox” we’d be all the better for it.

    • Julius says:

      Your comment is spot on. Especially, ” I think if we as a community focused a bit on what value we’re delivering and helping each other out and less time on “I’ve got the best toolbox” we’d be all the better for it.”.

      Truthfully, I feel like clients are interested in paying for full custom based websites any longer. Since frameworks/site-builders are so prominent now, I feel like it solves my client’s problems.

  • Great article that encapsulates all the info probably most of us experienced by learning “the hard way.” Your WPShout course was the one bright spot I still rely on. In general, I’ve settled on Beaver Builder to make the job easiest for me to understand and control.

  • A.White says:

    You’ve read my mind with this post. I only recently came across Divi and at first got very excited to use it. In fact it saved me a ton of time redoing a big website about a year ago. Or did it? After experiencing it for over a year I realized that I’m being punished by my desire to finish the project sooner and cut corners. Now, for a regular guy with no knowledge of wordpress or web development in general, Divi might not be a bad idea. I don’t know. All I know is that it’s been a pain in the ass in my work. I will definitely stay away from it and the like in the future.
    I am a bit of a purist and sometimes even idea of wordpress rubs me the wrong way, but whadyagonnado?

  • reader says:

    what is a DRAME?

    • Fred Meyer Fred Meyer says:

      It’s a silly pun on the phrase “Teamwork makes the dream work” – so: “Frameworks make the drame work.”

      It was the Friday of a very busy week when I wrote that, if it helps. 🙂

  • Richard Leo says:

    Hey Fred! Nice article. But why do you catalog Visual composer as a bad framework?

    I work with many sites, some of them have elementor and I find it very hard, sometimes impossible, to customize details but with visual composer its pretty easy and straight forward. (at least with the backend editor, I never use the frontend editor). With Elementor I feel I have no real handling of the code and im tied to what it has, with visual composer I don’t get that feeling.

    I see Elementor as a frontend editor that tries to makes things so much easier that sometimes it gets very complicated, do you know what I mean?

    Let me know your thoughts.

  • Jason says:

    It’s been my experience that traditionally in WP circles “frameworks” are as bare-bones as possible; a place from which you can extend. A minimalist starting point upon which to build. Underscores, Genesis (stock), Bones, Sage, etc. The beasts mentioned above are page builders for the most part. Site builders. Not frameworks.

    • Fred Meyer Fred Meyer says:

      Thanks, Jason—I agree that those starter themes are sometimes called “frameworks” or “theme frameworks.” But then again, Genesis is also clearly a “theme framework” and is not bare-bones at all in the decisions it makes about how to architect a WordPress theme. Divi’s marketing materials do call it, among other things, a “design framework”; and so on.

      So I agree the terminology is used a bunch of different ways. I don’t know a better term than “framework” for “do-lots-of-things solution,” so that’s the language I’m using here.

  • Nigel says:

    When I realized the problem of being locked in with Divi, I turned it off for posts and generic page templates. I use Divi only for design-heavy tasks now. While Divi does add a mild amount of bloat to pages it’s mostly fixed by caching plugins and static site generators. While Divi helps get work done faster, ideally I shouldn’t be using it.

    Moral of the story: Junk food is nice, just don’t make it your diet.

  • Lars Faye says:

    As everyone else said, this was a really fantastic article, and very necessary.

    I echo what @Guy said above regarding ACF, although its a bit of a stretch to consider it a framework, as much as it’s a vehicle for a more streamlined custom development process via custom post types/templates/fields.

    But Guy is right as well, that defining a framework does get muddy at a point. Yes, I re-use a lot of tried and tested blocks of code that I’ve written prior, from slideshows to mobile navigation implementations. But I wouldn’t be able to say what I do is a framework, but rather an increasingly more efficient custom development workflow.

  • Matthew says:

    Thanks for this:

    “If I wanted to build a WordPress website in a weekend with no training—and didn’t really care how it worked or whether it’d be stable, usable, or extendable into the future—then Divi is probably close to the best decision I could make.”

    Divi’s code makes my stomach churn and my blood boil: floats, Russian-doll-inside-of-another-Russian-doll nested divs, and virtually no use of grid or flex. It’s a framework alright, a tool to allow agencies to claim they “build custom WordPress Themes” when in reality they have one junior designer on staff who “knows a little CSS.”

    I love (most) agencies and (all) designers, but using Divi is a slap in the face to anyone who cares about:

    The openness of WordPress
    The ease of use of WordPress
    content belonging, fully, to the end-user

    Basically, when I’m working with Divi, I lose all faith in humanity. I come back and read this to calm myself. Thanks for fighting the good fight.

Add a Comment

Your email address will not be published. Required fields are marked *