In the previous post in this series, we revisited the topic of working with Ajax in WordPress. Ultimately, the goal is to improve upon a previous series that was run on the site a few years ago.

To reiterate, it's not that the techniques taught in the original series were wrong, but it's that software changes over time so it's always good to revisit concepts that were covered years ago and try to update them to something that's a bit more current and more resilient for our development efforts.

Recall from the previous post, we looked at the following comment from the original series:

We're going to give a very brief overview of what Ajax is, how it works, how to set it up on the front, and understanding the hooks that WordPress provides. We'll also actually build a small project that puts the theory into practice. We'll walk through the source code and we'll also make sure it's available on GitHub, as well.



And in that post, we reviewed some advanced ways to incorporate the WordPress Ajax API into our projects using procedural programming. In this post, we're going to take the code that we wrote in the first part of this series and refactor it so that it uses an object-oriented approach.

Ultimately, the goal is not to make a case why one paradigm should be used over the other; instead, it is to show how we can achieve the same functionality regardless of the approach that you choose when building your plugins.

Planning the Plugin

Before we get started refactoring the code, something that we need to consider is how we're going to lay out the various files. After all, part of the process of beginning a new project—or even jumping into an old one—is planning how work is going to be done.

For this particular plugin, we're going to need the following:

a bootstrap file that's responsible for initializing the main class and starting off the plugin

a class that's responsible for loading the dependencies such as the JavaScript

a class that serves as the main plugin class

As you can see, there's not too much that we need to do to the plugin. We'll also be re-organizing some of the files to have a consistent directory structure, and we'll make sure to properly document all of the code so that it follows the WordPress Coding Standards.

With that said, let's get started.

Organizing the Files

Before we get into writing any code, let's go ahead and do the following:

Create an assets directory. Create a js directory that will be located in the assets directory. Move frontend.js to the js directory.

The reason for doing this is that we're moving into an object-oriented style of programming. Part of this includes organizing our files so that they follow conventions often considered to be packages.

In our case, the assets directory includes all of the things necessary to make the program run. For some plugins, this could be JavaScript, CSS, images, fonts, and so on. In this instance, we have a single JavaScript file.

The Dependency Loader

Next, we need to introduce a class that will be responsible for loading the dependencies for our project. For this particular plugin, the only dependency that we have is the JavaScript file that we just placed in the assets directory.

Part of object-oriented programming is making sure that each class has a specific purpose. In this case, the class we're about to introduce will be responsible for loading the JavaScript using the WordPress API.

Let's start by creating the basic structure of the class:

Next, we'll add a method that will be responsible for enqueuing the JavaScript as per the WordPress API.

After that, we need to take the functions responsible for handling the Ajax requests and providing responses and then add them to the class. Since they'll be within the context of a class, we need to add a new function that will register them with WordPress.

We'll create a setup_ajax_handlers function. It looks like this:

Next, we need to actually move the functions into this class. Note that the functions that were originally prefixed with _sa are no longer marked as such. Since they are in the context of the class, we can drop the prefix and also drop the underscore in favor of the private keyword.

Then we'll save this file in an includes directory in the root of the plugin directory. The includes directory is often where code that is used throughout a project is located. More could be said about this particular directory, but that's content for a longer post.

The final version of this class should look like this:

The Main Class

Now we're ready to write the main class for the plugin. This particular class will reside in the root of the plugin directory and the basic structure of the class will look like this:

Next, we'll add a couple of properties that we'll set when the class is instantiated:

After that, we'll create a constructor and an initialization function that will be used to set the plugin in motion:

In the code above, the constructor sets the properties and instantiates the dependencies necessary to set the plugin in motion.

When initialize is called, the plugin will start and it will call the initialize method on the dependency class we created earlier in this tutorial.

The Bootstrap

The last thing that we need to do is to take the main file that we have, use PHP's include functionality, and make sure it's aware of the necessary PHP files that we have.

After that, we need to define a method that will initialize the main plugin file and set everything in motion.

The final version of the bootstrap file should look like this:

First, the file checks to see if its being accessed directly by checking to see if a WordPress constant has been defined. If not, then the execution stops.

After that, it includes the various classes we created through this tutorial. Finally, it defines a function that's called when WordPress loads the plugin that starts the plugin and sets everything into motion.

Conclusion

And that brings us to the end of this two-part series. Hopefully you've learned not only some of the best practices for incorporating Ajax into your WordPress projects, but also a bit about documenting both procedural and object-oriented code as well as seeing the difference in how much of the code is laid out.

In a future post, I may revisit some of the object-oriented concepts that were introduced here and cover them in much more detail. For now, however, have a look at the plugin using the GitHub link on the sidebar of this page.

Remember, you can catch all of my courses and tutorials on my profile page, and you can follow me on my blog and/or Twitter at @tommcfarlin where I talk about software development in the context of WordPress.

As usual, please don't hesitate to leave any questions or comments in the feed below, and I'll aim to respond to each of them.