Artem Russakovskii's programming and technology blog

Updated: August 30th, 2014

Introduction

In this tutorial, I am going to introduce a WordPress technique that I believe was unpublished until I raised the question a few days ago on the WordPress forums.

In short, the problem I was trying to solve was plugins unnecessarily loading their JavaScript and CSS on *every* page of the blog, even when doing so would achieve absolutely nothing and the plugin wouldn't do any work.

Let me explain using this example:

• a code formatter plugin only does something useful when it sees a [code] shortcode in any post on the page.
• most of your posts do not contain the [code] shortcode as you don't include code snippets that often or you only started using this particular plugin recently.
• the plugin, however, loads the CSS and JS (which are most likely GeSHi and take up loads of space) on every page.
• these CSS and JS do absolutely nothing on most page loads.
• bandwidth is wasted, extra DNS and HTTP requests are processed, the browser is slowed down, and for what? For no good reason, other than the plugin author didn't know how to achieve this conditional loading.

If you think about it, there are many plugins that only do something once in a blue moon. Table of contents, text manipulators, galleries, sliders, etc, etc. If only they loaded their frontend code strictly when necessary, most page loads would suddenly become much lighter.

So what can we do to solve this? Let's look at a few techniques.

Loading CSS And JS In Place?

Here's one, albeit pretty bad, solution – only print the CSS and JS includes if and when you determine somewhere in the middle of loading the posts that the scripts and styles are indeed needed, then set a flag to avoid printing them again. In our example, that would be when the plugin detects the [code] shortcode.

This, however, is a mediocre solution because, while it's not a bad idea to load Javascript in the footer, CSS should be loaded in the header, otherwise the page might look unformatted until the CSS is reached.

Additionally, it's not the cleanest and most robust solution because you shouldn't be writing <script> and <style> tags manually but rather using wp_enqueue_style() and wp_enqueue_script() functions.

What's This About wp_enqueue_FOO?

Now, you might say: "What's this about wp_enqueue_style(), wp_enqueue_script(), and then hooking into 'wp_print_scripts', 'wp_print_styles', 'admin_print_scripts', and 'admin_print_styles' hooks"? You know about these, right? Right??

Allow me to explain this, in my opinion, greatest and most underused WordPress paradigm in a short refresher:

Enqueuing Alone Is Not Enough

Enqueuing is great for loading your JS and CSS but using it alone doesn't achieve the conditional behavior that we are looking for here.

This is a classic case of Chicken or the Egg, because WordPress makes only one pass through all of the content.

You see, since the header needs to be printed before the content, wp_print_scripts and wp_print_styles hooks are triggered before you even get to the posts. If you enqueue a script or style from within the 'the_content' hook, for example, the queued up scripts and styles will never get printed. It's too late to print them then anyway, as you're already in the middle of printing the posts.

The Solution

What we need to do is take a step back, before even printing the header, and then peek ahead.

Sure, this adds an extra pass over some data, but since no filters are applied during this process and if you avoid regular expressions (using stripos(), for example), this extra pass should be quite negligible.

The upside, however, can be potentially very substantial.

Credit goes to @white_shadow for the idea.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

add_filter('the_posts', 'conditionally_add_scripts_and_styles'); // the_posts gets triggered before wp_head
function conditionally_add_scripts_and_styles($posts){
	if (empty($posts)) return $posts;
 
	$shortcode_found = false; // use this flag to see if styles and scripts need to be enqueued
	foreach ($posts as $post) {
		if (stripos($post->post_content, '[code]') !== false) {
			$shortcode_found = true; // bingo!
			break;
		}
	}
 
	if ($shortcode_found) {
		// enqueue here
		wp_enqueue_style('my-style', '/style.css');
		wp_enqueue_script('my-script', '/script.js');
	}
 
	return $posts;
}

This simple function fires before the header gets printed, as it's attached to the 'the_posts' hook. However, this time it has full access to the posts' content.

I have tested this method and it works really well – if you have heavy scripts in your plugin, please do us, users, a favor and incorporate this logic into it.

Conclusion

In this tutorial, you have seen a method of loading scripts and styles for you plugin conditionally. This technique allows for less bloated pages and faster page loads.

Plugin developers, what is your take on this solution? Do you use another method? Please share in the comments.