Ajax in WordPress not working in IE8 and IE9

Server holding a beautifully decorated plate with salad.
Your Ajax with SSL, sir.

I recently ran into an issue where Ajax requests were not working in WordPress when using Internet Explorer 8 or 9, and while this may not be a common issue among WordPress users, you’ll most likely run into this problem if certain conditions are met on your site.

1. Cause

The conditions that must be true are:

  1. SSL is being enforced on admin pages
  2. Ajax requests are made on the front-end via admin-ajax.php
  3. Visitor is using http instead of https protocol
  4. Visitor is browsing site using Internet Explorer 8 or 9

Together, these conditions are creating a cross-origin resource sharing (CORS) issue in Internet Explorer 8 and 9 that prevents the request from ever being attempted.

1.1 Forcing SSL on admin pages

If you set the FORCE_SSL_ADMIN constant to true

define('FORCE_SSL_ADMIN', true);

to ensure users login to WordPress over https, it inherently forces SSL on anything admin-related, such as Ajax requests using admin-ajax.php

$.ajax({
  url: 'https://domain.com/wp-admin/admin-ajax.php',
  // other stuff here
});

It makes sense that admin-ajax.php would now be over SSL, since it lives in wp-admin, however there’s also no alternative for Ajax requests on the front-end of the site.

1.2 Front-end Ajax request

If this particular Ajax request is not happening on the back-end, where SSL would now be enforced, and you’re not otherwise redirecting the user to a secured version of the page, requests will happen over https on an http version of the page.

1.3 Request over https on http page

If the user is on a page using the http protocol and the request is attempted over https, Internet Explorer 8 or 9 will view this as a different domain all together, preventing the request from being initiated.

1.4 User browsing with IE8 or IE9

As mentioned toward the top, this is only a problem with IE8 and IE9. IE10+ and other mainstream browsers like Firefox, Chrome, and Safari, are not affected by this.

2. Solution

Luckily, the solution is quite straight forward. If you are localizing the admin URL, you can simply add a check that will either force http or https, depending on what protocol the user is currently using when viewing the page:

$admin_url = admin_url('admin-ajax.php', 'http');
if($_SERVER['SERVER_PORT'] == 443) {
  $admin_url = admin_url('admin-ajax.php', 'https');
}
wp_localize_script('your-script', 'php_vars', $admin_url);

Now that requests via admin-ajax.php will match the current protocol, the CORS issue is resolved.

Featured image by Lefteris Kallergis.


Comments (4)

Previously posted in WordPress and transferred to Ghost.

Jordan
April 24, 2014 at 9:33 am

Thanks Ryan, I was having exactly the issue you described and your fix took care of it! I wouldn’t have known what to try without your post.

-Jordan

Ryan Sechrest
April 24, 2014 at 10:07 am

Glad to hear it helped someone else

Grávuj Miklós Henrich
October 2, 2014 at 9:44 am

Greetings. Same solution is applicable also when on IE the add to card button is not appearing after all product options were selected?

Ryan Sechrest
October 6, 2014 at 4:09 pm

Can you clarify where you see the “add to card” button? I ask, because I don’t think this is native WordPress, but perhaps a plugin? If so, you may need to reach out to the plugin author if something isn’t working as expected in IE.