0

I know all the downsides of trying to include wp-load.php, but bear with me :)

I'm trying to create my own admin-ajax-like functionality, in a way that I can control whether or not I load the default WordPress environment, whether I load it with the SHORTINIT constant defined as true, and with granular control over each module of my plug-in, as required by the specific function being access via AJAX. The only way I can think of doing that is doing AJAX via a custom file, other than admin-ajax.php, and then including wp-load.php when desired.

I've actually used it successfully for months. I've named the file bootstrap.php, and it sits inside my plugin's 'includes' directory. Requiring wp-load.php from within bootstrap.php will load WP just fine.

Today I decided I needed more control, so I attempted to delay the request for wp-load.php for when I've loaded the files containing the AJAX functions. Those files are called within bootstrap.php with include(), but requiring wp-load.php within those files will generate the following error:

Notice: Undefined variable: wpdb in .../wp-includes/ms-settings.php on line 126
Fatal error: Call to a member function set_prefix() on a non-object in .../wp-includes/ms-settings.php on line 126

The problem occurs within the loading of WP, so obviously the require() call points to the correct location of the wp-load.php file. Calling it from the file of the URL request works fine, but calling it after an include() breaks the entire thing... any ideas why?

Thanks in advance!

Improve this question

2 Answers 2

Reset to default
1

A different way of fixing it:

function load_wp(){
    global $wpdb;
    include_once('wp-load.php');
}
Improve this answer
1
  • Ooh, that's pretty clever :) I wish I had thought of that at the time... Commented Nov 10, 2013 at 12:34
0

Well, it turns out it was a problem of variable scope. I discovered that $wpdb was loading fine, but was inaccessible outside of the function that generated it, so it kind of led me to the solution: the includes() I mention in the question are done inside a function, with local (not global) scope. I'm sure, then, that it would have been a problem for all WP global variables, but $wpdb was the first one to generate a fatal error.

I didn't mention I was loading wp-load.php from a function because I didn't really know it was important. So remember, kids: don't include wp-load.php, but if you do, don't do it from inside a function.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.