Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.I'm looking at #871116: Drupal 7 port (userpoints_flag).
Despite what the project page says, the version of userpoints_flag in git still has a core 6.x version in the .info file.
I also noticed #1354290: Offering to co-maintain userpoints_invite
Is the roadmap for this project to separate the modules into individual projects as new maintainers volunteer?
While I can think of a dozen reason not to, was there a technical reason for keeping the modules in a single project?
Comments
Comment #1
berdirThis project was and is basically a place where all kinds of modules where thrown in that used userpoints in one way or another. I think it was initially even thought to be more like a set of examples to build upon rather than complete modules. Most are rather old (Drupal 5 or even older) and have been ported multiple times to newer core versions. Most of the modules in the 6.x branch are actually completely broken from what I saw when porting them.
I attempted to properly port them to Drupal 7 and fix them up but it's a large list of modules and I haven't found much time to continue with that process. All I can do is review patches and I tend to be picky (worked too long on core) so people often give up after posting an initial patch.
I have left the unported modules in the 7.x branch with the idea that people interested in them would attempt to port them and it's easier to review the patches but that conflicts with the bug in project.module that overrides the core value and so I'm getting tons of bug reports about broken (obviously) modules. Not sure what to do.
And yes, if someone is interested taking over a specific module, I'm more than happy to give it away. It's not exactly the official roadmap though. It's however very unlikely that this project will ever see a stable version, there's just too many different modules that would need to be ported, fixed, improved and tested.
Comment #2
kreynen commented@Berdir That's what I thought. I'd like to move userpoints_flag to a new project (w/ your blessing of course). I've already altered it for a client who can afford to subsidize any time I'd spend supporting it. The change is minor. I added an hours field to the limit so that it doesn't assume 24 hours(86400 seconds) in _userpoints_flag_within_limit. This still allows the limit to function exactly as it did before, but also allow longer or shorter limits as well.
The biggest issue I have with delivering this to a client as a patch within userpoints_crontib is it looks like a hot mess in the module list AND it would be nearly impossible for them to know when they need to update since all the modules in the project would get the same release tag and any commit to any module in the project rolls a new sandbox release.
It's also worth noting that Manhattan Neighborhood Network is in the process of upgrading their D4.7 install where @jredding had configured userpoints in one of his previous lives. The current code is a HUGE improvement and the 2.x branch of userpoints and it look very promising. Thanks for keeping this project moving forward!
Comment #3
berdirSure, go ahead. Feel free to also take over the 6.x code (and the open issues), similar to what was done with the invite module.
Give me the URL and I'll put it on the project page.
I assume that we can mark the issue as fixed then, feel free to re-open if you think otherwise.
I'm interested in any kind of contributions/help for 7.x-2.x, I'm also open for different ideas and things to do. I'm still planning to reach the goals outlined in the roadmap but it's going to take a while as I have a bunch of other large projects that are more urgent at the moment like Simplenews and the Translation Management Tools.
Comment #4.0
(not verified) commentedadded [] to issues