Let’s say that you’re working with Ajax in WordPress. And let’s say that, whatever you’re building, is using object-oriented programming.

Depending on the complexity of your work, you may find that how you’ve implemented your Ajax functionality doesn’t work.

That is:

  • You’ve implemented the proper hooks
  • You’ve got the callbacks defined
  • You’re `echo`ing the data properly
  • You’ve got the `wp_die()` call at the end of each request
  • And you’ve setup `console.log()` or other debugging statements in your Development environment

But you’re still seeing the request return 0 for everything you’ve implemented.

What gives?

Priority and Ajax in WordPress

The short of it is that depending on when you define your hooks, you may have them defined too late. Furthermore, changing the priority with an argument in the add_action call will not help.

The more detailed explanation has to do with instantiation and the order in which things are setup in the plugin.

Whether this is a bad thing, per se, isn’t the point of this post.

Instead, it’s meant to provide a fix to resolve a situation just like this.

In My Case…

I was recently working on a project that was using a fair amount of Ajax on the front-end. In short, the plugin was doing the following (all asynchronously):

  • Setting up two database values
  • Polling the database every N-seconds
  • Determining what course of action to take after M-seconds had passed

Sure, this is a bit simplistic but the point remains. Anyway, I had the classes organized such that:

  • There was one class that served as the single point of entry into the plugin
  • Once that class was all setup, it would then initialize its dependencies
  • Once it had initialized its dependencies, it then instantiated the related classes

One of the related classes was responsible for setting up the Ajax functionality. From a programmatic perspective, you can see these hooks were last in the lifecycle of the program.

No good, huh?

But if you’re someone who aims to have solid class design, this presents a problem. Further, if you opt to balance good design with WordPress best practices, it gets more complicated.

Unfortunately, sometimes WordPress best practices and object-oriented design can be mutually exclusive. That’s another post, though.

Anyway, faced with this solution, what are we supposed to do?

Refactor That Code

In a manner of speaking, the best thing to do is to yank out – a professional term, to be clear – the Ajax code and move it.

What does this mean, exactly?

Rather than have it residing in a related class (or even a dependent class), it needs to be setup separately. Although the functionality may still be related – that is, have a high-level of cohesion – we have to work around the constraints of the system we’re in.

This includes WordPress and PHP.

So to fix this, I recommend the following:

  1. If your Ajax code is not contained within its own class (or set classes), make sure that it is.
  2. Make sure no other classes are instantiating it. I’ll cover this more in a moment.
  3. If the Ajax class needs information from other classes, make sure it’s accessible. This could be via `set` methods or by reading database values.
  4. If other classes in the project need to access what the Ajax code has done, give them knowledge of the Ajax class. Or, better yet, have them read the database values the Ajax classes are writing.

Sure, this is easy to explain at a high-level, but what might this look like in the context of a plugin?

First, we need to make sure that the Ajax functionality is in its own file (or files). So perhaps you have an inc directory for the files:

A single class for Ajax in WordPressNext, you make sure to require those files in the bootstrap of your plugin. And you make sure to initialize those classes in the same file:

After that, you setup the rest of the plugin so that the main class mentioned earlier in this article starts:

Order is important. Your plugin is likely to need the values the Ajax functionality is writing. I’d say rarely will Ajax code will need to communicate with non-asynchronous code.

Sometimes, maybe. But not always.

Anyway, this makes sure that the asynchronous code is setup and working before anything else is set into motion. This gives the most flexibility as it relates to reading and writing this type of code.

There Are Other Ways

Sure, as with anything in programming, there are other ways to implement this solution. I’m not claiming this is the best way, but it’s a way that worked well for my project.

Further, it helps to contain the asynchronous code into its own set of files. This made it easier to know where to place code and how other code can read the values.

On top of that, it also helped to organize other files like JavaScript around what would be synchronous and what would not.

Ultimately, the take away is that if you’re working with Ajax in WordPress, setup the relevant code as earlier as possible. Otherwise, you may find yourself getting unexpected results when you’ve done everything else correct.