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.

Category:
Articles
Tags:

Join the conversation! 6 Comments

  1. Great article and approach using OOP , what i will also suggest also is this: if the assets can be built into a class accepting a single array containing js and css file array indicating the ver, dependencies, file path and a TYPE: which could indicate either a css file or a js file. so for example, we would have Assets_Loader( array(

    array(

    ‘name’=>’file_name’,

    ‘ver’=>rand(),

    ‘type’=>’js or css’,

    ‘path’=>’file_path’,

    ‘dep’=>’the_dependencies’,

    ),

    array(

    ‘name’=>’file_name’,

    ‘ver’=>rand(),

    ‘type’=>’js or css’,

    ‘path’=>’file_path’,

    ‘dep’=>’the_dependencies’,

    ),

    ) );

    • Great article and approach using OOP

      Thanks! I don’t consider it great OOP (since this is just Part 1), but it’s a  step into the direction that I hope to take readers in a future post.

       if the assets can be built into a class accepting a single array containing js and css file array indicating the ver, dependencies, file path and a TYPE: which could indicate either a css file or a js file.

      You’re on the right track, but I would simplify this even more: A class shouldn’t need to have an array to manage multiple dependencies.

      Instead, I want to ultimately create a single JavaScript Dependency class and a single Stylesheet Dependency class. Then each would have attributes describing its version, name, path, etc. 

      After that, you instantiate each one as needed and add those instances into a  collection in the Assets_Loader

      From there, the Assets_Loader iterates through its collection of actual object references and uses their properties.

      All that to say, continuing to use arrays is still not OOP “enough,” IMHO. We’ve gotta continue to use classes and other attributes and functions that allow us to achieve the same functionality without data structures like that.

      Enough information is stored in massive arrays in WordPress already.

      • Hi Tom!

        Thank you for sharing an alternative way to manage assets in WordPress!

        However, I am not 100% sure that I understand the advantage of your approach compared to just wp_enqueue_script and wp_enqueue_style. Is it a performance gain? Or maybe the advantage is just having a more structured approach?

        Thank you!

        • However, I am not 100% sure that I understand the advantage of your approach compared to just wp_enqueue_script and wp_enqueue_style. Is it a performance gain? Or maybe the advantage is just having a more structured approach?

          It still uses both of these functions (see the functions enqueue_scripts and enqueue_styles in the class in the gist above).

          What this code does is rather than having a bunch of redundant function calls, it creates an array of dependencies, sets up two functions hooked to the appropriate WordPress hooks, and then fires those functions.

          Those functions then iterate through the array — if it’s working on CSS files, then it will loop through the array with the css index. If it’s working on JS files, then it will loop through the array with the js index.

          This is really just the first part of this series, though. Ultimately, it can be made more object-oriented such that it doesn’t require an array. And that’s what I’ll show in a follow-up post.

  2. Hey Tom,

    I did something very similar to enqueue my assets in my brightnucleus/dependencies package. I called them dependencies in my library, but I now think that talking about assets is preferable.

    If I remember correctly, this particular package originally started out as code by Gary Jones, and I just executed on the details.

    I have two notable differences in my package, and here’s why:

    I have abstracted away the type of asset, together with the functions that are needed to register and enqueue it. This way, you can easily add a third type of asset, change the handling of a specific type of asset, etc… all without modifying the original code.
    I have extracted the actual project-specific details you have in your $assets property into an external Config file. This makes the class itself 100% reusable, and you can use it in many different projects, by simply passing different Config files through its constructor.

    • I called them dependencies in my library, but I now think that talking about assets is preferable.

      I tend to use ‘assets’ just because somethings they aren’t necessarily things my projects depend on but they are things my project will use (because assets can cover for than things that the project does depend on).

      But, like you, that was one of those things that has come over time.

      I have abstracted away the type of asset, together with the functions that are needed to register and enqueue it. This way, you can easily add a third type of asset, change the handling of a specific type of asset, etc… all without modifying the original code.

      The way I’m working towards this is similar though it sounds like it might be a bit different. I have an asset interface that allows me to create a more concrete type and then toss it into a collection through which I can iterate and enqueue or, really, do whatever I need to do with it.

      It has properties that allow me to read information from it without having to traverse an array (like we so often do in WordPress).

      I have extracted the actual project-specific details you have in your $assets property into an external Config file. This makes the class itself 100% reusable, and you can use it in many different projects, by simply passing different Config files through its constructor.

      I’m hoping if I can get this right over time, that I won’t necessarily need configuration — everything can just be spun up via code as needed; however, it sounds like our uses cases are a little bit different, too.

      And that’s always okay :).

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.