CiviCRM Community Forums (archive)

*

News:

Have a question about CiviCRM?
Get it answered quickly at the new
CiviCRM Stack Exchange Q+A site
This forum was archived on 25 November 2017. Learn more.
How to get involved.
What to do if you think you've found a bug.



  • CiviCRM Community Forums (archive) »
  • Discussion »
  • Extensions (Moderators: mathieu, totten, kasiawaka) »
  • Using payment processor vs Module extension
Pages: [1]

Author Topic: Using payment processor vs Module extension  (Read 2224 times)

dschafer

  • I post occasionally
  • **
  • Posts: 93
  • Karma: 3
    • Backoffice Thinking
  • CiviCRM version: 3.2.3 - 4.4.4
  • CMS version: Drupal 6.x, 7.x, Wordpress
  • MySQL version: 5.1.x - 5.5.x
  • PHP version: 5.2.x - 5.4.x
Using payment processor vs Module extension
May 31, 2013, 07:18:21 am
We're doing some enhancement to our Vanco payment processor extension under 4.2.x and have run into an issue.

If we define the extension as a payment processor then we can't have hooks in our extension code, there appear not to get called (so we have to deploy a drupal module, etc).

If we define the extension as module type then it does execute the process for creating the entries in the payment processor table.

Any recommendations how to proceed? Are we missing something?

We need hooks in order to alter the billing fields display for various forms and we'd like to make it uniform so the processor works on all platforms.

Donald Lobo

  • Administrator
  • I’m (like) Lobo ;)
  • *****
  • Posts: 15963
  • Karma: 470
    • CiviCRM site
  • CiviCRM version: 4.2+
  • CMS version: Drupal 7, Joomla 2.5+
  • MySQL version: 5.5.x
  • PHP version: 5.4.x
Re: Using payment processor vs Module extension
May 31, 2013, 08:28:55 am

we are phasing out the payment processor / custom search / report extension types

all extension types should be of type module, which in turn can install multiple payment processors / report / searches. Also helps that the module can then trap hooks and alter civicrm behavior

lobo
A new CiviCRM Q&A resource needs YOUR help to get started. Visit our StackExchange proposed site, sign up and vote on 5 questions

dschafer

  • I post occasionally
  • **
  • Posts: 93
  • Karma: 3
    • Backoffice Thinking
  • CiviCRM version: 3.2.3 - 4.4.4
  • CMS version: Drupal 6.x, 7.x, Wordpress
  • MySQL version: 5.1.x - 5.5.x
  • PHP version: 5.2.x - 5.4.x
Re: Using payment processor vs Module extension
May 31, 2013, 09:46:09 am
OK - so if well change it to type module and see how that goes.

Thanks

totten

  • Administrator
  • Ask me questions
  • *****
  • Posts: 695
  • Karma: 64
Re: Using payment processor vs Module extension
May 31, 2013, 12:25:03 pm
To handle
Quote from: dschafer on May 31, 2013, 07:18:21 am
If we define the extension as module type then it does execute the process for creating the entries in the payment processor table.

For some background on the technique which addresses this, see: http://civicrm.org/blogs/totten/api-and-art-installation

For an example of a "module" which uses this technique to insert a new row in the "civicrm_payment_process_type" table,  see:

https://github.com/drastik/civicrm_stripe/blob/master/extension-4.2/com.drastikbydesign.stripe/stripe.php#L117

xavier

  • Forum Godess / God
  • I’m (like) Lobo ;)
  • *****
  • Posts: 4453
  • Karma: 161
    • Tech To The People
  • CiviCRM version: yes probably
  • CMS version: drupal
Re: Using payment processor vs Module extension
May 31, 2013, 02:25:29 pm
Hi,

We are trying this technique (the mgd way)
https://github.com/Project60/sepa_dd/blob/master/CRM/Core/Payment/SEPA.mgd.php

But it doesn't work reliably. I has worked on some install/version, but not on others. I'm pretty sure it's something obviously wrong on the way I have written the page, but we can't figure it out.

Another (or related?) problem is that when you de-install the extension while a payment processor still exist, it can't remove the payment processor type and leaves civi in a corrupted state (or so it seems). Moreover, is this possible that some caches aren't updated?

If you have suggestions, we are confused about what is or isn't broken and what to do to make it work reliably.

X+

 
-Hackathon and data journalism about the European parliament 24-26 jan. Watch out the result

totten

  • Administrator
  • Ask me questions
  • *****
  • Posts: 695
  • Karma: 64
Re: Using payment processor vs Module extension
May 31, 2013, 02:42:11 pm
Quote from: xavier on May 31, 2013, 02:25:29 pm
But it doesn't work reliably. I has worked on some install/version, but not on others. I'm pretty sure it's something obviously wrong on the way I have written the page, but we can't figure it out.

Another (or related?) problem is that when you de-install the extension while a payment processor still exist, it can't remove the payment processor type and leaves civi in a corrupted state (or so it seems). Moreover, is this possible that some caches aren't updated?

The two could be related -- e.g. if the uninstall left things in an inconsistent state, then a subsequent re-installation might hit a conflict (either in civicrm_managed or civicrm_payment_processor_type).

Have you determined whether any of these variables correlate with the successful or failed installations (either to rule-out or rule-in the variable's significance); if so, what is the correlation:
 * CiviCRM version (4.1, 4,2. 4.3, master)
 * PHP version (5.2, 5.3, 5.4)
 * Previous installation (e.g. it installs on a fresh CiviCRM instance but fails if the payment processor was previously installed by other means)

Lastly: What error do you get when installation fails?
Pages: [1]
  • CiviCRM Community Forums (archive) »
  • Discussion »
  • Extensions (Moderators: mathieu, totten, kasiawaka) »
  • Using payment processor vs Module extension

This forum was archived on 2017-11-26.