A Rule of Thumb for WordPress Partials

For anyone who has worked with WordPress on some level, you’re likely familiar with the concept of templates.

In the context of WordPress, templates are the files in which information retrieved from the database is rendered. In other frameworks or platforms, they may also be called templates, but are also often referred to as views.

But for anyone who has done enough work with building web applications, you know that as much as we like to build reusable components on the server-side – be it functions, classes, or whatever else – that we also like to do so with client-side related code, too.

WordPress Partials

When it comes to creating reusable components for WordPress templates, one of the most useful functions and features that we have at our disposable is the get_template_part function.

The thing is, after seeing enough code, I’m not sold on the idea that we’re taking advantage of it as much as we should in order to create more reusable code on the front end of WordPress themes (or views or WordPress plugins).

According to the Codex, the function should be used when we need to:

Load a template part into a template (other than header, sidebar, footer).

But there are additional ways to use the function to help create more modularized templates. Here’ my rule of thumb as it relates to WordPress partials:

If a piece of code is going to be reused across multiple templates, then abstract it into a partial.

Essentially, if I’m going to be using a set of code more than once throughout my theme or application, then I move it to a partial.

Sometimes, though, we don’t know if we’re going to need to do that until we’re further along in development, but that’s okay.

That’s why we have refactoring.

A Practical Example

Anyway, I also take this one step further such that I organize my project directory to include a partials directory:

Partials in Mayer

Partials in Mayer

From there, I can then easily include any of these partials in any of my primary templates used throughout my profile.

Then, say, I wanted to use pagination.php in a number of different templates, I simply call:

get_template_part( ‘partials/pagination’ );

And we’re good to go.

But That’s Easy

I know – and it makes front end development cleaner, and it makes our code more reusable, but this is something that I still don’t see being used as much as it should be.

So if you’re in the process of working on something in WordPress, and it affords the opportunity to create more reusable components, take advantage of this.

18 Comments

I like the thought, but I find that function to be lacking a bit. I usually just write functions to call multiple times, since I often have to pass variables into them.

I’m with Norcross. Would love to see parameterised partials!

How does using partials compare with a) using functions or b) using actions – both of which you can control with parameters?

And what about the overhead of loading yet another template file…?

    Partials, functions, and actions (which are just functions executed at a certain point) all serve different purposes.

    Partials are just reusable components of markup (and perhaps a bit of PHP) that can be used across a variety of templates. Think post meta – it’s visible in the `single`, `index`, `archive`, etc. templates.

    They don’t necessarily have to do any work; whereas, by definition, functions do exactly that so when it comes to firing a function, it depends if you’re requesting it to execute (manual invocation), or having WordPress do it (though hooks).

    Finally, the overheard really just depends on how much work the partial requires. Personally, I think they should be lightweight, but it would really depend on what all the partials are doing (such as how much data they are retrieving and so on).

Talking about front end coding and making it cleaner I know it’s common to mix HTML in with your PHP functions in the PHP world. I always find this strange when I find this in a plugin because other parts of the same plugin are usually nicely separated. In fact I wrote a blog post about it here.

However the above post has given me an idea for another little experiment I am working on The Pico Plugin Framework, and using get_template_part to add functionality to provide customised elements.

    I’m with you (regarding separating concerns) so much so that a follow up post to this post just went live this morning.

    Absolutely a fan of keeping our code as clean as possible depending on the nature of the language that’s being used to achieve work.

Several times I’ve planned on using get_template_part(), but invariably I abandon it and either use an include() or functions for the same reasons mentioned above. The inability to pass anything into a template part makes them not terribly useful.

    The inability to pass anything into a template part makes them not terribly useful.

    Yes, for sure – under the case that you actually need to pass information to it.

    If, on the other hand, you’re creating partials that will use functions that a part of, say, The Loop, I think it helps save a lot of redundant code.

Have you seen this? https://core.trac.wordpress.org/ticket/15086

I’ve been itching to use template parts in a directory but the only thing that has been keeping me back is that get_template_part() wasn’t designed for it, even though it works, and that (hopefully) some kind of intentional support for directories will be added.

    I had forgotten about that ticket.

    I’m skeptical that intentional support will be added, but who knows – I think that some of the things that end up getting added are based on demand and how WordPress is being used.

    If people are beginning to build more things such as applications on WordPress, then I can see a greater need for it.

      Yeah, it’s been almost two years so I wonder too. This “hack” way of using subdirectories will always work so I may end up doing it too. I don’t like having the root directory cluttered with different types of files.

Leave a Reply

Name and email address are required. Your email address will not be published.

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>