jQuery Ajax returning 404 Error, but correct Respo

Question

I'm posting some data to a PHP script via jQuery AJAX, and everything executes correctly, but it returns a 404 error. In my Firebug console the response from the PHP script is correct. I don't understand how the script can respond, and it is still throwing a 404 error. The jQuery "error" callback method triggers, and the "success" method doesn't.

All statements performed by the PHP script work accurately, because I can see the database being updated, etc.

I'm using jQuery 1.4.2, on a WordPress 3.x website hosted by Dreamhost.

-----------MORE INFO-----------

OK, I've figured out that when I include WordPress's wp-blog-header.php file in the Ajax script, I get the error. Also, once upon a time these scripts work, and I am 90% sure they stopped working after the WP 3.0 update. I'll paste in the Response headers from Firebug.

This header response from PHP that includes the wp-blog-header.php and returns a 404 error in Firebug...

Date                Tue, 10 Aug 2010 01:44:44 GMT
Server            Apache
X-Powered-By        PHP/5.2.6
X-Pingback        http://www.learnwake.com/xmlrpc.php
Expires          Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control       no-cache, must-revalidate, max-age=0
Pragma            no-cache
Last-Modified       Tue, 10 Aug 2010 01:44:44 GMT
Vary                Accept-Encoding
Content-Encoding    gzip
Content-Length    36
Keep-Alive        timeout=2, max=98
Connection        Keep-Alive
Content-Type        text/html; charset=UTF-8

This header response from PHP that doesn't include the wp-blog-header.php and returns a 200 OK in Firebug...

Date                Tue, 10 Aug 2010 01:44:58 GMT
Server            Apache
X-Powered-By        PHP/5.2.6
Vary                Accept-Encoding
Content-Encoding    gzip
Content-Length    36
Keep-Alive        timeout=2, max=100
Connection        Keep-Alive
Content-Type        text/html

Answer 1

Overall there aren't a ton of places where WordPress will return a 404. I recommending grepping the source tree for those places and placing some debug code to trace why it's happening.

Answer 2

I've added an ajax.php file in a WordPress template once, and had this problem.

I solved it simply by adding at the top of ajax.php

header('Response: HTTP/1.1 200 OK');

Kind of a hack, but it worked.

Answer 3

No one else posted this as an answer, so it's worth noting. You should be including wp-load.php instead of wp-blog-header.php.

If you open up wp-blog-header.php you'll see why:

if ( !isset($wp_did_header) ) {

    $wp_did_header = true;

    require_once( dirname(__FILE__) . '/wp-load.php' );

    wp();

    require_once( ABSPATH . WPINC . '/template-loader.php' );

}

If you are only outputting json for an AJAX operation, you do not need to include template-loader.php. This will create unnecessary overhead, and then of course provide the 404 error.

This 'workaround' is necessary for current and future versions of WordPress. I'm assuming anything past 3.0 should include wp-load.php as stated.

Answer 4

Based on the answer from Tim, I changed the hook I was catching from "wp" to "init" in my plugin and it stopped giving me the 404.

Answer 5

I had the same problem.

The Fix.

Change:

require_once('wp-blog-header.php');

To:

require_once('conn.php');
require('wp-config.php');
$wp->init();
$wp->parse_request();
$wp->query_posts();
$wp->register_globals();

This will also fix HTTP header errors if you want to have a page outside WP.

Answer 6

When you include wp-blog-header.php, you end up bootstrapping the whole WordPress setup routine. The function wp() is called, which calls $wp->main(), which in turn calls various setup functions.

One of these is $wp->query_posts(), which calls $wp_the_query->query(), which in turn calls WP_Query's parse_query() function. I suspect that the 404 indication is generated in there (your AJAX page isn't a WP post, or anything like that), and is later transformed into an actual 404 response header by $wp->handle_404(), the function called after query_posts() in main().

I'm not 100% sure that parse_query() is the definite culprit, but I would suggest seeing if you can just include wp-load.php instead, since I believe it does the actual work of creating the objects that you want to access.

Again, I don't actually use WordPress, so I can't be sure, but looking at the source code this seems to be the most likely case, from what I can tell.