Ajax in WordPress is something I’ve discussed a few times on this site. For example, I’ve touched on:

But you know how it goes: Over time, things change. WordPress matures, we grow as developers, and techniques and methods that we might have used yesterday (or last year) aren’t necessarily the best way to achieve the same thing as today.

Ajax in WordPress

And Ajax in WordPress is one of those things. Although the actual API may still be the same, the way in which we can build object-oriented solutions that communicate with it can be refined a bit more (at least in contrast to what I used to do).

Ajax in WordPress

Assume for a moment that I have a menu page that has a feature that will leverage Ajax functionality. Perhaps this is at the template level; perhaps it’s at the partial level.

For this post, it doesn’t matter. The point is that the menu page will be communicating with the WordPress API to wire up its Ajax functionality.

But, as discussed in several previous posts, this is not necessarily functionality that the options page should be responsible for maintaining. Instead, let’s say the there is a class responsible for registering all of the Ajax requests.

1. An Ajax Manager

Perhaps a descriptive name for this class is Ajax_Manager. The implementation may be something as straightforward as the following code:

The implementation of the class is simple:

It accepts an object argument and a method argument. The object is the class in which the method resides that will perform the action when invoked via JavaScript.

Obviously, this could be grown into a more mature class but remember that this class has a single responsibility: Connect an existing class and it’s methods with the WordPress Ajax API.

2. The Page Knows The Manager

Next, since the menu page is the object (in this example) that has the functionality to invoke via Ajax, we can pass this class as a reference in the menu page’s class constructor and set it as a property.

The constructor will look like this:

And the invocation of the class will now look like this:

Now, this example is about as simple as it gets. The thing is, the Ajax_Manager could be passed around to as many classes that need it and though that’s the big idea behind this post, this showing but one way to do this.

3. The Partial Defines The Functionality

At this point, we can now register an asynchronous event on an existing class and its methods. Let’s say that we have a partial that’s part of our options page. This partial, $event_partial, is responsible for rendering options related to a calendar event.

Specifically, part of that functionality will result in retrieving the taxonomies for a certain custom post type. This method that will achieve this is a method called the_taxonomies.

Since the options page is composed of partials and since the above partial has a method that will be used via Ajax, the Event partial doesn’t have to do anything but define the method to be invoked via JavaScript.

Everything else is wired up via the page and the Ajax_Manager. More specifically, there are no calls to add_action( 'wp_ajax_{action_name}', 'method' );.

4. The JavaScript Asks For Information

Finally, the associated JavaScript file (which should ideally be a single JavaScript object all on its own) can make the call like this:

All that’s needed is to make sure that the script is properly registered and enqueued within WordPress.

Alternative Implementations (Always)

As mentioned, this example is meant to demonstrate the advantages of having a single Ajax_Manager class that can be passed around to other classes in the plugin that need Ajax functionality.

This allows classes that need Ajax functionality to maintain a property to an external object that’s responsible for registering it with WordPress without having to implement the details on their own.

This also allows us to easily have a single class to introduce for advanced Ajax functionality in WordPress. Finally, it allows us to keep the JavaScript as independent as possible. All it needs to know is the name of the action to call and the name of the method.

I’m sure there are other ways to go about doing this, but this is one of the easiest, more reusable ways I’ve found when implementing Ajax in WordPress that’s not only useful in a given project, but useful in any project that needs Ajax functionality.