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.