Created a class in an external script which is dependent on the Wordpress environment. Since it's a class I intend to use on various projects, I decided to dynamically create a path to wp-blog-header.php and here's what I came up with. It currently works for me, but I need to ensure that its foolproof.

$scriptName = $_SERVER['SCRIPT_NAME'];
$queryArray = explode("/", $scriptName);
$queryLength = count($queryArray);

require_once($docRoot . ($queryLength > 2 ? "/".$queryArray[$queryLength - 2] : "" ) . '/wp-blog-header.php');

Does anyone have a better solution or is this good enough to rely on, regardless of script location or WP installation setup?

4 Answers 4


In the generic case, there is no performant solution other than to check every file and folder that is publicly accessible, and then all the parent folders.

Since this is not a feasible or excusable operation to perform on every page load or request, you're left with two other options:

  • Define the location manually, which is not an unreasonable request
  • Make assumptions and expectations about where WordPress can be found relative to your file

The latter is what you'll be relying on if you want to automate things.

Issues I see with your code:

  • It assumes that WordPress is either in the same folder or 2 folders up

If you're okay with those assumptions, then yes, your code is safe to use

However I would recommend you roll your external script into WordPress as a plugin.

  • Making a bunch of utilitarian things for Wordpress, to streamline enqueues and what-not. Perhaps if the need comes up I'll roll it as a plugin, or at the very least a function you can include to help determine file paths. I'm pretty sure I found a usecase where this isn't the best solution so it's not foolproof, to say the least.
    – akamaozu
    Apr 8, 2013 at 11:43
  • How would streamlining enqueues be helped by an external script? Only thing I can think of is minifying and merging multiple scripts together, which is something that can already be done by Core or existing plugins
    – Tom J Nowell
    Apr 8, 2013 at 11:51

As per the Codex,



Whether or not your means and method is foolproof is entirely dependent upon your setup and the locations in which you are placing your scripts, relative to your WordPress installation.

Assuming you follow the convention outlined in your code, then you should be OK.

You should provide a more detailed example of script locations (including any possible variations), versus WordPress location, so if someone has something to add that can refine your code, it'd then make sense, as your snippet is to localized to your use case.


(in response to your comment)

The path to your WordPress installation is a constant, so instead of devising some trickery to figure out where that path lay, state it as is and in full, just like the example above.

If for example your actual path (for localhost) is something like;



//document root being c:\apache\htdocs

$_SERVER["DOCUMENT_ROOT"] . '/wordpress/wp-blog-header.php';

Will locate your document root, for which you then specify the your install directory and wp-blog-header.php file.

I would then place a .htaccess file in c:\apache\htdocs which amongst other things should include the following,

php_value auto_prepend_file "auto_inc.php" //the auto_inc.php can be a name of choice

This will include (auto_prepend) the file auto_inc.php before any other PHP file so if you have a directory structure like,

..\htdocs\ (root)

The auto_inc.php file will be included in any of the sub-directories, no matter depth.

Now within this automatically included file, you can place a function that wraps the require('/the/path/to/your/wp-blog-header.php'); for which you can arbitrarily use within your various projects, for example;

function wp_function_include() {

$path = require('/the/path/to/your/wp-blog-header.php');

echo $path;


wp_functions_include(); //which fires the verbose require(path..wp-blog-header.php)

Or alternatively, you need not wrap the require at all and have it be available to you on every file, sub-directory, at any depth, without ever having to specify it again, allowing you to focus on your projects.

Seeing as the /wordpress/ directory already has a .htaccess of its own, it won't be affected by the .htaccess found within its root directory, removing any clash between declaring functions twice.

  • Sounds fair. In my localhost working environment, the path to the Wordpress Installation looks like this: localhost/installation_dir In my production server, the path looks more like this siteurl.ca The snippet of code works perfectly for installations that are at root and one folder deep, but I haven't tested it on installations deeper than one folder past root. The require/require_once snippet works well. What I'm trying to hammer down is a path to WP Installation root regardless of where the script is located.
    – akamaozu
    Aug 9, 2012 at 22:40
  • I see what you did there, but the path is not always a constant. This script is currently stashed in the wp-content/themes/themeroot/functions/. It could be stashed in one folder up, or somewhere totally different (like a plug-in folder). The path from the script to wp-blog-header.php is always undetermined. Is there no way in PHP to automatically map it, regardless of how convoluted the path gets?
    – akamaozu
    Aug 10, 2012 at 16:25

You just need the followingcode to apply to get real path for the wp-blog-header.php

$scriptPath = dirname(__FILE__);
$path = realpath($scriptPath . '/./');
$filepath = split("wp-content", $path);
// print_r($filepath);
define('WP_USE_THEMES', false);
  • wp-content can be changed to whatever you like. That's not a static string in WP.
    – kaiser
    Feb 28, 2014 at 13:59
  • i think wp-content would be because wp-content is main folder of wordpress which can not be changed [code]$scriptPath = dirname(FILE); $path = realpath($scriptPath . '/./');[\code] Gives you path like /home/wordpressfoldername/wp-content/plugin/yourpluginname So we can easily split wp-content and get path the wp-blogheader.php Mar 4, 2014 at 10:49
  • No. You can set the constants WP_CONTENT_DIR and WP_CONTENT_URL to whatever you like in your wp-config.php file.
    – kaiser
    Mar 4, 2014 at 10:56
  • Bro change the code according to your requirements Mar 4, 2014 at 17:34

BTW, if you want to include worpdress core (+theme functions), its better to user:


and NOT


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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