This module is structured in such a way that backporting to Drupal 6 wouldn't be extremely painful (as, fortunately, is often the case with library modules). This is especially true since it doesn't use Libraries API.
Opening this issue because I might wind up doing it. I'm first just going to try and tailor Ubercart Stripe to my use case, but it looks like I have to write so much code I might as well use code that is already out there, particularly for Stripe.js integration.
...so yeah, I suppose I actually am going to backport this. Just from having to add public key fields and integrate Stripe.js alone, I can already see it's time better spent. And then hopefully other people secretly waiting for it will improve it.
Comments
Comment #1
wizonesolutionsAlso asked the Commerce Stripe maintainers if they plan to use this. That'd motivate me even more because eventually my site is going to be on D7. See #1533480: Plans to use Stripe module?
Comment #2
markie commentedThere can't be a backport of the commerce_stripe module because there's no D6 version of Drupal Commerce. Now if we got an UberCart payment method created, that would probably need a D6 version
Comment #3
wizonesolutionsmarkie: This issue is filed under the Stripe API module. I wasn't suggesting porting Commerce Stripe to D6. Ubercart Stripe already exists, but it doesn't implement Stripe.js. That's my motivation for porting this library module, which *does* already support generating the form and storing the API keys.
Comment #4
wizonesolutionsAlright, completed the backport. It works fine. API keys can be saved, and the test form works. I made some tweaks to make things better - most notably, removing name elements from form elements so nothing will ever be sent to the server even if JS is off and removing a defunct hook_theme call that was coincidentally and artistically commented out, but that when commented in gave me an untraceable WSOD.
I've attached the files here zipped for easier review, but really if you can just fetch the branch from my sandbox and use that, that'd probably be easiest. I'm also willing to be at least a passive co-maintainer on the Drupal 6 version...hook me up and I can commit it myself :)
Sandbox instructions: http://drupal.org/node/1533594/git-instructions/6.x-1.x/nonmaintainer
Comment #5
pbuyle commentedSorry for the very long delay, the module is been mostly unmaintened until recently. Hopefully things will be a little smoother now as mmilano and I are working more actively on it.
I can speak for mmilano, but I cannot commit to work on a D6. So if there is still interest for a D6 port, we would probably need a D6 maintainer. wizonesolutions are you still interested?
The D7 version of the module has been severely reworked to use the Libraries API (#1967094: Integration with the Libraries API) and provides form helper as element type using
hook_element_info()(#1971058: Provide payment form element through hook_element_info()).To keep the D6 version as much as possible in sync. with the D7 version, I would prefer to see these changes backported to D6. Libraries API is available for D6 (although only in version 1.x) , and
hook_element_info()used to behook_elements()(see https://drupal.org/node/224333#hook_element_info). So this should still be doable. However, the decision to backport, or not, these changes is to be made to willing D6 maintainer(s).Support for the Payment module has been added. Since Payment is not available for D6, it cannot be backported. This should not prevent a D6 port of the core Stripe module.
Comment #6
wizonesolutionsNah, at that time I switched to
uc_stripewholesale but never did get it implemented and don't have time right now. So this could just be postponed or closed.Comment #7
pbuyle commentedComment #8
hamrant commentedFrom February 24th 2016, Drupal 6 no longer be supported.