Custom Post Type Search Results Templates in WordPress

As I was building out the the knowledge base section of the marketing site for my new WordPress church themes project, I came across the need to have a custom search results template for my knowledge base articles (custom post types called kb_article).

I figured that WordPress would have something build-in by default for this like they do with archive-{post_type}.php or single-{post_type}.php, but it turns out that’s not the case. The search results template WordPress looks for is search.php. If that’s not there they revert to archive.php and if that’s absent, index.php.

Limiting Search to a Particular Post Type

Before I go on, I want to quickly cover how to limit your search results to a particular custom post type. Add a hidden input to your search form with a name of post_type and the value attribute set to the name of whatever post type you want to search. In my case, my post type was called kb_article, so my form code looked like this:

Display Custom Results

We’ll name our custom search results templates using the WordPress filename conventions of {template}-{post_type}.php. In our case, that would result in search-kb_article.php. We could just check to see if that post_type=kb_article is set in the URL string and use get_template_part to load it if it is, but let’s go a step further. We’ll check to see if post_type is set in the URL string, and if it is, also check to see if custom search template exists for that post type using the {template}-{post_type}.php naming pattern. If it does, we’ll load it. If not, we’ll continue with the default search template.

So far this has worked well for me. If you have any ideas on how it could be improved, let me know in the comments.

Custom WooCommerce Cart Links

Sometimes if you’re working on a WooCommerce site, you’ll find yourself needing to create custom links to the WooCommerce cart. I covered pieces of this in passing in my post about adding static menu items to wp_nav_menu(), but I wanted to go ahead and cover it more in-depth as well. Here are a few mini-tutorials and things to keep in mind as you’re building your custom WooCommerce cart link.

A Simple Link to the WooCommerce Cart

This is probably the most basic form of linking to the cart. Here, we’re just calling get_cart_url() from WooCommerce’s WC_Cart class.

Adding the Cart Total to the Link

In this example we’re getting the cart total with the aptly-named get_cart_total() function and using that as the link text.

Updating the Cart Link Live

WooCommerce has a setting that allows products on archive pages (the main Shop page, product category/tag pages, etc.) to be added to the cart via Ajax. By wrapping our cart total with span that has a class of .cart_totals we ensure that the cart total is updated when products are added to the cart via Ajax.

Only Display Link if the Cart Contains Products

Here we’re checking to ensure that the cart actually has had products added to it. If so, we’ll display a link.

Further Reading

This really only scratches the surface of what you can do with the WC_Cart class. I recommend checking out the WooCommerce API docs for more.

Adding Static Menu Items to wp_nav_menu()

This week I found myself needing to append a static menu item to the end of a wp_nav_menu()-powered navigation menu. After a bit of Googling, I discovered I could do this using wp_nav_menu()‘s items_wrap parameter.

It’s actually pretty simple. Create a function that picks apart the default value of items_wrap and rebuilds it with a static link. Then call that function in the items_wrap parameter of wp_nav_menu():

How would something like that be useful? In my case, I was adding a WooCommerce cart link to the navigation that dynamically pulled in the sub-total. My code looked something like this:

You can even check for certain conditions, and only return the static menu item along with the default items if the those conditions are true.

Here, I’m checking to see if there are items in the WooCommerce cart, and if there are, I’m adding a link to the cart to the nav menu.

Tools

This essay was written in early 2013 to be my contribution to Tim Smith’s Lustra Magazine. Unfortunately, circumstances dictated that the project never launched and this has been sitting in my Documents folder ever since. I ran across it today and wanted to share. Enjoy.


We’re lucky folks. By our industry’s very nature, the toolsets available to us are very good because we’re good at building them. That’s a luxury not afforded to carpenters or bakers. A carpenter can’t make a better table saw out of a 2Ɨ4 and a baker can’t make a better oven with flour and water. But we’re different. The things we build are made with other things we build.

It’s like a tweet I saw several days ago. Sadly, I can’t find it, but it went something like this.

Kid: “Was the thing you use to program made with programming?”
Dad: “Yes, it actually was.”
Kid: [mind = blown]

When you get down to it, this is huge. It’s no problem if you want a JavaScript component to work substantially different than it currently does ā€” fork that sucker on GitHub and get to it! Want to make significant tweaks to your text editor? TextMate, arguably the best text editor of all time, is just waiting for you. Notice a bug or inefficiency in Ruby on Rails? Fix it and you too could have code in the Rails source.

The sky is the limit it and it’s awesome.

So, a couple of things. First, if we want something, we’ll build it. Second, there are a lot of us and we build a lot of things.

Blessings tend to come hand-in-hand with curses in my experience. Buy a Corvette and you can expect a substantial increase in your car insurance bill. Buy a new MacBook and you’ll be constantly worried it’ll get dented.

Have an endless supply of tools and you’ll never make anything.

I’ve just finished Execute by Josh Long and Drew Wilson. All in all a fantastic book. I wouldn’t say I agree with every single thing in it, but that’s for another time.

What it did best was explaining inspiration ā€” how it works and how to manage it to your advantage. Inspiration is our most valuable asset when building things. With it at our backs, we can do a task twice as fast as it would take an uninspired us to do half as well.

Different people draw inspiration differently. Managing it is the trick. As Drew says in the book, whenever he gets a little tired of building out the backend of an app, he designs a marketing page or tweaks an interface. Design recharges him and gives him fresh energy towards the project.

Making, whether it be designing, developing or even gardening or sewing, is what inspires us. It’s what we as humans were designed to do. It’s our God-given nature and there’s not a thing we can do about it.

Picking our tools is a distraction. It’s time we’re not making, and more importantly, not being inspired. Bootstrap versus Foundation… SASS versus LESS… PHP versus Ruby versus Python… flat versus skeu… Mac versus PC…

It doesn’t matter.

Actually, I take that back. It matters a darned lot. It matters that you don’t get stuck there. It matters that you build instead of plan.

Pick something. Build something with it. Only then will you really know if you like it or not. If you get to the end of the project and want to try something different next time, do it. At least you’ll have some real experience to inform your decisions.

Stay inspired. Keep moving. Work hard. Leave things better than you found them. Make stuff.

Maybe even tools.

Responsive, Flexible-Height Sticky Footers in CSS

Since I’ve been in the game, front-end devs have been wrestling with sticky footers like it was going out of style. I’m no exception, but today I learned a trick that made things a lot easier.

Before we go on though, I’d like to explain the problem briefly. It’s common for websites to have a header, a content section and a footer. On pages with a lot of content, the content takes up enough vertical space to push the footer to the bottom of the browser window. But, on pages with little content, sometimes the content does not take up enough vertical space to push the footer to the bottom of the window. This leaves the footer sitting oddly in the middle of the screen.

There are several solutions, each with their own pros and cons.

The Old Way

The old way works well, except that it relies on the footer to be a fixed height at all times. In responsive sites, this is rarely the case. Of course, you could write JavaScript that detects the footer height and adjusts the CSS accordingly, but that’s neither clean nor performant. A CSS-only solution would be better.

The display: table Trick

My new favorite approach to the problem looks something like this:

The only real caveat to this solution that I’ve encountered so far is the styling limitations present with elements using display: table-row. Often padding, margin, etc. don’t behave as expected. This is easy enough to work around by adding a <div> or something inside the .page-row and styling that:

Why not Flexbox?

As I understand it, Flexbox handles sticky footers very well. If you’re in a position to be able to use Flexbox without worrying about browser support, go for it!