The hassle with WP_CONTENT_URL and WP_PLUGIN_DIR

Since WordPress 2.6 it’s possible to move wp-content and the plugins path to a different location. Basically not a bad idea , except the situation that my plugins wordTube / NextGEN Gallery loads some XML/AJAX based “standalone” php files not via the admin page. This means I need to know the location of wp-load.php. In the past I can be sure that my plugin is located always below wp-content/plugins/<plugin name>. So it was easy to get the correct path to wp-load.php

Now this has changed and Ozh show up the new way in his article. In his discussion with GamerZ he added the note to the article :

However, as pointed out by GamerZ in the comments, this still may not work. Why? Because not only the config file may not be there anymore, but the relative path to it may have changed since wp-content might have been moved too.

At this point though, there is no way I can think of to guess the locations of both wp-config and wp-content. To be 100% foolproof, such a “standalone” file needing to include wp-config should be editable so that advanced users moving their wp-content directory could manually edit a location path (the $root variable in the previous example)

I’m currently thinking what would be the best solution. For a intermediate solution I will now add a “config” file where you can add “server path” to wp-load.php in the case you moved the plugin folders. The disadvantage of this solution is the automatic upgrade procedure, because every upgrade wipe out your changes (Mhh, would be not a good idea to have a way to exclude files from the upgrade procedure ??).

Anyway here is the code :

[code lang="php"]
/** Define the server path to the file wp-config here,
if you placed WP-CONTENT outside the classic file structure */

$path  = ''; // It should be end with a trailing slash   

/** That's all, stop editing from here **/

if ( !defined('WP_LOAD_PATH') ) {

 // classic root path
 $classic_root = dirname(dirname(dirname(dirname(__FILE__)))).'/';
 if (file_exists( $classic_root . 'wp-load.php') )
  define( 'WP_LOAD_PATH', $classic_root);
  if (file_exists( $path . 'wp-load.php') )
   define( 'WP_LOAD_PATH', $path);
   exit("Could not find wp-load.php");

// let's load WordPress
require_once( WP_LOAD_PATH . 'wp-load.php');

I’m happy for any comments / ideas for a better solution….

Tagged , ,

6 thoughts on “The hassle with WP_CONTENT_URL and WP_PLUGIN_DIR

  1. Jeremy Bicha says:

    I’ve yet to move my wp-config.php or wp-content files from the default location because I’m not sure that various WordPress plugins won’t get terribly confused. Maybe in a few months…

  2. [...] you update photoq. Sorry, there just is no other solution to this right now (If interested see for a discussion of this) Posted in blog, iq2, photoq, [...]

  3. Will says:

    Was this ever updated?

    Why not just pull the WP_SITEURL from the wp-config.php file if it’s set there? If it’s not, then the default would be the value from the db.

  4. Jeremy says:

    My file structure works like so:

    /content (my wp-content folder as defined in the local-config.php)
    index.php (Points to the boostrap in the wp folder)
    /wp (clean subversion controled WP folder – nothing in here changes! [accept .htaccess sometimes])

    For some reason no matter what I do I can’t get the flashuploader in the nextgen gallery plugin to upload. my ngg_config.php looks like this:

    Line 14: $path = dirname(__FILE__) . ‘/wp/’; // It should be end with a trailing slash

    Uploading without the flash works fine – everything else works fine… but with flashuploader enabled I get a (no pun intended) flash of an error message saying it can’t find wp-load.php.

    Somehow the WordPress team handles this fine with their normal uploader… Why can’t you use the same strategy? Do you have any idea how I can fix this problem?

    Thanks, Cheers,

  5. Jeremy says:

    Oh yeah and for the record… I’m not sure what I gain by having my directory structure organized this way. I keep all of my project under version control from the root level (using git). At least this way I’m not putting WP code in my repository (it’s managed as a submodule) and yes, it’s a bit of a pain every time wordpress is updated… but this way keeps my code repository smaller and cleaner. Other then that I’ve not really run into TOO much hassle with other plugins. Typically if it’s a good plugin then you don’t have problems, I only use good plugins ;) – like NextGen Gallery

  6. Jeremy says:

    So I found the problem… I have to set $path to the ABSOLUTE server path… I wonder why this other cleaner version didn’t work?

Comments are closed.