17

It seems to me both of these afford the opportunity for the end user to modify a theme without actually editing the themes files (via child themes).

My question is, is one method preferred over the other.

For example take a theme I am workig on now. I am trying to decide whether to go with template parts of hooks.

<?php get_template_part('before_sitecontainer' ); ?>
<div id="sitecontainer" class="sitecontainer" <?php //closed in footer ?>>

<?php get_template_part( 'before_topcontainer' ); ?>
<div id="topcontainer ">

    <?php get_template_part( 'before_topedge_navigation' ); ?>
    <?php get_template_part( 'topedge_navigation' ); ?>

    <?php get_template_part( 'before_site_header' ); ?>
    <?php get_template_part( 'site_header' ); ?>

    <?php get_template_part( 'before_second_navigation' ); ?>
    <?php get_template_part( 'second_navigation' ); ?>

    <?php get_template_part( 'after_second_navigation' ); ?>

</div><!-- end topcontainer div -->
<?php get_template_part( 'after_topcontainer' ); ?>

The above allows the user of the theme to replace any section of existing code by simply creating an appropiately named file in their child theme folder as well as adding new code before/after each pre existing section by the same method - the before/after template part files don't exist in the parent theme at all and are there simply to allow them to insert code - and this method does not require they understand hooks/filters to accomplish this.

I could of course achieve the same using hooks and filters.

Is there an advantage to using hooks/filters instead? Bearing in mind the target audience that will be using this is decidely not code savvy. I can give them relatively basic instruction they can follow to use the template method but will almost surely confuse the devil out of them with hooks.

Or are there situations where one would be better than the other within the same theme?

3 Answers 3

10

I prefer hooks, since they are more flexible: you can hook into them from your theme's functions.php file, but also from plugins. I try to put as much logic in plugins, so that the themes contain mostly layout stuff.

If you use an action hook, it is still possible to use get_template_part() in that hook handler. This gives you the best of both worlds. You could probably even create a default hook that calls get_template_part(), so that people who don't have much experience with coding can add extra files, and others can remove this hook if they don't want to.

Regarding performance: get_template_part() uses (in locate_template()) file_exists() one, two or four times (depending on how you call it). It appears file_exists() is very fast, and uses caching in PHP and maybe even in the OS. So that is probably not an issue.

1
  • That makes sense. Part of my design thrust has been to eliminate the need for plugins in most common use situations whilst still preserving the ability to use them with for those that want to. My target client knows very little about WordPress or plugins, is not qualified to tell good plugins from bad (the major weakness of plugins IMO) and doesn't want to have to deal with updating and managing multiple pieces of software. So I do have to build a lot of functionality right into the themes in order to deliver what they want: a simple to use, simple to maintain, one stop solution. Oct 19, 2010 at 7:44
6

I would say that the main difference is readability. If you see several, well named, template parts, you can grasp what is happening easily. If you just see a hook, you will need to search through the rest of the theme to establish what is attached to the hook.

1
  • 1
    Yeah, that makes sense, and is part of what I was trying to achieve with the example code. Oct 18, 2010 at 9:39
5

It is (relatively) easy to remove function from hook in child theme, but much harder to make it ignore unwanted parent template.

Essentially working with hooks is closer to PHP side and working with templates is closer to HTML side. I use Hybrid parent theme, which is very hook-oriented. It is a bliss right until you need to get rid of some parent's template.

For users that aren't tech savvy neither is very nice option. Why would they need to mess with such theme internals anyway?

PS also note performance issues. Stuff with hooks happens in memory, stuff with templates takes plenty of disk lookups. Especially if you are writing something like in your example.

PPS not everyone's preference... but instead of writing parent theme from scratch why not take existing parent theme and provide simple child theme to user?

5
  • Ignoring a parent template would be as easy as creating a blank template file to replace it I would have thought. Much easier than messing with hooks (and therefor PHP) for the non tech savvy user. Although for someone with experience hooks would be much easier. As to why, there are always those who want to customize, you even admitted you do. As to why I am creating a theme, that's the direction I want to take my business in. Building around someone else business doesn't seem very future proof to me, also because IMO most existing themes leave much to be desired. I think I can do better. Oct 18, 2010 at 10:25
  • 1
    Good points about the performance issues though. Although, as wordpress was designed to work with get_template_part I would have thought it wouldn't be that much a performance hit. Anyone have any benchmarks on this? Oct 18, 2010 at 10:27
  • I see what you mean about ignoring a template part. Not as easy as I thought Oct 18, 2010 at 10:36
  • Actually it is as easy as placing a blank template file in the child folder, provided its in the root of the folder. Where it becomes difficult is when the template files are in subfolders of the parent/child theme folder Oct 18, 2010 at 10:40
  • Actually, even subfolders are no problem. I just had the folder named wrong (a sure sign I am working too late LOL). To override a template part it only requires a file of the same name in the same path in the child as was in the parent Oct 18, 2010 at 11:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.