So, are you going to fix it man? I'm not going to do it. Last time I checked, the 6.x-2.x branch was still pretty broken. Yes, "just subscriptions", but most of the functionality is based on that. In the alternative, would it just be more prudent to deprecate the module in favor of Pay module.

http://drupal.org/project/pay

Comments

Patroclas’s picture

Patroclas commented

But don't abandon those of us who are actually using this module. At the very least it would be a requirement thate xisting data could be transferred.

In the absence of anything better, I have been successfully using the 6x-1.x-dev version for nearly two years for role subscriptions.

What we need is for this module to be developed properly. There is another module ( I won't mention it here because it costs) - and that will do some stuff that LM_PP won't - but having tested it, it's really not that much better for role subscription.

Also, it would be good to see a roadmap of where and when this module may get into a stable version. If one of the module maintainers want to contact me, I could offer a bounty that may help.

amaisano’s picture

amaisano commented

*Subscribing*

lyricnz’s picture

lyricnz commented

The code problems are really with 6.x-2.x. The current 6.x-1.x just suffers from lack of maintenence. :)

All feel free to step up and help! The maintainers are just suffering a lack of time, and needing to pay bills.

Patroclas’s picture

Patroclas commented

It would be useful to have a clearer statement of where the 6.x-2.x. branch is at the moment - having tested it briefly, albeit on a local test server with no live payments, there do appear to be some improvements in the functionality of role subscriptions (I don't use any other functions).

How 'broken' is it?

This really is an important module for some of us who don't need an e-commerce solution for role subscriptions. I don't have the expertise to help with coding but I did make another offer in my previous post and that still stands.

lyricnz’s picture

lyricnz commented

Well, here's how I see it.

LM Paypal was originally written as a "does everything" module, which offered a few use-cases aligned to the original maintainers requirements. It wasn't possible integrate with it, and it either did what you wanted, or it didn't. This is not a negative comment on the author, or the module, but it was really a product of the Drupal 4.6/4.7 environment. Drupal 5 support was via code-checks, without a separate codebase. For what it was, it worked fine (I used it on a few sites myself). It didn't really support custom theming, messages, emails, etc - all was hardcoded.

A couple of years ago, a few of us did a straight port to Drupal 6, without significantly reworking the module. That basically works fine too. That's 6.x-1.x.

Since then, the philosophy of Drupal site-building has changed. Nowadays, modules should be more integration-friendly (and probably do *less* themselves). Modules should provide hooks/events/triggers for other modules to react to (eg: Triggers/Actions, Rules, etc). Modules should be able to export/import their configuration. Modules should provide Views support for exposing their data. Modules should not hard-code so much, but instead provide default (and substitutable) implements for things. Modules should be 100% themable. This will allow site-builders to use the module for more exotic things, which the original maintainers never imaged.

That's what 6.x-2.x is aiming for. We first performed significant refactoring and cleanups, making the code a bit more manageable, having grown and grown over the previous years. I guess for me, the goal of the initiative was identified in #328730: Make it easier to integrate with LM Paypal. Plus, if the module supports nice integration, this should be documented properly. The availability of the maintainers has varied a lot over the last couple of years, which causes its own problems, of course.

The current roadblock, besides our lack of time to support the module (and lack of community members stepping up to help), is that a large commit/refactor was commited a year or so ago (?), which broke some of the functionality around subscriptions, which is one of the main useful points of the system. I fixed as much as I could get my head around, but am unwilling/unable to do any more until that code is fixed. Even then, I can't make any guarantees - which is why I'm not pushing this more (it's not fair to the other maintainer).

I'm reluctant to just roll back everything to before that commit, because lots of things have been fixed on top of that codebase, and the system is probably the better (but broken) for it.

So... we're stuck.

With regards offers of sponsorship/bounty - that's not really the problem. I don't do community modules to make money, and doubt that enough $ could be raised to justify my time on a pure commercial basis. That being said, I have asked my own developers to look at this module, if they have time available between their (paying) commitments. That hasn't actually happened yet (good for my business, bad for this module).

Patroclas’s picture

Patroclas commented

Thanks lyricnz - that is useful info.

Not sure if it helps me to make a decison about what to do - but that's my problem!

For me 6.x-1.x. works well as far as it goes, at least for simple role-subscriptions. As far as the discussion at http://drupal.org/node/328730, I can't add much to that as I am not a coder, but just from an end-user perspective, the two major problems are:
1. Expiring the role at the end of term (Not immediately on cancellation)
2. Rules integration to maybe allow a reminder message to be sent before a recurring payment is due.

If those are fixed, the module would have a longer shelf life. Even if [1] gets fixed in a stable version, that would be a big step along the way.