Make this module more generic [#1360218]

It would be nice if this module was more generic. For the moment there is an emphasis on the use case of 'paying to view or create content'. As an API the module should not be concerned with this, as it is the developer's task to implement specific use cases.

Some example use cases:

Pay to become a member, or a premium member
Pay to unlock a section on a website, or get additional functionality
Pay for products in an online shop
...

Imagine if all of these use cases were covered in the module, it would be a nightmare :) No single use case should be enabled by default. Having the module implemented as API-only would solve this neatly. You can provide a contrib folder with optional modules that cover a single use case, and the current pay-to-view-content would be one of them.

I understand where this is coming from, it was probably adapted from functionality that was originally made for a client website. It would be good to take a step back and evaluate how this module could serve everyone better.

In my opinion this would be great as a typical Drupal general purpose "lego block" module, especially if it could integrate with modules such as Rules and Webform.

Comments

Comment #1

aacraig commented 14 December 2011 at 11:28

That is indeed the direction the module is heading. In the future, I imagine the content view/creation functionality will be broken out into a plugin extension, and the core module will simply handle Paypal IPN (and other) transactions.

Currently, however, you can do just that and implement your own logic as necessary. There are two hooks, one called when the payment form is created, one called when the Paypal IPN message arrives from Paypal, which allow you to completely control the business logic for your transactions.

If you need to, you can also generate the form wherever you like using theme('paypal_payment_page'), though the system remains dependent on managing interactions with nodes, at this stage.

It is important that the module (or family of modules, eventually) allows for basic "just works" functionality, while exposing more functionality to those capable of extending the module through their own code.

Anyway, thanks for the input -- I agree with the idea, and am working in the direction you propose.

Comment #2

pfrenssen

Sofia

commented 14 December 2011 at 21:38

Yes that was the motivation for this issue. I wanted to use this module as a starting point to create a redirect page that is launched from a custom checkout form submit handler. Unfortunately since the actions of viewing and creating nodes are hard coded into several parts of the module this was not feasible and I ended up coding my own solution. Functions that eg generate the Paypal buttons or IPN urls take parameters such as $op and $bundle which make a lot of sense when getting paid access to content types but were not applicable in my case since I was processing a custom shopping cart.

Comment #3

rooby commented 20 April 2012 at 04:41

+1 for this. After reading the name of the module that is what I first assumed it was.

In my case I can massage my spec a little to suit what the module provides but it would be even better if there was more flexibility.

I would probably be able to spare a little spare time to help out if there were tasks that could be farmed out or just for testing or whatever.

Comment #4

aacraig commented 21 April 2012 at 08:15

This is definitely a top priority for me, but I am at the end of a large project and won't have time for this for a couple more weeks.

I don't think this is a small job. We're talking about a complete rewrite, because the current version is intimately tied to node management.

If someone gets to it before me, great. Otherwise, I'll have time after 15 May 2012.

Comment #5

aacraig commented 27 May 2012 at 08:48

Version:	7.x-1.x-dev	» 7.x-2.x-dev
Assigned:	Unassigned	» aacraig

I have just created the version 2 branch of this module, which addresses the concerns in this issue. Please checkout the dev version (a first stable version should be ready by the end of May 2012) for testing and feedback.

I'll leave this issue open until the stable version is out and has been tested.