Author Topic: Passing additional parameters to payment processor back ends (Read 9607 times)

Donald Lobo · August 31, 2009, 05:00:15 pm

how about modifying the singleton constructor to do this:

self::$_singleton = eval( 'return ' . $paymentClass . '::singleton( $mode, $paymentProcessor );' );
self::$_singleton->setForm( $form );

And add the below to CRM/Core/Payment.php

Code: [Select]

   protected $_form;

   function setForm( &$form ) {
      $this->_form =& $form;
  }

  function &getForm( ) {
     return $this->_form;
  }

lobo

torenware · August 31, 2009, 05:20:38 pm

Now that I understand that the singleton is a processor object, I see that you're right, that would work.

I see also that you want the form object writable, which is fine as well.

torenware · August 31, 2009, 06:07:26 pm

I've posted the new 3.0 patch.

There are two corner cases (UserDashboard, and BaseIPN) where no form object is available. Currently, the hook won't get called in these cases (hopefully), but for now, it's necessary for the user of the getForm() call to check before treating the object returned as a descendant of CRM_Core_Form -- it will not be so in these cases. Something _is_ passed in both cases (the page in the first case, an empty array in the other), so no error will occur when the singleton is created.

See the JIRA issue for the new patch.

dmccarney · August 31, 2009, 07:08:22 pm

FYI:

It appears that the patch applies successfully on a 2.2 installation. Below is my patch log. There were two failures but they both make sense: hook.php was previously patched from ver 1 of your patch, and Moneris.php in my installation is still pretty hacked up from the logging I was doing. A stock 2.2 should have no issues.

Thanks again! Going to see if I can't get my use-case working now.

Code: [Select]

patching file CRM/Event/Form/Registration.php
Hunk #1 succeeded at 251 (offset -91 lines).
patching file CRM/Event/Form/Participant.php
Hunk #1 succeeded at 194 (offset -7 lines).
Hunk #2 succeeded at 867 (offset -58 lines).
patching file CRM/Event/Form/Registration/Confirm.php
Hunk #2 succeeded at 454 (offset -20 lines).
patching file CRM/Event/Form/Registration/Register.php
Hunk #1 succeeded at 423 (offset -142 lines).
Hunk #2 succeeded at 587 (offset -172 lines).
patching file CRM/Utils/Hook.php
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file CRM/Utils/Hook.php.rej
patching file CRM/Core/Payment.php
Hunk #1 succeeded at 54 (offset -12 lines).
Hunk #2 succeeded at 65 (offset -12 lines).
patching file CRM/Core/Payment/Dummy.php
Hunk #1 succeeded at 50 (offset -1 lines).
patching file CRM/Core/Payment/PayPalImpl.php
Hunk #1 succeeded at 213 (offset -3 lines).
patching file CRM/Core/Payment/Moneris.php
Hunk #1 FAILED at 105.
1 out of 1 hunk FAILED -- saving rejects to file CRM/Core/Payment/Moneris.php.rej
patching file CRM/Core/Payment/AuthorizeNet.php
Hunk #1 succeeded at 79 with fuzz 2 (offset -1 lines).
patching file CRM/Core/Payment/BaseIPN.php
Hunk #1 succeeded at 641 (offset -7 lines).
patching file CRM/Member/BAO/Membership.php
Hunk #1 succeeded at 899 with fuzz 1 (offset -46 lines).
Hunk #2 succeeded at 993 (offset -50 lines).
patching file CRM/Member/Form/MembershipRenewal.php
patching file CRM/Member/Form/Membership.php
Hunk #1 succeeded at 91 (offset -4 lines).
Hunk #2 succeeded at 692 (offset -74 lines).
patching file CRM/Contribute/BAO/Contribution/Utils.php
patching file CRM/Contribute/Form/Contribution/Confirm.php
patching file CRM/Contribute/Form/Contribution/Main.php
Hunk #1 succeeded at 871 (offset -33 lines).
patching file CRM/Contribute/Form/ContributionBase.php
Hunk #1 succeeded at 291 (offset 8 lines).
patching file CRM/Contribute/Form/Contribution.php
Hunk #1 succeeded at 205 (offset -5 lines).
Hunk #2 succeeded at 878 (offset -52 lines).
patching file CRM/Contribute/Page/UserDashboard.php
Hunk #1 succeeded at 99 (offset 10 lines).
patching file drupal/civitest.module.sample
Hunk #1 succeeded at 454 (offset -48 lines).

- Dan

torenware · August 31, 2009, 07:21:30 pm

Dan,

One thing to test for when you do this.

There are a couple of (rather obscure) paths where the object returned from getForm() is not a form object.

You may want to try something like this, so we can determine if this is a real problem or not:

Code: [Select]

$form = $processor->getForm();
if (!is_object($form)  or !is_subclass_of('CRM_Core_Form')) {
  error_log('This form object is not a form object !');
  //consider writing the trace to a file as well...
}

My guess is that the paths in question never lead to doDirectPayment(), but I don't really know this for sure.

CiviCRM Community Forums (archive)

News:

Author Topic: Passing additional parameters to payment processor back ends (Read 9607 times)

Donald Lobo

Re: Passing additional parameters to payment processor back ends

torenware

Re: Passing additional parameters to payment processor back ends

torenware

Re: Passing additional parameters to payment processor back ends

dmccarney

Re: Passing additional parameters to payment processor back ends

torenware

Re: Passing additional parameters to payment processor back ends