Custom field integration (feature request)

Hey Jon,

I’m more than happy to review a pull request on GitHub. ??

A follow up thought here: with you obviously having the ability to code custom solutions, why not grab the embed code an inject it into the site with whatever string you want? You could append it to the_content, or build your own shortcode (i.e. [request-submissions-form]).

I’m curious as to how adding this functionality to the main shortcode provides value to someone needing a solution like you mentioned in the Idea Forum.

I did think about implementing my own solution from scratch but, from the client’s perspective, having the Pardot integration as it stands in the current plugin is much preferable to remembering a custom shortcode’s syntax. By simply extending the base implementation offered by the plugin, I’m saving myself time and effort, as well as maintaining the client’s user experience at no extra cost to them (from time spent by me).
When I submitted the feature request, I did so under the assumption that there will be a decent number of Pardot clients running WordPress (hence the existence of the plugin in the first instance), and that many of them would like the ability to implement custom fields. I’ll be surprised if I’m the first to require such functionality! ??

Oh, not at all, but that’s why I asked. In most cases, it’s just as easy to ‘set it and forget it’ with a specific form or two, especially considering our implementation in the plugin relies on our API, which returns a fully-formed iframe element.

Anyway, that should be as easy as adding another shortcode attribute that accepts a query string (i.e. ‘mycustomvar1=yes&mycustomvar2=no’) and appending it to the src. That aligning with your approach?

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?

It may or may not be the most friendly way, but it is certainly consistent with what a user has to do currently to achieve the same result. Consistency with that supported method can be helpful, and I’d worry that changing the format (from query string to CS) would actually be more confusing.

Fair enough. I suppose that, as long as the functionality implemented is documented on the Pardot site’s KB, users can figure it out.
Thanks for looking into this.

Hey Jon,

I’ve added the ability to do this in two ways in version 1.4, and I’d love your help testing it: https://github.com/Pardot/pardot-for-wordpress/tree/1.4

First, there’s now a querystring parameter that you can include in the form shortcode that will append an arbitrary string to the end of the form URL: https://github.com/Pardot/pardot-for-wordpress/tree/1.4#form-shortcode

Secondly, you can now filter the entire embed code for a given form: https://github.com/Pardot/pardot-for-wordpress/tree/1.4#filters

This should cover your use cases (and others’), so I’m hoping this solves it for you. I’ll push this live after more testing.

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!

Nothing’s changed with authentication. Were you able to log in with those credentials on that installation before? If so, have you tried clicking “Reset All Settings” and trying again?

Not on this installation, no. I’ve tried resetting my settings repeatedly. I’ll see if I can’t get someone else with access to that Pardot account to try authenticating, I guess, in case it’s a problem with my account.

Sure, give that a shot. If not, it might be something in that site’s environment that’s keeping it from allowing that sort of authentication (i.e. having cURL disabled). As well, ensure IP security in Pardot has your server whitelisted or is off.

Thanks. It worked with the third account I tried! ??

Version 1.4 is live and includes the feature mentioned above.