Loading WordPress assets usually consist of making multiple calls wp_enqueue_script or wp_enqueue_style, but this makes for redundant calls and unnecessarily long methods.

So I’ve been experimenting with a variety of different ways to load assets. And though I’m not planning to layout the final version of the code for doing this in this post, I thought it’d be worth starting from the first pass at how we can improve our process.

After all, even if there’s one degree of improvement to make in your work, isn’t it something worth considering?

Loading WordPress Assets

As mentioned, most WordPress developers – be it for themes or plugins – are familiar with the process of loading assets and the various things that come with this.

For example:

  • JavaScript files include the source of the file, any dependencies, the version of the file to use, and whether or not you’re going to include in the footer of the page.
  • Stylesheets include the path to the source file, any dependencies required, the version to use, and the media to which the stylesheet is applicable.

These methods require a defined set of arguments some of which are required and some are optional.

A Class For Loading WordPress Assets

With all of the above laid out, this gives us an opportunity to look for ways to improve the process by which we load assets and to improve the way we do this.

If you’ve read my post on combining your scripts into a single file (which may not be necessary if you’re using HTTP/2 though that’s a topic for another post), then your build process may change some of the organization of this information.

Class Design

With that said, let’s say that we want to focus on organizing our assets and then defining them as an attribute or a piece of data within a class.

The initial class design might look something like this:

Notice that there’s a class, an attribute that is an array that’s responsible for maintaining the attributes, and then a few function that we’ll see put to use in a little bit.

Again, remember this is just the first part in properly organizing our assets, but it’s a start.

JavaScript Files

First, let’s assume that you have a single, concatenated JavaScript file that requires jQuery as a dependency, and it will be using rand() to act as its version.

Note that I don’t particularly like this strategy, but it does bust the cache, and it serves a purpose for this example. If you’re interested in a more advanced approach, I recommend Alain Schlesser’s cache busting strategy.

With that said, let’s first define the JavaScript file in our constructor:

As you can see, we’ve got a path to the JavaScript file, the version, the path, and the dependencies all defined in the context of this array.

Stylesheets

We can do a similar thing with stylesheets, as well:

Notice that it’s not altogether different from what was demonstrated in the JavaScript code above.

Enqueuing The Code

Next, we need to define functions that will register the assets with WordPress. First, we can do that with JavaScript:

Then we can do that with CSS:

And after that, we can take a look at the entire class.

The Final Code

The final class that’s been shown up to this point will look like this:

But there are some things to discuss regarding how well this class works in the context of object-oriented programming (with or without WordPress).

Lots of Room for Improvement

First, using a data structure as an array to contain this type of information is not an ideal way to go about this. Instead, it would make more sense to define a base class (perhaps something like GenericAsset or something named better than that. It would define the methods and properties an asset would have.

For example, we know that assets have a path, a version, and some optional dependencies. There may also be the need to request this information from the object. We can implement this abstract class.

Next, the Assets_Loader doesn’t need to know all of this information (as it does in the arrays right now). Instead, all it cares about is having a set of assets that it needs to register with WordPress.

This implies that the loader is responsible for registering a Stylesheet_Asset and a JavaScript_Asset or a collection of each. So perhaps there’s a mechanism that would take the Asset_Loader and pass all of the assets it needs to register with WordPress into a private collection.

But all of this is just setting up a case for how to handle this in a future post. I don’t necessarily know when I will be writing Part 2 of this post. But I wanted to make sure that I shared at least one incremental improvement over the traditional way of filling up a single function with multiple calls all of which are doing the same thing.