Rendering a Civi Contribution page in a drupal page

[mpnordland]

Hey all, I'm making a specialized drupal module that uses the civicrm api to create paid memberships. I want to embed a contribution page, like what webform_civicrm does, but I don't want to use that module for two reasons. First, the form that I use needs to deliver information about the membership via ajax. I do this using server side rendered content so that I have a graceful degradation without JS. Second because I want this site to be deployable without copying the database as per http://dcycleproject.org/ . I have multiple environments to deploy it in and having to move around stuff in the db is error-prone. I'm hoping for a solution that does not involve me cobbling several modules together to get something like I want.

[mathieu]

Does webform_civicrm have JS requirements that do not have graceful degradation? You could probably add custom code that hooks into it, for the membership info.

Otherwise, you can code a completely custom Drupal module, but I don't think there's a CiviCRM API for the actually credit card processing. You might want to check how webform_civicrm does that.

[Coleman Watts]

I'll answer your question, but also speak to the potential advantages of using webform_civicrm rather than going it alone.

1) I would say that webform_civicrm embeds a contribution page "hackishly." I wrote the code as cleanly as I could but ultimately fell back on some cheap tricks to get the job done. I took advantage of the fact that CiviCRM loads the contribution page's billing fields via ajax (this is because the user is allowed to select from multiple payment processors on-the-fly) and so I wrote some js for webform_civicrm that mimics the call to load those billing fields. So no graceful degradation there. See js/webform_civicrm_payment.js.
Post-processing is done by calling the civicrm contribution:transact api. See wf_crm_webform_postprocess::submitPayment(). Pay attention to the code comments -- they'll help.

2) So some arguments to use webform_civicrm instead of striking out on your own would be:

• Someone else maintains the code for you, and updates the integration when it no longer works with the latest version of CiviCRM
• A webform can be deployed from code. See the node_export module.
• A webform can make a perfectly serviceable membership sign-up form. If you require additional content to be loaded via ajax why not write a module for that only - it would be a much more manageable chunk of code than doing everything. And since the contribution form can't be embedded without ajax anyway, screw progressive enhancement. No one really cares about that these days anyhow.

[mpnordland]

Well, I need JS fallback. So, I'll look at submitting the payments using my own form. Or I'll just use a webform for the payment parts. The form for selecting a membership isn't the one that would be used for creating one.

[Coleman Watts]

Well, I need JS fallback. So, I'll look at submitting the payments using my own form. Or I'll just use a webform for the payment parts.

Remember that webform-civicrm payment fields will not work without js. So I guess the thing to do would be to use Drupal FAPI to add the credit card fields to the form and then call the CiviCRM api to process it.

[Chris Burgess]

mpnordland - I'd be interested in chatting further about what you need to get this done, especially WRT pushing out the API functionality needed to deliver a decent CiviCRM contribution / membership form whilst avoiding HTML_QuickForm.

Some notes I wrote up a year ago when thinking about this (unfortunately the solution that time around was to throw more JS over the top of existing CiviCRM forms, wah!).

If there's an opportunity to extend CiviCRM API to provide the tools needed for your and my goals here, let's talk

[mpnordland]

So as it turns out, I did a sort of comparison of the two methods and talked to my supervisor about it. He said that since much of the rest of the site depends on JS, it wouldn't be a problem to do it here. And because the webform method had us doing less we should go with that. I have a hidden existing contact field that must be filled so I added a hook_form_alter implementation that checks if it's set. If not, it redirects to a page where it can be set. For some reason checking the required box in the webform settings didn't work, and adding a validation handler didn't work either. I also added a hook_cron to clear out submissions since all this form does is create a paid membership. No data is collected that we would conceivably want to keep around.
My issues with this setup: 1) drupal_goto in hook_form_alter. It's a code smell. 2) Still trying to figure out how to create the webform node in the .install file.

Chris Burgess:
What would make this simple would be a way to get a representation of the contribute form for a payment processor from the api. Then you just pass the results from that to another api call and it does verification and all that for you. Maybe you would still need to do stuff like relationship and membership creation, but mainly getting that payment form and then handling the processing. I'm still quite unfamiliar with the civi api. Or just scrap getting the payment form, and just handle the validation and transaction in one call. I'd be glad to talk with you about making this a better, cleaner solution.