38 Responses

  1. Nathan Rice
    Nathan Rice Published |

    Problem with template parts (or, I should say, one of the problems) is that they seem inefficient. I’ve not benchmarked it, so I could be wrong, but it certainly seems that way.

    For every hook that is replaced by a template part call, there are as many as two file existence checks, plus the include. If the file doesn’t exist, those file checks are pointless overhead.

    I suppose you could argue that the benefits outweigh this inefficiency, but I’m not sure a theme with 20+ template files is really doing users any favors.

    To me, it seems like whatever method you choose, educating users is going to be a necessary ingredient to successful theme customization. And if I’m going to spend the time to educate a user about something, I’d almost rather them learn about hooks, which have much broader practical applications, than template files, which are only useful in themes.

    Reply
    1. Andreas Nurbo
      Andreas Nurbo Published |

      Hooks are really wasteful really. Hooks calling hooks calling hooks ends up being a lot of well hooks. Having simple conventions I think is a better way going forward. Not sure template parts as is is the best but think in general its a better way than lots of hooks. If user could just drop a post-content.part in a folder to change how post content by default is displayed would be preferably.

      Reply
  2. Andreas Nurbo
    Andreas Nurbo Published |

    I’d like an easier way for plugins to add template, templates parts etc as well. Having a way to replace template parts would be a great thing. All current methods are a little convoluted.

    Another thing that would improve things would be an addition of layouts. Currently each template is its own layout with the inclusion of template parts but one cant easily extend them dynamically or replace the template parts.

    Convention over configuration is the way forward in general I think.

    Reply
  3. Chip Bennett
    Chip Bennett Published |

    I would agree with the statement that template-part files are easier to understand for someone who already understands HTML; but I don’t think I agree with the statement that template hooks are outdated, and nothing in the post really supports that claim.

    One of the biggest shortcomings of template-part files in place of template hooks is Plugin injection of code/content. With standardized template hooks, Plugins would have a consistent means of injection. I don’t think that’s feasible with template-part files. Even if you use the core auto-generated template-part hooks, we would then have to require that Theme developers implement standard get_template_part( ‘foo’ ) calls. I think that’s far more restrictive, and far less likely to be adopted by Theme developers, than a standard set of template hooks.

    I think template-part files and template hooks can co-exist (they do, nicely, in my own Theme); but I also think that they tend to solve different problems – or meet the needs of different users.

    Reply
  4. SMNadim
    SMNadim Published |

    The configurations should be common to all themes.

    Reply
  5. Mike Schinkel
    Mike Schinkel Published |

    Hi Justin,

    In general I strongly agree with your post. I would summarize (what I think) you said with:

    “Hooks for theme developers is the wrong approach but standard theme hooks for plugin developers is the right approach, and needed. “

    I also like your proposed “*_after” hooks from the Trac ticket although I’ll have to warm up to the naming convention.

    That said I’d like to point out that, unrelated to the wisdom of your post, the current state of WordPress’ get_template_part() neuters the applicability of your proposal because of get_template_part()‘s lack of flexibility. And it’s not that people haven’t requested more flexibility on Trac, it’s that most of the tickets have been closed with “wontfix” and the rest have been left to languish:

    http://core.trac.wordpress.org/ticket/21676
    http://core.trac.wordpress.org/ticket/13239
    http://core.trac.wordpress.org/ticket/19063
    http://core.trac.wordpress.org/ticket/24814
    http://core.trac.wordpress.org/ticket/21062
    http://core.trac.wordpress.org/ticket/14310
    http://core.trac.wordpress.org/ticket/12877

    Not saying that all those tickets have 100% merit, but pointing out there is a lot of demand for a significantly improved get_template_part() but it hasn’t been improved in years.

    What we are doing on our projects is to create our own more flexible alternative to get_template_part() which works for highly custom themes designed for use on specific corporate sites but doesn’t really work well for widely distributed open source or commercially distributed themes where having a standard extension method is required to allow plugins to add features without requiring users to modify their themes.

    So again, I agree with you on this post in concept; tis a shame that there’s so much push back on improving get_template_part() because the reality is they make your recommendations somewhat moot.

    Reply
  6. Donna
    Donna Published |

    Gotta say…template parts drive me crazy. It takes way more time for me to track something down when I have to figure out where the problem is. Maybe it’s just me, but it takes me far longer than when everything is in one place.

    Reply
    1. Mike Schinkel
      Mike Schinkel Published |

      Hi @Donna,

      You know if WordPress core were to finally add some of the hooks that have been requested for so long then you could emit a comments like this and it would be easy to track down template use.

      But I digress.

      -Mike

      Reply
    2. Andreas Nurbo
      Andreas Nurbo Published |

      I think hooks are the devils plaything. Hooks are annoying and shouldnt be used as a design tool for most part in themes. They can be required for plugins too display data but themes should not use them as part of their design structure, that is layout etc should not be controlled by hooks.

      Hooks as design tools breaks the whole idea of a theme and good separation in my opinion. The structure of files should decide what is loaded. Hooks encourages user to manipulate the main theme in the functions.php file instead of making a child theme. When interacting with themes/plugins etc that use hooks one often encounters a mixture of presentation logic and business logic.

      Reply
  7. Ben B
    Ben B Published |

    Out of interest, Justin, does most of your business come from folks that have a deep understanding of WordPress (including hooks); or the WordPress-savvy geek who dabbles in a little HTML and gets includes/template parts?

    I love WordPress, and it allows me to help others in my passion of letterpress printing. Of late I’ve found that customisations would take too much of my limited time, and the hurdle to understanding hooks to do what I want was too much. That said, I’m happy with template parts.

    Just curious to know where your business comes from vs. the depth of understanding needed to get going.

    Reply
  8. Han
    Han Published |

    Thanks for sharing this invaluable insight.

    I guess one of the reason why hook is still preferable (at least by me) is that I can move a part of page element (like site navigation) with only 2 lines of code, remove_action and add_action.

    However we can make it easier for html user by combining both hook and get_template_part where appropriate.

    Reply
  9. Frank
    Frank Published |

    Thanks for the post, update the topic.

    I see the chance for hooks and templates, 2 great ideas and the mix of this solutions is the right part for my, but a decision of the developer side. For small changes, like content in footer or add to small markup with content in a template, is the hook solution a great tool. But for custom creations is a child the right way, important for the maintenance. But also it is not seldom, that the template have a lot of source and a small change is not easy for all users and also not maintainable. But this also the job of the developers to work with much templates, to separate in usable files.

    I see it also, that we close the ticket for standard-hooks, but I would wish to see a codex for default names convention to add hooks in the theme.

    We get more and more possibilities in themes, like the sub-folder for templates. But this is not easy to understand for end-customer. Often is a change via hook a fast and maintainable way. Also I like it to easy use a hook to deactivate a function in the parent theme.

    Reply
  10. Eric L.
    Eric L. Published |

    At first read, the idea of replacing hooks with template files went against all that I has assumed about WordPress dev. For the record, I too started out with HTML/CSS knowledge, no PHP, but eventually did get a fairly good understanding of PHP (learning Java didn’t hurt! :) ). So I came to really respect the hook method, especially with the idea of having a minimalist approach where the underlying basis (the parent theme) could be updated with minimal modifications necessary to the child theme. Using template parts flies in the face of that view because it means you’ll have to update those template parts whenever the parent theme is updated. That said, your hooked functions may need to be similarly updated.

    Reply
  11. Getting started with Hybrid Base and Hybrid Core (Wordpress Framework)
  12. Edward Beckett
    Edward Beckett Published |

    Great discussion… not necessarily just for WP either… I don’t know how many times I’ve cringed when I start working on a new technology stack only to find I’m required to learn a few templating engines as well…

    IMHO… templating engines are okay but they’re ‘messy’… I personally abhor the idea of having a hundred includes scattered throughout the site… moreover, what happens when theres a bug in include number 47 required six B-Tree levels deep? Hmm? Good luck debugging that one…

    In short, I believe the general consensus is…

    One :: Designers Use Templates

    Two :: Developers Use Classes, Functions

    I’m a developer… and a control freak… I use classes and functions…

    ;-)

    Reply
  13. Pete
    Pete Published |

    For the past few years i’ve seen the rise/domination of child themes and I’ve hated it for one big reason… php.

    I know html/css reasonably well and the introduction of ‘hooks’ and functions and pfsst! whatevaaa has confused the bejesus out of me. I really think (without any offense) that php gurus/developers have taken control of modern day themes and taken them out of the hands or reverse engineering html/css hacks like me without realising you’re creating a rod for your own back by making a dramatic rise in the need for support forums.

    Gone are the days of finding a theme with only the WordPress template tags in a theme, these days they are full of more php code than I care for.

    My favourite theme is the old original “News” theme from Studiopress. A great simple framework with really easy WP template tags etc. I can hack that to bits and go on the WP forums for any help.

    For the love of god please bring back a simple alternative for us hacks :)

    Reply
  14. Ian Stewart
    Ian Stewart Published |

    the days when the only way to achieve this feat was with a plugin coded by Kristin Wangen

    I felt like I’d found the holy grail when I stumbled upon this plugin. Kristin was really encouraging about this whole child themes thing.

    I feel nostalgic now. I should activate the Options Theme, kick back, and reminisce.

    Reply
  15. Theme template hooks are outdated | WordPress 2.0 Site
  16. amdha
    amdha Published |

    Nice post. Justin, you can check this theme.

    http://wordpress.org/themes/pahlawanweb

    Reply
  17. Brad Dalton
    Brad Dalton Published |

    I think you’ve got to look at how many files the user has to become comfortable with when they open the folder.

    Then they have to find the code and also find the file to paste the code into. Finding the correct files and then pasting the code in the right place is half the battle for non coders.

    Child themes which only contain a handful of files like functions, style and a couple of template files make it easier for users to find where to paste the code.

    Most users simply want a copy and paste job. Give me the code and tell me where exactly to paste it. They don’t want to modify it.

    If you don’t include hooks, its going to make the whole experience even more frustrating than it already is for new and technically challenged users.

    I’ve found people love using hooks as they are so simple to understand once you take a look at a visual reference but they don’t know how to use them in custom functions so they need to learn that unless you provide a library of snippets.

    If you took them all out and said copy and paste code from the parent theme, they’d still need to understand where exactly to paste it and how to modify it.

    What needs to happen based on my experience helping on various forums is MORE code snippets which are easier to find.

    Reply
  18. El arte de rastrear, contextualizar (e incluso generar) debates - CoLabores
  19. Reinhard
    Reinhard Published |

    Justin, so you are saying that themes like Genesis are outdated?

    Reply
  20. Standard WordPress Theme Hooks - leaves-and-love.net

Leave a Reply

By submitting a comment here you grant this site a perpetual license to reproduce your words and name/Web site in attribution.

Please use your real name or a pseudonym (i.e., pen name, alias, nom de plume) when commenting. If you add your site name, company name, or something completely random, I'll likely change it to whatever I want.

css.php