17 Responses

  1. Ryan Imel

    Still reading through this, but I noticed the link to my post under “further reading” seems to link to Nathan’s post :)

  2. Joan

    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.

  3. Greg Fuller

    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.

    1. Greg Fuller

      There are…

  4. Chip Bennett

    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.

    1. Tomas M.

      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.

    2. Tomas M.

      Actually this functionality that I just thought of, most likely could be made as a plugin.

  5. Sami Keijonen

    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.

  6. David Decker

    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.

  7. David Decker

    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!

  8. David Abramson

    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.

  9. Matt Kaludi

    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.

Leave a Reply