Foolproof Front-End Asset Cachebusting

Here’s a scenario you’re probably familiar with if you’ve done any amount front-end development. After deploying a CSS or JavaScript change and notifying the client, you hear back that they’re not seeing the updates. This is usually because their browser has the old CSS/JS cached and needs to be hard reloaded to re-download the new assets.

This isn’t too big of a deal for low-traffic sites or small changes, but what about when you’re deploying a significant change to a high-traffic site? I had a scenario recently where I was deploying a new header and navigation to a high-traffic website that had been using the old header styles for years. We’d rebuilt it from the ground up — new HTML, CSS, JS, everything — so without the new front end assets, the page looked completely broken.

Version Parameter

A common trick to force the browser to re-download assets is to add a version parameter to the query string of the CSS or JavaScript file you’re linking to:

Every time you make an update to the file, you’d update the version to a new value, which the browser reads as a new URL it must re-download to it’s cache. This is a pretty good solution, except that you have to remember to change the version every time you’re deploying updates that necessitate the browser re-download new assets.

Timestamp Versioning

One solution I’ve seen to this is using a timestamp as the asset version. This is especially helpful during development because it ensures you have the freshest version of the file on every page load:

While the timestamp method works well for development, but you wouldn’t want to use it in production since it forces the browser to re-download the assets on every page load — no bueno. Ideally we’d like a solution that only forces the browser to updates its cache when something changes, but makes use of the cache for performance reasons when it can.

File Modified Versioning

The solution is to set the version parameter to the timestamp of the last file modification for the asset you’re linking to:

Think about it — this solves all of our problems. Without any manual work, we’re guaranteed the browser will re-download our assets every time they change. And if they haven’t, the URL remains the same on as the last page load and the browser can keep its existing cache. Viola!

Integrating in WordPress

Since most of my work takes place in a WordPress environment, here’s how you’d integrate this using WordPress’s wp_enqueue_style() and wp_enqueue_script() functions:

Whatever you pass to the 4th parameter in both enqueue functions serves as the value for the ver parameter in the URLs to the asset files generated by WordPress.

Other Options

As is usually the case, CSS-Tricks has a great post listing a bunch of different methods to tackle this problem.

If you have a favorite solution, let me know in the comments.

Migrating a WordPress Site from utf8mb4 to utf8

Starting in version 4.2, WordPress will attempt to upgrade its database tables from utf8 to utf8mb4. You can read more about the change on if you’re into that kind of thing, but most of the time it won’t affect you. Most of the time.

It did affect me though. I ran into an issue where I’d built a site on a development environment running on MySQL 5.5 which supports utf8mb4, but had to launch it on Media Temple’s Grid service, which runs MySQL 5.1 and doesn’t support utf8mb4. I saw a few people recommending exporting the 5.5 database in phpMyAdmin using MYSQL40 compatibility and importing that into your 5.1 environment, but when I tried it, it messed up some serialized Beaver Builder data.

Eventually I discovered that WP Migrate DB is the way to go. The free plugin allows you to export your data with URL and file paths automatically replaced, and pre MySQL 5.5 compatibility. I ran it on the development site and got an export that I was able to import directly into the live, 5.1 environment without errors or corrupted serialized data.

I’m not sure how much of an edge case my situation is, but hopefully this is helpful to someone. Any other work arounds you’re aware of?

Gravity Forms Dashicon Plugin

If you’re someone like me that spends a lot of time in the WordPress admin, you’ll realize that little details in the UI can make a big difference. Combine that with my already slightly OCD bent, and it probably won’t surprise anyone that I find the lack of a Dashicon for Gravity Forms extremely annoying… so much so that I decided to make a plugin to fix it.

You can download it on GitHub. Hopefully they’ll update the core plugin before too long and this can become unnecessary.

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.