For anyone who has experience in building WordPress themes – or even just one theme – or anyone who has experience in working with child themes, or simply modifying a core theme, then you’re more than likely with <a title="wp_title" href="http://codex.wordpress.org/Function_Reference/wp_title" target="_blank">wp_title</a>.

It’s one of the tags in WordPress that’s easy to usd and that’s easy to understand. Straight from the Codex:

Displays or returns the title of the page. A separator string can be defined, and …, that separator can be designated to print before or after the title of the page.

This tag can be used anywhere within a template as long as it’s outside The Loop on the main page, though is typically used in the <title> element for the head of a page.

Not much to it, right?

But it’s also one of the tags that can be abused which can cause problems especially as it relates to plugins.

Filtering wp_title Matters

First, the default use case for wp_title is quite simple. It’s easy enough to add that tag, declare the separate, and how you want the title and the separator to be displayed.

For example: &lt;title&gt;&lt;?php wp_title( '|', true, 'right' ); ?&gt;&lt;/title&gt;

Easy enough – but it can always get worse (and I know this from personal experience).

Don’t Do It This Way

For example, let’s say that you want to create a more elaborate format that displays titles across your blog.

You could do something like this:

Which is really ugly, and really wrong. And I’ll be the first to admit that this is code that I pulled from something I’ve written before (just goes to show that you do learn with time :)

The problem with this is that you’re not able to filter wp_title. More specifically, this means that plugin developers who offer to customize your theme’s title structure can’t do it because you’re not properly using wp_title.

Instead, there’s a mishmash of wp_title, get_bloginfo, and string concatenation in order to get the scheme you’re going for, and a good rule of thumb in programming – at least in the context of some frameworks and applications – is that if it feels weird to write it in a certain way, then there’s likely a better way to do so.

Do It This Way

Since wp_title is a filtered function, this means that we’re able to provide a custom hook that allows us to define the schema for displaying our titles not only more precisely, but also correctly.

And by that, I mean that we’re not using a combination of “blog info” functions and the like – we’re taking advantage of how WordPress is built: through the event-driven paradigm.

On top of that, this will allow plugin developers to remove our custom code and insert theirs. Everyone wins, right?

To do this, you first need to define exactly how you want the title to appear using the basic wp_title function:

Next, you define a custom function, hook it to wp_title, and provide the code necessary for filtering the information:

Not only do you gain all of the advantages that are mentioned above, but you’re also doing this in a more correct way.

And, like the first bit of code, this is code straight from a project I’m working on right now.

I mention this not to showcase what I’m doing (after all, the code’s gonna be open sourced anyway), but to showcase that there are going to be times where you write bad code, times where you write good code, and times where you’re going to have something that works but could probably be improved.

So with that said, there’s likely something that can even be critiqued in the code above. But the point is that what I’m showing is what I’ve once done, where I am now, and the advantages of using available hooks.

Critique away :).

Category:
Notes
Tags:

Join the conversation! 23 Comments

  1. Does this filter play well with SEO plugins like SEO by Yoast? The plugin lets you define an explicit title for each post type item (pages, posts, CPTs) in the edit interface, which is integrated with page analysis tools.

    I guess the issue is whether you’re hooking earlier or later than the plugin into wp_title(). Would it be safer to pass a lower priority than 10 to the filter? What are the possible downsides to passing the filter earlier?

    • This is a good question, and the short answer is that yes it does.

      Joost has shared both himself (and in an SEO audit that I’ve undertaken in a previous theme) that filtering `wp_title` is the way to do it because it allow functions to remove previous hooks (like the one’s I’ve defined) so that plugins can offer enhancements.

      Would it be safer to pass a lower priority than 10 to the filter? What are the possible downsides to passing the filter earlier?

      You may get mixed answers to this, I dunno, but I always leave it at 10 and if I’m writing a plugin that provides a hook, I `remove_action( ‘wp_title’ );` before doing my own filtering.

  2. Nice. This is what was so good about in the Standard theme. Is your Quote for Beta testers full Tom?

    • Yes – it is. Right now, the plan to have this available for WordPress.com users first, then WordPress.org users second.

      The theme that’s released for WordPress.org will likely include a little bit of extras, a slightly different name, and a specific set of plugins only for this particular theme.

  3. Sorry I meant Quota not Quote.

  4. Oh how I hate the wp_title filter. It’s the only filter it’s virtually impossible to use safely unless you remove all other filters first.

    To me it’s telling that all of the default themes filter the output pretty extensively. Seems like the implementation could be improved.

    I can only imagine that the AIOSEO and Yoast guys have more than a few grey hairs caused by it :)

    • I can only imagine that the AIOSEO and Yoast guys have more than a few grey hairs caused by it

      Exactly – and for those of us who have built themes know that people are likely going to use those (or similar) plugins end up needing to filter it ourselves in the core them so that it can be removed by said plugins later :).

  5. You might want to fix quotes in code blocks turning curly. It appears to be happening with this new theme.

  6. Trying to fix the way my pages are being indexed in Google. Instead of indexing the title tag Google is displaying the page name and site tag line. Here’s a few examples.

    Contact Us – New Jersey Attorneys

    http://www.njlawconnect.com/contact_us/

    Newsletter – New Jersey Attorneys

    http://www.njlawconnect.com/newsletter/

    Sitemap – New Jersey Lawyers

    http://www.njlawconnect.com/njlawyersitemap/

    I’m desperate for any advice you can offer. I’m using All in One SEO. The title overwrite is “enabled” and my header .php file includes:

    Thanks.

  7. Saying that 25 lines of code are better than one line of code when both result in the same title is something only hard core WP could dare. For the rest of us, less code is better code.

    • …when both result in the same title

      This is true in some cases, but as soon as you start using plugins that modify the title and you don’t have the proper filter defined in your theme, then it’s not going to work correctly.

      You see this most often with SEO-focused plugins.

      For the rest of us, less code is better code.

      I completely understand what you’re saying, I really do – but the point isn’t using more code for the sake of using more code. It’s for making sure that the theme is as compatible with as many plugins and external work as possible.

      • Thanks for your kind reply.

        The truth is that I’m really frustrated by the recent tendency of WP of doing things more and more complicated. Be it the title, the internationalization, the escaping, the customizer support and the list goes on. And the main explanation for all this code mess is, like you point out, the “standardization”.

        In my opinion all this extremely long, complex and unreadable code distributed along many php files is the wrong direction for WP. It is really forcing you to either become a hard core pro WP dev or just get a theme and change the background in the customizer. There is no longer room for amateur coders (most bloggers and small/medium site owners) – it has become too complex.

        I’m sorry to express my general frustration with WP in your site, but wp title is a great example of what I mean. Btw, could you point me where I could share my feelings with the WP dev team? I hear there is a strong WP dev community, I wonder if anyone ever said “hey gus! let’s try to keep things simple”

        • The truth is that I’m really frustrated by the recent tendency of WP of doing things more and more complicated.

          I understand – from a non-developer perspective, I understand this type of stuff can be frustrating.

          The thing is that you can still use the “less code” case, this post is offering a more resilient solution to building themes. If you’re just working to customize your own theme, you don’t have to worry much about it (unless there’s a problem with it working with another plugin).

          The thing is, a lot of the examples on the web for how to do things with WordPress in very little code aren’t good examples. It’s permeated this idea that things, with WordPress, should be able to be easy, etc.

          It’s not that WordPress shouldn’t be easy – it should – but it’s that other people are writing code that’s not the proper way (or the way of “best practices”) to achieve the end result.

          That’s what these types of post (and this blog, really) are all about – providing the right way to do something so that themes and plugins are built in a way that won’t break with upgrades or that don’t use “hacks” to get something working.

          In my opinion all this extremely long, complex and unreadable code distributed along many php files is the wrong direction for WP. It is really forcing you to either become a hard core pro WP dev or just get a theme and change the background in the customizer.

          The long, complex unreadable code is something that shouldn’t be happening. Distributing code across multiple files is something that, if done right, should be done in order to help separate the logic and work of what each file is doing. That is, each file (or set of files) should contribute to a certain feature.

          Depending on what you consider long and complex may be different than what others consider to be long and complex. If the code in the post above is long and complex, then that’s not entirely accurate – it’s a short function that’s heavily commented that uses practices that have been in place in WordPress for quite a long time.

          If, on the other hand, you’re referring to other functions that are on the order of 50 lines long without good documentation, I know exactly what you’re talking about. That’s one of those things that has to get better over time and it, unfortunately, comes with the nature of software.

          As far as The Customizer is concerned, this is a new-ish feature of WordPress in which more and more things are being added in order to make it easier for people to setup, customize, and change their blog without having to write code and they can see their changes on the fly without having to toggle back and forth between two views.

          There is no longer room for amateur coders (most bloggers and small/medium site owners) – it has become too complex.

          Unfortunately, I don’t have a response to this. I hate to hear it because, obviously, I’m a big fan of WordPress and believe in its place in the future of powering much of the web, but the complexity is going to be a factor that varies from agency to agency or person to person.

          I’m sorry to express my general frustration with WP in your site, but wp title is a great example of what I mean.

          I don’t mind you venting your frustration, but there’s not much I can personally do about it other than try to explain why things are how they are :).

          I will say that if wp_title is becoming more complex than you feel it should be, then – at some point – there’s probably been a breakdown between how tweaks should be made in themes and how they have been made in themes (or plugins).

          There is a proper way to introduce changes and a way that works, but is likely improper. Just getting something working within the context of WordPress is usually not enough — it feels good, sure — but it’s not the right way to go about building a solution that will work with WordPress as it continues to evolve over time (and not just WordPress, but themes built on top of it and plugins built on top of it).

          I hear there is a strong WP dev community

          There is! And many of us are extremely welcoming and we’re opening to hearing suggestions. We do want things to be simple and we do what we can to make them simple (hence the code above being written with WordPress standards and comments).

          Then there are others who claim to be WordPress developers who aren’t really developers (I’ve talked about this particular issue in-depth in this post).

          could you point me where I could share my feelings with the WP dev team?

          Since it’s open source software, there’s not an official development team as anyone can try to offer contributions, but if you’re looking to try to get in touch with those who are the core contributors, then you can find all of that information on the Core Contributor page in the WordPress Codex.

          Hopefully this clears things up a bit!

  8. Yeah this is what am I looking for.

    Submit a theme to WordPress.org with hard code in header.php and BLAAAAMMM…

    GOT REJECTED.

    Thank Tom for the explanations.

  9. Very nice post.

    But i didn’t get the site description by using the get_bloginfo(‘description’, ‘display’) function ;

    Only showing the site name and page name

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.