WordPress.org

Forums

Pardot
[resolved] Issue with wp-load (12 posts)

  1. jonmcpartland
    Member
    Posted 1 year ago #

    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/

  2. Cliff Seal
    Member
    Plugin Author

    Posted 1 year ago #

    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?

  3. jonmcpartland
    Member
    Posted 1 year ago #

    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

  4. Cliff Seal
    Member
    Plugin Author

    Posted 1 year ago #

    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.

  5. jonmcpartland
    Member
    Posted 1 year ago #

    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). 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

  6. Cliff Seal
    Member
    Plugin Author

    Posted 8 months ago #

    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

    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

    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.

  7. jonmcpartland
    Member
    Posted 8 months ago #

    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
    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!

  8. Cliff Seal
    Member
    Plugin Author

    Posted 8 months ago #

    This is untested, but would this work for you? https://gist.github.com/logoscreative/62658ec041e4b84392c7

  9. jonmcpartland
    Member
    Posted 8 months ago #

    That would do it, yeah :)
    Cheers

  10. Cliff Seal
    Member
    Plugin Author

    Posted 8 months ago #

    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.

  11. jonmcpartland
    Member
    Posted 8 months ago #

    No worries, Cliff. Thanks for sorting everything, it all happened just in time! :)

  12. Cliff Seal
    Member
    Plugin Author

    Posted 7 months ago #

    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.

Topic Closed

This topic has been closed to new replies.

About this Plugin

  • Pardot
  • Frequently Asked Questions
  • Support Threads
  • Reviews

About this Topic

Tags

No tags yet.