Jay McPartland

That would do it, yeah 🙂
Cheers

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!

Hi Cliff

Thanks for sorting this (and the other things noted on the other threads).
I’ve cloned 1.4, but it won’t allow me to authenticate, so I’m currently unable to test the new functionality. User name & password are definitely correct (I even tried changing my password), and the API key was a copy/paste from the Pardot dashboard. I’m an account administrator – should that be sufficient, or would I need to use the account owner’s information (it’s been a while!)?

Cheers!

We do have forms that are set-and-forget, too, but the majority do need the query string. Perhaps ask your API devs for an endpoint that returns just the URL of a form requested by ID? 😉

That’s pretty much what I’ve implemented currently, yes. My concern with that (and why I didn’t submit a PR) is that I wasn’t sure it was the most user-friendly way in which to allow the user to add custom fields. By that, I mean that not all Pardot users may understand what a query string is, or how to build one, which is why this plugin is likely very important to their workflow.
I have been pondering whether allowing a comma/colon separated list of key/value pairs might be more beneficial to some users, using that to build the query string in the back end. In that case, users only have to worry about what their custom fields are called, and what values they wish to pass to each.
What are your thoughts on that?

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