Drupal 7 Port?

Before we can start a Drupal 7 port, http://drupal.org/project/pay needs to be updated for Drupal 7, since this module depends on it.

I ported the Pay module this week (see #998736: Drupal 7 porting) and while it's still an initial port I needed this module (and pay_realex payment gateway) to actually test what I was doing, so here's a working port of webform_pay too. However, it's kinda dependant on the pay module not being refactored so use at your own risk.

subscribe

I understand that pay module should be ported first, but FWIW, this works well for me together with Stella's pay port here: http://drupal.org/node/998736#comment-4943480.

Only thing so far have been some PHP notices:

Notice: Undefined index: paid in webform_pay_webform_component_presave() (line 57 of /Users/nicolashaase/Sites/d7dev/sites/all/modules/webform_pay/webform_pay.module).
Notice: Undefined index: pxid in webform_pay_webform_component_presave() (line 58 of /Users/nicolashaase/Sites/d7dev/sites/all/modules/webform_pay/webform_pay.module).

here's an updated version which may or may not fix that error. If it doesn't, can you provide the steps on how to reproduce them?

Thanks Stella, I'll try it out. I wasn't really too worried about them - looking at the code they should have been there in D6 as well, so maybe that can be dealt with once the D7 port is done.

Subscribe - I have some comments coming soon...

I've reviewed this patch and made an initial branch and commit of the changes that seem unquestionable. That way at least we'll get some forward movement on this, even if the 7.x-1.x branch doesn't actually work (I don't think it will, based on what I've committed).

A few changes in here that looked unnecessary or just outright incorrect:

    if (!$includes_loaded) {
      $includes_loaded = TRUE;
      $path = drupal_get_path('module', 'pay');
      module_load_include('inc', 'pay', 'includes/handlers/pay');
      module_load_include('inc', 'pay', 'includes/handlers/pay_method');
      module_load_include('inc', 'pay', 'includes/handlers/pay_form');
      module_load_include('inc', 'pay', 'includes/handlers/pay_method_gateway');
    }

Webform Pay module should have no business needing to load these files manually. Auto-loading of classes is the only reason we have that silly files[] = 'example.inc' in our .info files. I don't think these should be necessary, or at the very least Pay module should be responsible for it, not us.

In webform_pay_after_build(), this new code was added:

  // Remove the pay_submit and webform_client_form_submit submit handlers as
  // they're replaced by webform_pay_submit.
  $client_form_index = array_search('webform_client_form_submit', $form['#submit']);
  if ($client_form_index !== FALSE) {
    unset($form['#submit'][$client_form_index]);
  }
  $pay_submit_index = array_search('pay_submit', $form['#submit']);
  if ($pay_submit_index !== FALSE) {
    unset($form['#submit'][$pay_submit_index]);
  }

I don't know what this code does. Perhaps it's code from #1009446: Validate credit card numbers against the payment gateway in form_validate()?

In function _webform_pay_component_value() we have this code:

  if (!empty($values[$component['cid']])) {
    return $values[$component['cid']];
  }

Which I think should actually be handled by a different change, as done in #1222634: Multiple page forms broken for Webform Pay by API change in Webform.

Other changes:
- I rewrote webform_pay_node_load() to match the approach used in webform.module. This uses a single query for all nodes rather than one query per node.
- I backported all the obvious wins and documentation changes to the D6 version for code consistency.

sub - nothing new on this other than the initial ports?

No, still waiting for Pay module to stabilize. At this point I'm questioning the whole approach and I might recommend looking into other Webform payment solutions (as I'm doing that also).

do you mean the approach of webform_pay or the pay module? I'd be interested to hear how you would build multi-step donation forms without webform, webform_pay and pay module. I couldn't find a better alternative.

I'm still interested in handling payments with Webform, but I'm not sure Pay module is a good approach. The generic abstraction layer makes Webform integration rather difficult and solving problems like #1038436: Handling of failed transactions is extremely difficult. I think this may require either A) an payment API built specifically for Webform or B) forgoing an API and writing implementation for payment directly against the payment services.

The promise of Pay module being a generic framework for lots of modules to use hasn't really come through IMO. Considering it can't be used with either Ubercart or Commerce, and I've never used it besides with Webform Pay, it seems like a layer that is getting in the way more than helping multiple modules consolidate duplicate code.

@quicksketch Did you find other webform payment integrations?

No, I haven't investigated it yet. Last time I checked the landscape was quite bleak (which is why I originally wrote Webform Pay). Next time I need payments with Webform I'll probably write a replacement module for Webform Pay, but that probably won't be for a while.

There's now an alpha version of the Pay module.

However, there's still an issue with the dev version of webform_pay when you have a multi-step webform. Clicking the back button or submitting the form gives this error:

Fatal error: Class 'pay_method_gateway' not found in sites/all/modules/pay_realex/pay_realex_method_gateway_remote.inc on line 7

I know the error is about the pay_realex module but the line that is failing is the class pay_realex_method_gateway_remote extends pay_method_gateway { one. Maybe that's why I had those lines in that you removed in comment #8 above? Can't rem exactly why I had them in now, but it was for an error something like this.

Note: the pay component is on the last step of the form as recommended.

If you are interested in processing payments in Drupal 7 webforms, then you may want to take a look at Payment for Webform. It takes a similar, yet slightly different approach than Webform Pay.

Excellent, how timely @Xano. I was about to look into porting because we need payments of some kind in the immediate future for a client project, but I'm more than happy to pursue alternatives. Thanks for the heads up.

That way at least we'll get some forward movement on this, even if the 7.x-1.x branch doesn't actually work (I don't think it will, based on what I've committed).

Just a note, I've transfered ownership of this module to @jlyon. There actually *is* already a Drupal 7 port, but it's not listed on the project page. It is available as a Git checkout: https://drupal.org/node/907538/git-instructions/7.x-1.x

Much to my surprise, it looks like the code I wrote over 2 years ago actually worked out-of-the-box with Pay module. AFAIK they work fine together already, as well as the D6 version did at least. Overall though I'm still disappointed with Pay module's performance. We've had D7 out for 3 years and it *still* doesn't have a stable release ("alpha1" is as far as it got).

Short coordination effort advertisement: Authorize.net and Stripe support is being developed for Payment. If that is what you want, please consider helping out with Payment for Webform. We could use the help of someone with a bit more Webform knowledge to solve an issue with the Webform integration.