Can getDonationFormInfo return custom data elements?

Cory Watson

I am working on a donation form Drupal integration whereby I use getDonationFormInfo to pull a list of fields for a form, translate the result into an HTML form in Drupal, and then use the API to submit donations back to the original LO form. The problem I'm running into is that getDonationFormInfo seems to be ignoring custom data elements being used in our forms as they are not in the API response. Does anyone know if there is a way to get custom data elements to show up in the getDonationFormInfo results?


Thanks!

Noah Cooper

There is not any way to get custom donation elements back with the API unfortunately. If you're processing donations with the API through a form which includes anything more than the standard fields of name, email, etc., you must hardcode the custom elements in the form as described in the Custom Fields section of the documentation for the donate method.

Cory Watson

Well, that's a bummer. We can't use iFrames for various reasons, so this seemed like a really good way to create 1:1 forms in Drupal. If we could pull in general page fields and custom fields through the API, it would be fairly easy to write modules or plugins for CMS's like Drupal and Wordpress to provide a seamless integration with nearly no additional work. Having to hard-code custom fields is going to make this much more complicated. Any chance this could change in the future, or is the API pretty much locked at this time?

Brian Mucha

This will seem like a crazy idea.


What if you use some jquery on an otherwise blank pagewrapper to build a roll-your-own API out of the parent donation form? I think it would be trivial to get all the input IDs on the form and build the JSON. I think it would depend on how long it takes to retrieve, donation forms are not very fast.

Cory Watson

Thanks for the input, Brian. I've actually considered that approach, but it has even more challenges than a pseudo-API approach with some hard coded custom field values. Even with a blank page wrapper, there are a lot of extraneous HTML wrapper and input elements created that would have to be parsed through or excluded within the JS. You wouldn't get the yes/no boolean on whether fields are required like you do with the API so you'd just have to guess or come up with another way to sync those. There's the load time issue you noted as LO would have to go through a full page render instead of what I assume is a much lighter weight API call. Also, you would have to hit a long and somewhat complicated public form URL instead of simply hitting the stable API URL and passing in a form ID. It just feels like a less refined approach that would be harder to standardize and more prone to break.

Brian Mucha

"You wouldn't get the yes/no boolean on whether fields are required..."


You could get each input's parent .form-content div, and then look for the presence of a .field-required span within.


I just spent a ton of time using JQuery to parse the dom of ecom, JQuery is amazing at this. I think you could probably make it work reasonably well.


Load time is the one thing you just can't fix though. I wonder what you could get it down to. Maybe you build the form out with the standard API so the user doesn't fall asleep, and then lazy load any custom fields from a second call to your RYO API.


"It just feels like a less refined approach that would be harder to standardize and more prone to break."


No doubt about that, I said it was crazy!


You can post to IDEAS, but I'd be astonished if you got a change anytime soon.