Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

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!

share|improve this question
add comment

2 Answers

A different way of fixing it:

function load_wp(){
    global $wpdb;
    include_once('wp-load.php');
}
share|improve this answer
    
Ooh, that's pretty clever :) I wish I had thought of that at the time... –  tbuteler Nov 10 '13 at 12:34
add comment
up vote 0 down vote accepted

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.