Title: Issue with wp-load
Last modified: August 21, 2016

---

# Issue with wp-load

 *  Resolved [Jay McPartland](https://wordpress.org/support/users/jonmcpartland/)
 * (@jonmcpartland)
 * [12 years ago](https://wordpress.org/support/topic/issue-with-wp-load/)
 * In `includes/pardot-wp-loader.php`, the `pardot_get_wp_load_filepath` function
   makes an assumption that the wp-content folder will be contained within the wordpress
   directory. This is fine, in most cases, but for those people who move the content
   directory outside of the wordpress directory, that function will not be able 
   to locate `wp-load.php`.
    I realise that this is non-standard behaviour, but 
   I thought it best to inform you nonetheless, for good order. Cheers.
 * [https://wordpress.org/plugins/pardot/](https://wordpress.org/plugins/pardot/)

Viewing 11 replies - 1 through 11 (of 11 total)

 *  Plugin Author [Cliff Seal](https://wordpress.org/support/users/cliffseal/)
 * (@cliffseal)
 * [12 years ago](https://wordpress.org/support/topic/issue-with-wp-load/#post-4983448)
 * Moving the content directory is supported by WordPress, so it should be supported
   by this plugin.
 * Can you give me an example of a structure where this check is failing?
 *  Thread Starter [Jay McPartland](https://wordpress.org/support/users/jonmcpartland/)
 * (@jonmcpartland)
 * [12 years ago](https://wordpress.org/support/topic/issue-with-wp-load/#post-4983451)
 * Certainly. On the project I’m working on, we have it as follows:
 * docroot
    | |—–/content | | | |—–/themes | |—–/wordpress | | | |—–/wp-admin | 
   |—–/wp-includes | |—–/wp-load.php etc
 * Currently, the function to find wp-load.php traverses up the directory tree from
   the plugin directory; this prevents, of course, traversing sibling directories.
 * Many thanks
 *  Plugin Author [Cliff Seal](https://wordpress.org/support/users/cliffseal/)
 * (@cliffseal)
 * [12 years ago](https://wordpress.org/support/topic/issue-with-wp-load/#post-4983683)
 * I’ve looked into this some, and there are a few options from our side, but I 
   want to see what would help you first.
 * In this particular case, would being able to set a constant work as as stopgap
   solution? For instance:
 * `define( 'PARDOT_WP_LOAD', '/wordpress/wp-load.php' );`
 * I want to get you an update that can help without having to wait on a potential
   rewrite.
 *  Thread Starter [Jay McPartland](https://wordpress.org/support/users/jonmcpartland/)
 * (@jonmcpartland)
 * [12 years ago](https://wordpress.org/support/topic/issue-with-wp-load/#post-4983686)
 * Thanks for the response.
    When I discovered the issue, I did mull over setting
   a constant in wp-config, but I found inconsistent behaviour with supposedly predefined
   constants, which is why I ended up hard-coding the path into the loader. I did
   also look into whether WP had some predefined methodology for returning the WP
   directory (perhaps similar to `get_template_directory()`), but didn’t find anything.
 * If it’s true that there is no predefined way of returning the installation directory,
   there’s a few ways to try to find it manually, but I don’t think any of those
   are going to be foolproof.
    Since one has to set the `WP_SITEURL` constant to
   point to the wordpress installation folder (else WP will use its ridiculous `
   wp_guess_url()` function), one method might be to strip the domain from the constant,
   which would leave the installation folder name. That can then be fully resolved
   with `realpath` or similar. Something like this, for example. `file_exists(realpath(
   str_replace($_SERVER["REQUEST_SCHEME"]."://".$_SERVER["HTTP_HOST"]."/", "", WP_SITEURL))."/
   wp-load.php");` This looks absolutely horrible but, with WP_SITEURL set in `wp-
   config.php`, it’d be _somewhat_ reliable (though I am loathe to use the word).
 * Currently, I wouldn’t be able to update the Pardot plugin, regardless, since 
   I’ve modified the form shortcode to allow the addition of a custom field + value(
   re [this other thread](http://wordpress.org/support/topic/custom-field-integration-feature-request)).
   I’ve not submitted a pull request as yet as it’s not as extensive as I’d like,
   i.e. it only allows addition of one custom field.
 * Thanks
 *  Plugin Author [Cliff Seal](https://wordpress.org/support/users/cliffseal/)
 * (@cliffseal)
 * [11 years, 6 months ago](https://wordpress.org/support/topic/issue-with-wp-load/#post-4983797)
 * Hey Jon,
 * There’s a fix for this in version 1.4. I’d love your help testing it if you have
   the time: [https://github.com/Pardot/pardot-for-wordpress/tree/1.4](https://github.com/Pardot/pardot-for-wordpress/tree/1.4)
 * I’ve come up with a solution that should work that you can see in the README:
   [https://github.com/Pardot/pardot-for-wordpress/tree/1.4#the-editor-popup-doesnt-work-and-i-know-that-my-wordpress-installation-is-a-little-different](https://github.com/Pardot/pardot-for-wordpress/tree/1.4#the-editor-popup-doesnt-work-and-i-know-that-my-wordpress-installation-is-a-little-different)
 * Essentially, we had to find a way around using any constants and functions belonging
   to WordPress, because none of those are available until `wp-load.php` fires everything
   off. So, I put in a condition that looks for a custom file in the includes directory
   that lets you set a constant with the path to `wp-load.php`. This worked in my
   tests, and, though inelegant, should get the job done here.
 *  Thread Starter [Jay McPartland](https://wordpress.org/support/users/jonmcpartland/)
 * (@jonmcpartland)
 * [11 years, 6 months ago](https://wordpress.org/support/topic/issue-with-wp-load/#post-4983803)
 * Hi Cliff
 * It does the job, mostly 🙂
    The only issue with this solution (in my environment,
   at least), is on this line: [http://jon.moe/15rtu/3ldgONBd](http://jon.moe/15rtu/3ldgONBd)
   Because you’re assigning `$wp_load` to a string, its value is no longer falsey(
   in my environment, it’s set to `/Users/wp-load.php` at this point), regardless
   of whether the file exists or not. As such, line 27 will equate to true, and 
   the custom file will not be loaded. The solution, for me, was to change line 
   22 to `if ( file_exists( $filepath = "{$dir}/wp-load.php" ) ) {`, and add `$wp_load
   = $filepath;` on line 23 (above `break;`). That way, `$wp_load` remains false
   if the file doesn’t exist.
 * Cheers!
 *  Plugin Author [Cliff Seal](https://wordpress.org/support/users/cliffseal/)
 * (@cliffseal)
 * [11 years, 6 months ago](https://wordpress.org/support/topic/issue-with-wp-load/#post-4983805)
 * This is untested, but would this work for you? [https://gist.github.com/logoscreative/62658ec041e4b84392c7](https://gist.github.com/logoscreative/62658ec041e4b84392c7)
 *  Thread Starter [Jay McPartland](https://wordpress.org/support/users/jonmcpartland/)
 * (@jonmcpartland)
 * [11 years, 6 months ago](https://wordpress.org/support/topic/issue-with-wp-load/#post-4983806)
 * That would do it, yeah 🙂
    Cheers
 *  Plugin Author [Cliff Seal](https://wordpress.org/support/users/cliffseal/)
 * (@cliffseal)
 * [11 years, 6 months ago](https://wordpress.org/support/topic/issue-with-wp-load/#post-4983807)
 * Excellent. I’ll put that update in the branch, and will likely update the plugin
   today or early next week.
 * Thanks so much for testing.
 *  Thread Starter [Jay McPartland](https://wordpress.org/support/users/jonmcpartland/)
 * (@jonmcpartland)
 * [11 years, 6 months ago](https://wordpress.org/support/topic/issue-with-wp-load/#post-4983808)
 * No worries, Cliff. Thanks for sorting everything, it all happened just in time!
   🙂
 *  Plugin Author [Cliff Seal](https://wordpress.org/support/users/cliffseal/)
 * (@cliffseal)
 * [11 years, 6 months ago](https://wordpress.org/support/topic/issue-with-wp-load/#post-4983809)
 * Version 1.4 is live and includes the feature mentioned above. Thanks so much 
   for your help, Jon. Let me know if any other issues crop up with it.

Viewing 11 replies - 1 through 11 (of 11 total)

The topic ‘Issue with wp-load’ is closed to new replies.

 * ![](https://ps.w.org/pardot/assets/icon-256x256.png?rev=2995205)
 * [Account Engagement](https://wordpress.org/plugins/pardot/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/pardot/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/pardot/)
 * [Active Topics](https://wordpress.org/support/plugin/pardot/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/pardot/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/pardot/reviews/)

 * 11 replies
 * 2 participants
 * Last reply from: [Cliff Seal](https://wordpress.org/support/users/cliffseal/)
 * Last activity: [11 years, 6 months ago](https://wordpress.org/support/topic/issue-with-wp-load/#post-4983809)
 * Status: resolved