Quick Note About WooCommerce Checkout with Ajax

I’m working on a woocommerce plugin, and I had a problem I could not figure out. I spent quite some time, until I realized what was going on.

I have a class that, when initialized, checks if the current page is admin or front end. If it is admin, then it loads another class that takes care of displaying the admin options. If it is not admin, then it adds a few filters. The problem is that they were not working. I spent a lot of time trying to debug this, but could not find the problem.

I have something like this:

function __construct(){
  if(is_admin()){
    //load options class
  }else{
    //add filters.
  }
}

At some point I added a

die()

in the else block, and the script died, so I thought: “This block is being executed, so the problem is not here”. This made me look for the bug in other places, and I wasted even more time.

I event looked at the source of

is_admin

but that did not help.

At some point I decided to remove the else part of the if statement. To my surprise, it worked. So, what does that mean? it means that at the time the script runs the

is_admin

function is returning true. How is that possible? I checked earlier if that block was executing, and it was. We know that it was because the script died. So how is it possible that now, at the critical moment, when the checkout form is submitted, and my filters are supposed to be executed, the script is running on the admin side? Pretty simple, the form gets submitted via ajax. In order to be able to submit the form via ajax, it gets submitted to admin/. You can create your own ajax mechanism, but of course it is easier, and maybe better to use wordpresses’. Unfortunately, wordpress offers this ajax mechanism on the admin side only. My guess is that they implemented it at some point for internal use, and decided to also make it available to the public. The reason you have to use this mechanism is that it takes care of loading the wordpress engine so that your scripts execute on the wordpress environment.

So the solution to the problems was now obvious. Let’s remove the

else

leaving the block of code outside of the

if else

statement. This way it executes regardless of whether it is on the admin side or front side. Is this a problem? In my case not, but it could be.

Imagine that rather than adding a couple of filters, I were doing some heavy computational work. This work would execute every time, even when not needed. Lets imagine a scenario where I want to display the result of some heavy computational work. I want to present this result on the user side of the site, and update it every so often via ajxa.This work would be executed whether I am on the user end or not. Since I would be using ajax to get this result updated I could not prevent it’s execution when on admin using

is_admin

because in fact, this work would have to be performed on the admin environment, even though the result would be displayed on the user front end. Of course, we could check from more than just

is_admin

but I don’t think we should have to. This just makes me confirm that the ajax mechanism on wordpress is broken, at least on the user end.

If you want to dig a bit deeper on this matter, I suggest you check out the woocommerce.js file located on assets/js on the woocommerce plugin directory. The version of woocommerce at the time of writing this entry is 1.5.4, and the code in question starts on line 671 of the aforementioned file.

2 thoughts on “Quick Note About WooCommerce Checkout with Ajax

  1. As you have described the whole issue and given the solutions for the same, the way of explanation is extremely excellent. I would like to appreciate your nice effort of posting useful information. Your post is really helpful.

Comments are closed.