The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Notice: Undefined variable: form in activity_user() (line 431 of activity.module).
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | php_notice_activity_user-1426546-1-D6.patch | 494 bytes | pdrake |
Comments
Comment #1
pdrake commentedPatch fixes this notice.
Comment #2
morbus iffNot applicable to 7.x-3.x and the 6.x branches are no longer being maintained.
Comment #3
pdrake commentedWould it be possible for me to become a maintainer for the purpose of maintaining the 6.x branches (specifically, to address bug fixes & security fixes)?
Comment #4
morbus iffAt this point, if the 6.x branch comes alive again, it will be as a backport of 7.x-3.x, *not* as continued maintenance on the 1.x and 2.x lines.
Comment #5
pdrake commentedSo, 6.x-1.x and 6.x-2.x are abandoned and maintenance / bug fixes on these branches will not be allowed? It seems odd to refuse maintenance of the branches that (according to d.o module statistics) are used in over 97% of Activity Stream module installs.
Comment #6
morbus iff@pdrake: The 1.x branch is over 4 years old, the 2.x branch is just a weakly-renumbered 1.x branch with slightly more features which never saw an official (non-beta) release. Drupal 6 was also released 4 years ago, and Drupal 7 has been out for over a year. Drupal 7 promotes its own degree of "always moving forward" by never caring about backwards compatibility. My modules and mentality are the same - I only maintain for the latest core version of Drupal. The original maintainer (Adam Kalsey) and I both agreed not to maintain the 6.x-1.x or 2.x branches for anything but security fixes, of which none have been reported. Quoting a 97% statistic is a bit disingenuous, as there's never been any other official release for anything *past* 6.x.
See also http://drupal.org/node/1589242 - I'm not just picking on you ;)
Maintaining 1.x or 2.x, instead of focussing on a 6.x-3.x backport, just keeps entropy around.
If you'd like to expend the effort, it should be on a 3.x backport and/or an upgrade path from 1.x or 2.x.
Comment #7
morbus iffComment #8
pdrake commentedI certainly understand the desire to move forward and might consider assisting with a 6.x-3.x backport if/when I have time, but it does (IMO) make sense to continue to provide basic bug fixes for the 6.x-1.x and 6.x-2.x branches if they are widely used and someone is willing to step up and take responsibility as maintainer of those branches. I don't feel that quoting the official module Usage Statistics is disingenuous as I clearly stated that was the source of the data. Perhaps inaccurate (which is a judgement about the quality or completeness of the data), but not disingenuous (which is a judgement about my motives and truthfulness). That said, it seems clear that you still disagree with my position after I have stated my case, so I'll drop the subject and will continue to provide any bug fixes via closed (won't fix) issues in the queue, unless there are objections to me doing so.
Comment #9
akalsey commentedIf you can get patches reviewed and tested by others for the 6.x branch, I'll commit them. But only critical bug fixes and security patches. I don't want to risk the aim or API of the module diverging from how it is now. I'd consider PHP notices spewing to the screen a critical bug fix, as it prevents the module from being used in the manner it was intended.
Comment #10
pdrake commentedReturning this patch back to "needs review" per the latest response.
Comment #11
christianchristensen commented:+1: