On WordPress themes and frameworks

Categorized under:

Photo of author
Written By Brian Krogsgard

17 thoughts on “On WordPress themes and frameworks”

  1. Great article.

    I think it depends on the project you are working (small/large), your client (techy/non-techy), and on your needs. I use Genesis, Canvas, Builder, _s or just a parent theme depending on the project and the customer.

    Anyway, I agree 100% users should not be able to activate parent themes. And love the idea of core plugin dependency.

  2. There’s lots of good thoughts here. If I’m going to use a framework at all, I favor the approach of drop-in frameworks. I’ve used the dependable Hybrid Core in one project. I would like to take advantage of the extra features of Genesis, but I’m hesitant because of the problem of updating commercial child themes that have been modified.

  3. Two thoughts:

    1) #4 is the only actual “framework”. The first three mis-use the term.

    Clarity on this issue is important to me, because I would eventually like to be able to vet *actual* frameworks (i.e. drop-in code libraries) in the official Theme directory, to facilitate their use and update in directory-hosted Themes. I don’t know if that’s a pipe dream or not, but it would seem that consistent nomenclature would, at the very least, be a prerequisite.

    2) Requiring only the activation of Child Themes would be insurmountably difficult for end users, even if the monumental infrastructural requirements (Theme directory integration in the WordPress admin) could be overcome. It’s a nice thought, but I don’t see it being feasible any time soon.

    Right now, users can go into their admin, peruse available Themes, and install, customize, and activate in one fairly easy process. To make that process work consistently in a Child-Theme-Required scenario, the Theme SVN would then have to host not only every stand-alone Theme, but also a generic Child Theme for each stand-alone Theme. Do we have that child Theme generated on-the-fly? Do we require Theme developers to bundle it with their Theme ZIP file on upload?

    And even then, requiring Child Themes still wouldn’t fix any but the most basic of issues (i.e. style-only changes). Users who need/want to modify template or functional files will still need to get their hands dirty with the parent Theme.

    And also: *requiring* the use of Child Themes would not be consistent with the spirit of free software philosophy that WordPress espouses. End users should be able to do whatever they want with the Themes they install, and WordPress should not actively interfere.

    • What if WP would check if some theme X is using theme Y as parent and then the activation link in admin panel would be removed just for the theme Y?

      In this case problem would be solved locally and no need to make child theme for every parent theme.

    • Chip,

      I totally agree that only #4 is a “framework” in the truest sense. I was talking in terms of how they are viewed. That was much of the point of this article 🙂

      Requiring only the activation of Child Themes would be insurmountably difficult for end users

      As to this point, I don’t really understand or agree. I think packaging a default child theme with the parent, or generating one on the fly would be fine.

      Basically, my goal would be that when a user clicks “Install theme” WordPress determines if it’s a parent or child theme, and installs both but activates the child. I’m sure it has its challenges, but it seems possible to me, without burdening users. Consider the current burden for users of creating their own folder structure, stylesheet comment blogs, zipping folders, and uploading or FTPing. My alternative seems much simpler.

      And even then, requiring Child Themes still wouldn’t fix any but the most basic of issues (i.e. style-only changes).

      I think there is much more about child themes than styles. You can of course override any template of a parent theme in your child theme, not just CSS. It’s a key part of child theming workflow. I’d assume you’re very familiar w/ this workflow, so maybe I misunderstand your statement.

      • I don’t think the infrastructural challenge would be as simple to resolve as you imply. Post Formats UI was child’s play compared to what would be required to make Child-Theme enforcement a seamless part of core.

        (Side issue: the Theme directory hosts Child Themes. What happens if a user installs a hosted Child Theme?)

        You’re absolutely correct that there’s much more to Child Themes than style changes. My point is that it has been a tough row to hoe just getting mainstream usage of Child Themes for *any* change to an installed Theme.

        But if you force users to use Child Themes, that forced Child Theme will consist of one file: a style.css. (You could include an empty functions.php, but an empty functions.php can potentially cause problems, and should probably be added by the end user only if needed.)

        So, two things:

        1) If the user wants to make changes *other* than mere CSS, the user is still going to have to use FTP to get into the installed Theme, copy files to be modified, etc. And any users capable/comfortable doing that will be capable/comfortable with creating the initial Child Theme themselves.

        2) If the user wants to make *only* CSS-related changes, I would recommend *not* using a Child Theme, and using a Custom CSS Plugin instead.

        Maybe, instead of trying to force users to use a Child Theme, it would be more beneficial for core to provide a way – in core – for users to input custom CSS and custom functions – essentially core Plugins for Custom CSS and Site Functionality.

  4. Generating child theme on the fly could be difficult. Some themes needs to have @import rule in child theme style.css. Some themes load parent theme style.css automatically and there is no need for @import rule in child theme style.css.

    So packaging a default child theme with the parent theme could work better. At first it might be strange for the end user when they try to modify theme.

    “Wait, there is a parent theme, where? What, there is actually two themes installed?”

    At least all theme builders should provide base child theme in their theme page.

  5. I don’t have any problems with the term “framework” at all. It’s just a helper term – as well as “ecosystem” – to explain something somewhat more complex a bit better. Also, I don’t care if this term may come in four different “tastes” like you summarized above. I really don’t see the problem(s) some may have with (theme) frameworks. In my opinion, just like Nathan Rice pointed out in his great post, the benefits outweigh the flaws by far.

    A few more notes to your post here:
    I consider Genesis also a framework in the “truest sense” (stupid term, really), as it has one of the highest levels of abstraction, and has become a real “ecosystem”. Not to forget, they dropped quite some features in the last versions, to move them into plugins or whatever. One of the few themes/frameworks/whatever going in this direction, really interesting point! Also, they (StudioPress/Copyblogger) don’t seem to use the term “theme framework” often (if at all?), they use “design framework” for quite some time (I guess over a year or longer?).

    What is also really interesting, that only “Gantry” is a plugin of those listed above. All other you mentioned above have to be activated via /themes.php being it a parent or child theme. A really interesting point!
    This is a point that I see rarely these days: when a user wants to customize the theme, I would suggest via a plugin! REASON: A lot of these customizations aren’t theme-dependent so would have to be made with every future theme – so that is really plugin terrain! Sooner or later users have to be educated with the hooks/filter concept to make their custom stuff. Plugins are best for that, anyways!

    Regarding child themes, in my opinion there were made a lot mistakes when indrocing them some years ago. I mean not technically but in sense of “promoting”/ “marketing” them to the end user. They are quite “unvisible” in the backend, beside a few notes, often only in light gray font…
    This could be done much better beginning with the overall wording, in backend, on .org, Codex, wherever! I agree, that the default Twenty-something themes should come with a child theme by default and that should be the one that gets activated if I activate one of those default themes. Or, there should be an on-the-fly-generation of a child theme at least consisting of the style.css (and maybe a functions.php).
    This step makes only sense, of couse, if wordpress.org/Automattic/etc./etc. would start really promoting this and educating users.

    I have seen too many users tweaking their (default Twenty…) theme and lost all on updates. A child theme would have been a life saver to them.

    • Hey David,

      Thanks for your reply.

      I really don’t see the problem(s) some may have with (theme) frameworks.

      I actually like the concept of abstracted code. Who wouldn’t? As you bring up, it’s some of the parts of how it’s done in the parent/child setup WordPress utilizes that worries me a bit more.

      I think products like Genesis are great. I think it really enables quality developers to develop faster and more reliably. And I think some end users will find the methods for customizing a theme that way easier than alternative routes.

      However, that doesn’t make it for anyone. I think each style of framework listed above, and each has their flaws. For instance, indeed updating a drop-in framework can be challenging. But I like that I have control over all markup for drop-ins, and can simply manage the includes folder for updates. However, it would make more sense as a plugin to me, just the way I feel for Genesis’ and other parent theme frameworks’ functionality.

      Regarding child themes, I think we are on the same page!

  6. Chip Bennett
    […] it would be more beneficial for core to provide a way – in core – for users to input custom CSS and custom functions – essentially core Plugins for Custom CSS and Site Functionality.

    That is, what I highly suggest to do! And I note, you said “Plugins” which is what’s the best solution for this!

  7. Using theme frameworks have opened up a whole new possible world to me in building websites. I’ve been building most of my websites on the Genesis framework lately and I love how easy it is not only to build it, but to pass it off to my clients and allow them to update their homepage areas and feature different content.

  8. I have always asked this question for the longest time! I still don’t understand why authors refer to them as frameworks and funny enough people believe them and pass the terms to their peers.

Comments are closed.

A2 Hosting