Loading WordPress assets usually consist of making multiple calls
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.
- 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.
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.
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.
We can do a similar thing with stylesheets, as well:
Enqueuing The Code
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
version, and some optional
dependencies. There may also be the need to request this information from the object. We can implement this abstract class.
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
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.
Leave a Reply
You must be logged in to post a comment.