It is time to move poll module from core. It cannot be developed in any proper way as long as it is in core and its inclusion in core is holding it back. Why? Because it is not destined to be a standalone module, but rather part of a larger set of modules, most likely including Views and Voting API. No development on making poll module more generic, more flexible, more modular or more powerful can happen as long as it is core because it will probably involve making dependencies on one or more of these other modules. As long as they are not in core, this cannot happen, thus nobody will bother working on poll module.
[edit - I keep updating this next line as time goes on]
Removing poll module is a good first step towards making 4.8 5.0 6.0 7.0 8.0 an even slimmer, more flexible framework.
Poll module development has fallen significantly behind the rest of Drupal and is not really the quality that we want to present to the world when we say "Drupal core". Getting it out of core is the best way to guarantee its survival.
Comment | File | Size | Author |
---|---|---|---|
#151 | 61285-151-remove_poll_from_core-MAINTAINERS-etc.patch | 124.18 KB | adammalone |
#151 | 61285-151-remove_poll_from_core.patch | 119.7 KB | adammalone |
#147 | 61285-147-remove_poll_from_core.patch | 119.7 KB | adammalone |
#144 | 61285-144-remove_poll_from_core.patch | 119.75 KB | adammalone |
#135 | 61285-135-remove_poll_from_core.patch | 118.98 KB | adammalone |
Comments
Comment #1
Robin Monks CreditAttribution: Robin Monks commented+1
Robin
I ♥ Bugz
Comment #2
Richard Archer CreditAttribution: Richard Archer commentedPolls are surely something which should be included in Drupal core.
So... you would remove poll.module from core, hack on it for a while, then put it back?
Comment #3
Frando CreditAttribution: Frando commentedPolls are surely something which should be included in Drupal core.
No, they should not be included in Drupal core.
Drupal core should be more like a framework than like a system that covers all needs.
And this framework is then extended by modules.
However, I think when we start removing stuff from core, we have also to introduce the idea of the 'golden modules', which will be a collection of 'core-like modules'. Modules, which are actively maintained and are considered important.
These modules can then also be gathered together in some kind of drupal distributions.
There is currently a discussion in the development mailing list on that topic, you might want to read this:
http://lists.drupal.org/archives/development/2006-05/msg00029.html
best regards,
frando
Comment #4
archetwist CreditAttribution: archetwist commented-1 for "removing stuff from core". Drupal is not just a framework. Using the same argument you could say that we don't need comment, blog, page, archive and other modules in core and make default installation package unusable.
Besides, I often find additional modules buggy and sometimes incompatible with current version of the core.
Comment #5
robertDouglass CreditAttribution: robertDouglass commentedBefore you get into an argument about "what belongs in core", you've got to step back and examine my basic point: poll is dying in core. Poll cannot be developed in core because the modules and frameworks which now exist and which could make poll great, will never be in core. Thus one cannot develop poll in such a way as to use these frameworks, thus nobody cares about poll, thus poll is dying. Bringing it out of core will free it to be developed.
The discussion about golden modules and distributions is to be had somewhere else, don't do it on this issue, please.
Comment #6
bradlis7 CreditAttribution: bradlis7 commentedWhy can't someone just develop an advanced poll module, so that the basic one stays in drupal core? It seems like there was one that was being developed, but I'm not sure. If one works well, it could be documented inside of drupal for those that want advanced functionality.
Just my $.02.
Comment #7
robertDouglass CreditAttribution: robertDouglass commentedHave no fear of removal from core. It doesn't mean that the module is thrown away, it just means that it a) doesn't get packaged with the main Drupal download, and b) doesn't have to meet all the stringent requirements that core modules must meet.
Ask yourself this: if you want a feature for the poll module, and you write a patch, whom are you going to best be able to convince to commit it; a core maintainer that is busy with the forms API and protecting Drupal from XSS attacks? Or the polls module maintainer who is doing the job because of a specific interest in the poll module?
Comment #8
green monkey CreditAttribution: green monkey commentedGoogle summer project?
5 minutes ago - i didn't even know what a XSS attack was: had to look it up.
Shame we can't teach these people with all that energy to write modules instead :-)
Comment #9
smk-ka CreditAttribution: smk-ka commented+1
I'd prefer to see it developed in a more generalized context using the Voting API. And I like slim frameworks.
--
Stefan Kudwien
www.unleashedmind.com
Comment #10
bradlis7 CreditAttribution: bradlis7 commentedOk, +1 to removing it.
I have had a better experience with individual module developers, for the most part, than with core developers. At least having to do with getting something done, which is understandable..
Comment #11
criswellious CreditAttribution: criswellious commented+1 for removing it.
There's enough irritating problems with this module (my personal favorite is this) that are being ignored that it is in dire need of becoming a seperate module where someone can own it easier.
Comment #12
ChrisKennedy CreditAttribution: ChrisKennedy commentedThe Advanced Poll project seeks to eventually become high-quality enough to justify removing poll from core. We believe that this may be a possibility for Drupal 6.
Comment #13
sun+1
Comment #14
robertDouglass CreditAttribution: robertDouglass commentedChrisKennedy - great news! I'm still in favor of trimming core. Is there and upgrade path from poll to advanced poll?
Comment #15
ChrisKennedy CreditAttribution: ChrisKennedy commentedGood question, I hadn't even though of the need for that. I'll add that to the roadmap & issue queue.
Comment #16
BioALIEN CreditAttribution: BioALIEN commented+1 to the general idea behind this. The poll.module is lacking behind. One cant even set a redirect path after a votes without hacking the code.
The actual module (or block more precisely) HTML is a major overkill and can use some simplification. If advanced poll reaches a stable enough release that allows an upgrade path then I am in favour of replacing poll.module with advanced_poll.module for Drupal 6.
Comment #17
xatoo CreditAttribution: xatoo commented+1 for removing it. Drupal is a light weight modular framework and polls aren't suppose to be a vital part of that.
Comment #18
chx CreditAttribution: chx commentedLet's see whether the CVS log supports the dying claim or not. In the last two years, the only feature we added is inspect and cancel and nothing else. Even that issue begins with
Also, the poll code is simply bizarre at some places. It really seems noone cares.
Comment #19
chx CreditAttribution: chx commentedI read back more -- four years and no features added...
Comment #20
BioALIEN CreditAttribution: BioALIEN commentedAmen to that, brother.
Anybody agree with this insanity?
Comment #21
Robin Millette CreditAttribution: Robin Millette commented+1 to remove it, since nothing is built on top of it.
Comment #22
sunAlmost any poll or voting module relies von Voting API.
We should concentrate on removing poll module from core and replacing it with Voting API.
Having Voting API in core would make rather sense to me.
Comment #23
robertDouglass CreditAttribution: robertDouglass commentedVotingAPI in core is unlikely and not the topic of this issue. I'm marking this ready to be committed even though there is no patch attached. The day the module is removed from core, I will make a contrib project for it and promise to maintain it for one release cycle.
Comment #24
Dries CreditAttribution: Dries commentedPoll module stays in core, and I'm accepting patches for improvement.
Comment #25
chx CreditAttribution: chx commentedYou mean, you accept voting API in core?
Comment #26
alexandreracine CreditAttribution: alexandreracine commented-1 to remove the poll module from core.
Arguements :
- Others have it. Joumbla, etc.
- Polls are fun.
- Polls is a good feature to have from start. Unless there is a very easy web-installer online, like Gallery 2.2.rc2, where one clic does it all (download, install, configure the basic).
Somehow if you have the one clic install, you can remove a lot of others from core. For those who are saying that there is a security trade-off, I'll say that you are right. There are always security trade-off whatever you do. End of story.
Comment #27
alexandreracine CreditAttribution: alexandreracine commented1-Not assigned
2-Dries said it stays
3-This issues is close.
Comment #28
ChrisKennedy CreditAttribution: ChrisKennedy commentedIn case anyone is interested, Advanced Poll now has a migration path from Drupal Polls as of two weeks ago: http://drupal.org/node/102139
Comment #29
catchI agree this should be removed from core.
Personally I reckon the overall issue could be dealt with by two or three core install profiles (with those modules not in the install profile not in the download), so that the CMS-type modules can be developed outside core in x.x-1.x and x.x-2.x branches whilst still offering something recognisable as a CMS to new users. More arguments in favour of this here: http://groups.drupal.org/node/6143
Comment #30
dwwBump: I forgot about this issue, so I just submitted a duplicate a few hours ago and already got enthusiastic support from 7 members of the community, including Moshe:
http://drupal.org/node/200427
What triggered it was realizing that http://drupal.org/node/67895 is still open. It's a critical data-loss bug that's been open for about 1.5 years. Apparently, no one actually uses poll.module enough to care about fixing it. So, either poll should get out of core (yes please!!!), or that issue is a critical bug that should block the 6.0 release. But, we shouldn't release another version of core that contains such broken code. If this gets postponed again, we need to bump the priority on #67895.
Advanced poll in contrib (http://drupal.org/project/advpoll) boasts:
So, it looks like the "but what about a migration path?" question is already solved....
Poll is one of the least used parts of core, it's very broken, it frequently slows down other core development (the FAPI regression test), and many of the leading members of the development community want it to go. Advance poll already provides migration, is maintained by a respected member of the community (ChrisKennedy), and is built on top of the VotingAPI (eaton). Furthermore, if someone wanted to adopt the existing poll module as it moves out of core (much like the drupal.module that we recently dropped), that's fine too, and they can worry about fixing it, maintaining it, porting it to VotingAPI, updating to D7, etc. http://drupal.org/project/poll is even still available. ;)
I've yet to hear a good reason for poll to stay in core for the 6.0 release. If there is one, bring it on. ;) Otherwise, poll should go.
Comment #31
sunI have tested the core Poll module recently and was really disappointed by its features. It took me 5 minutes to install Advanced Poll, it works great, and the included default set of features are really noteworthy.
Thus, I'd say that having the current Poll module in core won't help anyone.
Additionally, we have great support for install profiles now. If there is a demand to have a (bloated) install profile like Joomla, we can create one.
Comment #32
catchI use the core poll module (phpbb2drupal imports them ok so we just switched it on in 4.7) and there's nothing good about it. It's got a whole range of issues (auth. users can vote multiple times with multiple sessions for example, which means the block switches from options to results seemingly at random) and it would be an immediate "won't fix" if someone submitted it to core today.
Rickvug said on the dup. issue:
If people don't want new features, they don't have to upgrade to 6.x at all. The biggest improvement that could've happened to poll, drag and drop, didn't get in - for good reasons - some of them being that it would highlight the shortcomings.
If people think Advanced Poll is too much of a jump for an upgrade path this late in the cycle, then I'd suggest moving poll.module into contrib and immediately deprecating it in favour of Advanced Poll (maybe security patches if someone's prepared to take that on). Then we have the best of all possible worlds and it gives people a few months transition if they need it.
Comment #33
moshe weitzman CreditAttribution: moshe weitzman commentedGood suggestion Catch.poll.module moves to Contrib as is. There is no need for users to migrate elsewhere if they are happy with their data loss. +1. People can keep chiming in on this issue, but I think it is ready for CVS review again. That data loss bug is new information.
Comment #34
TapocoL CreditAttribution: TapocoL commented+1 to move poll.module. I am a new adopter of Drupal (about 6 months into use). One of the few disappointments I had at the beginning were poll, I was thinking since it was core it should be a solid module. However, I came across many spots that lack usability, and the one main bug that hit me was the data loss on editing. I quickly went to see what the community contributed, and have not enabled it for any of my projects. Thought I would reflect my personal experience with it.
Comment #35
Gábor HojtsyGuys, are you serious with removing a core module from Drupal after beta 4 and hopefully right before rc1? This bug was there for such a long time, and I have not seen it being critical for any release before. Also I am not sure it is so critical to warrant the removal of the module. Despite shortcomings, poll does its job of collecting simple polls. The built in stats module is just as simple, and is not enough for most sites, the built-in listings are just as simple, and not enough for most sites. The built-in profile module is just as limited, and not enough for some sites. IMHO poll is not any different.
Although I planned to take my time tomorrow with IMHO more critical bugs for Drupal 6, I'll definitely take this on, even improve on the UI and fix the data loss bug. As far as I see, all it takes is to sit down and think through how the data is used there. Let's meet at http://drupal.org/node/67895 if you care.
Whenever 7.x opens for development, make sure to propose this sooner then past beta 4, if you are serious.
Comment #36
catchSimilar arguments apply although less dramatically in those cases because I'm not aware of any release blockers for those modules.
It's also been bumped repeatedly since then, during this cycle.
edit: I didn't actually mean to change status, but this should stay open while the bug is, in my opinion. We have the module ported, we have namespace in contrib cvs, and we have a long term upgrade path, so happening late in the cycle isn't too much of an issue imo.
Comment #37
Pancho+1. I'm totally on catch's side. I don't see the problem with removing this from core, either, even if it is that late in release cycle.
Fact is:
We have to move the module to contrib, cover this in our upgrade documentation, and that's it. Some issues are too late to be fixed now, but this one is certainly not.
P.S. Some kind of Voting API in core would be great, especially as we are known as a CMS that is strong in community features. But that's another point and it is something to think about for D7.
Comment #38
dww@Gabor: there are many other poll bugs, not just the critical data loss bug:
http://drupal.org/project/issues/drupal?components=poll.module&categorie...
I'm advocating the fastest way to get to a stable D6 release for core is to remove poll instead of trying to fix it. We have vastly more important and far-reaching bugs to be spending our time/energy on than anything in the proceeding query. ;)
As others have pointed out, this isn't a "radical" change to core this late in the cycle. There's are multiple upgrade paths available to existing poll users. It's one minor extra step for a handful of users upgrading to D6, and it a) removes a chunk of unloved, broken code from core, b) would let us focus on fixing bugs that are actually critical, and c) makes development of poll.module possible again.
Thanks for your reconsideration,
-Derek
Comment #39
robertDouglass CreditAttribution: robertDouglass commentedI still fully support the removal of this module from core. I haven't encountered any arguments that I find convincing for keeping it in core. If we want regression tests we should write test cases. The timing with regards to the release cycle is also of no concern to me. We get D6 sooner without poll - yay, that's better.
Comment #40
Gábor HojtsyWell, I sat down and took one hour on that scarily depicted poll module queue. Identified the following outstanding issues:
- 5.x and 6.x had a missing db_rewrite_sql() in the poll pager count query, RTBC for 5.x, committed to 6.x
- 4.7.x does not have a count query there, so the pager is still broken there
- two UI improvement ideas for poll module moved to 7.x
- with page caching enabled, only one anon user can vote (who's surprised?), this is how page caching works by now, poll cannot work around this, 7.x to improve caching in general in Drupal
So three bugs open for 5.x/6.x:
- form_values is not working for a guy, so he cannot ask for more poll options; I cannot reproduce, and from the looks of the code it looks right
- poll editing clears votes (huh, this bug heated up the remove poll craze)
- poll *choices* are removed in some cases (I am investigating this)
This does not seem like end of the world to me.
Comment #41
robertDouglass CreditAttribution: robertDouglass commentedGábor, thank you for looking that closely at the queue.
The bug may have heated up the queue, but the bigger issue is most people just don't like this module, don't use it, resent having to write code for it (when making core changes), and think that it would be better served by putting it in contrib and letting interested parties decide whether it gets maintained. This was a very good decision for Drupal when we moved the archive module into contrib, and I'm 100% confident that poll would die an equally unloved death, primarily because there are better options.
Comment #42
litwol CreditAttribution: litwol commented@Gábor, Even if you fix the bugs in the poll module that doesnt change the fact that no one uses it, no one wants it.
Comment #43
Gábor HojtsyI don't remember how late was archive module removed, but in the current case I see we fixed what feature set we have in Drupal 6 a few months ago, so it would have been an opportunity back then to remove stuff. Now we are fixing issues in what we have, neither removing, neither adding stuff to it.
Comment #44
robertDouglass CreditAttribution: robertDouglass commented@Gábor: I'm not going to try to push you against your will to remove this for D6 (though that would be my preference). I'm totally comfortable removing it at this point in the cycle, but I encourage anyone who is uncomfortable with the decision to speak up. We can remove it from D7. However, the comments here do send one clear message - and that is very few people are willing to waste their time bugfixing a module that they don't care about.
Comment #45
PanchoWell, I guess we should surrender, as this discussion doesn't seem to be about arguments, but about rules and authority. Dries and Gábor just don't want poll.module to be removed in D6. And technically there's no room for discussion, as features have been already frozen.
I actually don't care that much about a dead module in Drupal 6 core. I won't enable it, and thus it won't bother me.
So let's restart the discussion for D7. The big questions are IMHO:
Think that this will lead us towards a more encouraging discussion.
Comment #46
catchIn terms of precedent, Drupal module is the most recent example, not that long ago.
Pancho in terms of what should and shouldn't be in core - I think there's a wider question of whether any cms type stuff should be in core at all, especially as install profiles develop.
Comment #47
Gábor HojtsyrobertDouglass: it would be interesting to compare the Drupal 5 poll module to the Drupal 6 poll module, and then say whether nobody cared to work on it, I looked into the CVS logs:
- errors were fixed for E_ALL compliance
- merlinofchaos pointed out on IRC that he did considerable work to upgrade the module to proper FAPI 3 use in Drupal 6
- he also tplified the module (nice huge diff at: http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/poll/poll.module?r...)
- reverse proxy, node_load() cache, etc. improvements all improved the module in different patches
- Crell split the module into multiple parts
- quicksketch et. al. improved on the UI and added AHAH poll option addition, one of the very few AHAH form showcases in Drupal 6
- blakehall, JirkaRybka, catch improved on its permission names to be more usable
- in GHOP and out of GHOP, the help texts were improved, the content type description was replaced
- I am into fixing whatever very old bugs come up
These are the main things improved in poll module between Drupal 5 and 6. quicksketch et. al. also proposed a patch to add drag and drop support which would have also fixed the bad db table design, but this was late, so was not committed.
Do we call this "nobody cares about the module"?
Comment #48
dww@Gabor: I, too, am uninterested in fighting over this. I've already spent way more time thinking/writing about poll module in D6 than it deserves. ;)
I just want to point out that from my perspective, at least 1/2 of your list up there falls into my "poll module slows down core development by forcing people to work on it who don't otherwise care" category. ;) E_ALL, FAPI3, tplification, reverse proxy/node_load caching, module split... I thank everyone who worked on this things, but if you asked them, I'd bet they'd answer "yeah, change X was my baby, so I had to get poll to support it too or it wouldn't have been committed".
Basically, the only new feature from your list that people did specifically *for* poll, because they wanted to, was the UI/AHAH thing, and even that was probably motivated by "this feature is cool, where's something we could use to show it off? i guess poll would do", not "poll's so great, and i use it on all my sites, so i want to make it rock!". The other few remaining changes were bug fixes: fixing the permission names, fixing the help text, etc.
So, I'm not convinced this is a strong evidence to support the theory that lots of people care about this module. But, as I said at the top, I'm not arguing about it anymore... ;)
Comment #49
Crell CreditAttribution: Crell commentedI will not claim to speak for anyone else, but my reason for page-splitting poll was "it's in core, so I may as well". There were several other modules where that was the case, too. It was not because I particularly like poll module. :-) I am in favor of it moving to contrib and letting Darwin take its course, as long as there is an upgrade path for it (to the contrib, to adv_poll, or whatever).
That said, I am inclined to agree with Gabor. We're at beta 4 state, we're six months past theoretical code freeze, and we've already violated that code freeze a couple of times. :-) Unless poll is unfixable for D6, let's plan and agree right now that once D7 opens up, poll module gets dropped within the first month. (If we don't, this issue will get forgotten until D7-beta4 and we'll have the same conversation all over again.)
Comment #50
webchickI'd be ok with removing poll if we have full unit tests for core. It /is/ our regression test, after all. :P
I do concur that removing a module from core will make core development times faster, which by itself may be a worthy goal. But thinking that we're going to somehow magically end up with a better poll module because we put it in contrib is a pipe dream, imo, and not supported by facts/evidence.
The old Drupal module, Site Network, thusfar hasn't seen /any/ commits since October 8/9, 2007 when it was removed from core: http://drupal.org/project/cvs/181692. That's over 2 months now.
And it looks like it took the old Archive module from core over a year to get a new maintainer interested in expanding its feature set: http://drupal.org/project/cvs/77690
The arguments made here against poll module could easily apply like half the modules in core:
- Aggregator, which was completely broken > 50% of our dev cycle in 6.x
- Blog module, a constant source of usability headaches for the single-user blog case.
- BlogAPI, which hasn't been updated in earnest since over a year ago.
- Forum, which saw some love this time around, but is still light-years behind dedicated systems like PHPBB
- Ping, same boat as BlogAPI.
- Profile, another source of bugs, and a performance drain on heavy-traffic sites.
- Throttle, which d.o doesn't even use. :P
- Tracker, the source of our most damanging query, performance-wise
- Upload, which is another constant source of bugs that no one in their right mind wants to touch.
So looking at that list, we'd be removing all of the features which put Drupal ahead of its time when they were conceived, along with PoC code for features such as our File API, and over half of what makes Drupal a "community" management system. Our core development cycles would likely be much faster without these things, true. But we would also eliminate a lot of what makes Drupal competitive in the more than "just" a framework area.
Thus far, moving something to contrib is at best a crap-shoot, at worst a death sentence. It also makes things more difficult for our users. Instead of "Let me start by what's offered in core and then move on to add-on modules for this feature," it becomes "Crap. Which of these 30 modules that all seem to do the same thing do I use for feature X?" It also makes our beta testing of core more useless. Right now, almost the only things that are getting tested are things in core, since contrib lags so far behind porting things. And unless we include functionality that tests the limits of things like Form API, we're not going to find out things like, "Oh, crap. It turns out multi-page forms are completely broken." until /way/ too late to fix them without causing a lot of pain.
Despite all of this, I am roughly neutral for removing poll in 7.x, however I just want to make sure we are taking all of these things into consideration before we go hog-wild.
Oh, but absolutely -1 for removing Poll module for D6. We got away with that in Drupal module only because we had a suitable replacement that was superior in every way.
Comment #51
JirkaRybka CreditAttribution: JirkaRybka commentedI've nothing great to say here, except my personal approach to core modules: I care most about the ones, that my production site runs. I believe, most of us do it this way, more or less. From this angle of view, poll module is one of the more important ones for me, while other modules I don't care about entirely (quite a few others in core). Matter of taste, I would say. Also I think there are other such 'basic' modules in core, for example I wonder why we even have the blog.module, when it does nothing more than a custom basic content type, and a few node listings (well possible through Views), tracker.module (on my site Views replaces it entirely), etc.
As for the poll problems - on my site, anonymous users can't vote (as well as they can't post comments - we're interested about members' opinions, not just passing-by spammers), and I don't even think that granting permissions for editing own polls is a good idea (changing the question makes the whole months-collected poll results unreliable a lot). The only problem I ever had with poll module was, when another admin misunderstood something and added a new option to a running poll (resulted in everyone being able to vote again). But still, we saw much bigger bugs in core already (comment-jumps, luckily now fixed, for example).
The drupal.module was, I believe, removed under a bit different conditions: OpenId sort-of replaced it, so core in fact didn't loose any functionality. We don't need two modules for the same, IMO.
So as for me, -1 to removal.
Comment #52
Gábor HojtsyNote that as it looks like poll module's issue queue is cleaned up. There are two trivial RTBC fixes for 5.x, one user notification improvement sitting for review when it comes to anonymous polling and page caching in Drupal 6, which will not work together, a 7.x feature suggestion and a missing pager in 4.7.x, which I would not fix as 4.7.x is reaching its end of life very soon now.
So one more issue against 6.x, then 6.x is without issues as far as the poll queue goes.
Comment #53
catchHere's a patch.
Comment #54
Freso CreditAttribution: Freso commentedHohum. If we're going to move it to contrib, perhaps it would be better if someone with filesystem access "simply" moved the files (so that commit/revision history was preserved)? (Or it might be better to remove the files and import them in contrib, seeing the status of 6.x CCK...)
Also, is this really critical? The data loss issue was taken care of, right?
Comment #55
catchThere's currently the Advanced Poll module in contrib (which uses Voting API and has more options), and Pollfield module (which supposed to be functionally identical to poll.module except for providing a CCK field instead of a node type). Both modules provide an update path from the core poll tables afaik, although Advanced Poll is more actively maintained.
I'm going to downgrade this from critical, fair point. A few people have mentioned that poll.module currently provides core's best FAPI regression test (note that commenting on polls has been broken in HEAD for two months which I guess is a suitable example). I can understand wanting to keep it in for that reason, although I don't think this particularly helps people who want polls on their site, so it'd be better long term to either write a regression test, or use another complex form if one gets added to core later, if that's the main reason put forward to keep it in core.
Here's a working patch with a CHANGELOG.txt entry.
Comment #56
Freso CreditAttribution: Freso commentedAs soon as SimpleTest is in core this point should be moot, shouldn't it?
Comment #57
webchick@Freso: It depends on how good our tests are. To date, nothing has tested the Form API quite like the Poll module... it's a multistep form, and a node form at that, with a collection of fields in each grouping. We could write some fake form arrays to test the crap out of FAPI, but Poll module proves that it's actually usable.
Comment #58
aaron CreditAttribution: aaron commentedThe module is a half-dead branch hanging from the Drupal tree. There are better alternatives, with upgrade paths. Moving it to contrib won't fix Poll. Keeping it in core won't fix it.
I'd suggest moving it from core, and giving the namespace to one of the alternatives (probably advanced poll), so long as the maintainers promise to also maintain that upgrade path. That way, the cruft is gone, the module is instantly made far superior, and being in contrib allows a more robust evolutionary path.
Comment #59
webchick-1 for advanced poll taking the place of poll in contrib. That module does WAY more than a simple PHPBB-esque Poll module replacement, which is what most people use it for.
Comment #60
moshe weitzman CreditAttribution: moshe weitzman commentedsee the title of this issue. thats not being proposed. the issue creator proposes to move poll.module into contrib where interested people can use it OR use advanced poll or whatever. please, no straw men to derail the conversation..
Comment #61
chx CreditAttribution: chx commentedWe need to the test the preview and the creation of a node form that adds elements on the press of a button utilizing AHAH. Currently this is done by the poll module and the poll test and it very nicely catched a lot of form API errors. I suggest adding a path to node_menu, put the code into node.test.inc and add a test for it. Borrowing code from poll.module and poll.test is allowed :)
Comment #62
Dries CreditAttribution: Dries commentedI've no desire to remove poll from core -- certainly not at this point in the development cycle. I think we should make poll module better, and open new issues to fix whatever needs fixing.
Comment #63
dww<disgruntled>
#62: certainly not at this point in the development cycle ("early")
#35: removing a core module from Drupal after beta 4 and hopefully right before rc1? ("late")
</disgruntled>
Seems there's no "good" time to do this. Let's be honest here: Dries loves poll.module, so it will stay in core (presumably, forever). ;) The rest of us have better things to spend our time on than lost causes such as this...
Comment #64
catchNever say never.
If it stays in, we ought to unbreak it though: http://drupal.org/node/216515
Comment #65
bsherwood CreditAttribution: bsherwood commented+1 for removing poll from core.
From an administrator's point of view, I typically do not use many core modules (poll, profile, blog, forum, book, etc..). Most of the functionality can either be duplicated with CCK/Views or is not important enough for my sites to use. This is why having an API for CCK and views in core is one HUGE step in the right direction. Core modules should be nothing but a API so we can extend Drupal.
I can understand Dries motives for keeping it in and respect his viewpoints, I just don't think its forward thinking. I do agree with the community that "core" should not rely on contrib modules.
I think most of the modules I mentioned earlier were great when they were the only option, but things have changed. Drupal is moving away from a CMS and into more of a CMF.
I am not sure about moving one module out of core and adding another, would this mean that if we put Advanced Poll into core, would it still be maintained the way it is? Or should we just move poll (and book,forum,etc,,) out and leave them out?
I don't really have the answer to this, but I do think we need to embrace forward thinking code as opposed to hanging on to old or rarely used code.
Comment #66
owahab CreditAttribution: owahab commented+1 for a poll API in core but not a whole module.
Comment #67
HS CreditAttribution: HS commentedHow do you report bugs in poll since it's a core module?
Comment #68
catchHilalsuhaib open a new issue at http://drupal.org/project/issues/drupal/bug and choose the 'poll.module' component.
Comment #69
bsherwood CreditAttribution: bsherwood commentedIt's been a couple of months since this was discussed. Any progress on this issue?
Comment #70
ChrisKennedy CreditAttribution: ChrisKennedy commented1) Dries doesn't want poll.module removed from core (#62), which makes perfect sense, esp. after poll.module got a bunch of much-needed bug fixes prior to the D6 release. 2) If there were any "progress" on this issue it would (kind of obviously?) be posted here.
Comment #71
dwwThis is postponed until Drupal decides that core is going to be a framework, we rip out modules like poll and blog, and provide different bundled installation profiles for different kinds of sites. Given the direction of the d7ux stuff, I doubt this is going to happen in D7, maybe never. I still think "won't fix" is the more accurate status, but catch seems to think "postponed". /me shrugs
Also, please don't use "maintainer needs more info" unless you're a maintainer asking for more information from someone who posted an incomplete issue that doesn't clearly explain the bug or feature being discussed. See http://drupal.org/node/156119#postponed-maintainer-needs-more-info for more. Thanks.
Comment #72
NaheemSays CreditAttribution: NaheemSays commentedHas there been any attempt to turn poll into a field instead of its own node?
Comment #73
rickvug CreditAttribution: rickvug commentedTagging.
Comment #74
q0rban CreditAttribution: q0rban commentedDear g-d, +1
Comment #75
q0rban CreditAttribution: q0rban commentedwhoops
Comment #76
jennifer.chang CreditAttribution: jennifer.chang commentedsubscribe
Comment #77
markus_petrux CreditAttribution: markus_petrux commentedsubscribing
Comment #78
catchIt's not going to happen this release, we should renew the hate-fest in D8 though.
Comment #79
anarcat CreditAttribution: anarcat commented+1.
Comment #80
chx CreditAttribution: chx commentedhttp://buytaert.net/8-steps-for-drupal-8 let's stop saying smallcore.
Comment #81
webchickSomething that's interesting to note is that despite our new fancy-schmancy testing framework, Poll module still seems to prevail as the best regression test we have for complex FAPI and AJAX/AHAH functionality. ;)
Comment #82
sunI'm totally unofficially calling this issue won't fix.
Instead of degrading Drupal core's functionality that's available (not enabled) by default out of the box, we totally want to do the opposite: Improve it.
So where are all the pollfield, advpoll, and wtf module maintainers today? On vacation?
Applications accepted here: #621618: Revamp MAINTAINERS.txt
Comment #83
GreenReaperDecisions seems pretty active (they just added AJAX in CVS). Advanced Poll hasn't had an update since May '09.
Comment #84
NaheemSays CreditAttribution: NaheemSays commentedpollfield I think was mooted as a potential replacement at some point, but yes decisions and adv_poll are also out there.
(Some people seem to think pollfield has a "more correct" implementation but I have not looked too deeply into it or have any idea what they mean by it.)
Comment #85
sircurmudgeon CreditAttribution: sircurmudgeon commentedPollfield is nice with one exception: I can't figure out how to make a view for mods to inspect votes. I consider it to be more correct because it allows you do add field_***** which means you can put it in any content type. I don't see similar functionality in adv_poll. I have not tried decisions. It did not appear to be what I needed, but I could be wrong.
Comment #86
asb CreditAttribution: asb commentedsubscribing
Comment #87
mcrittenden CreditAttribution: mcrittenden commentedHopeless subscribe.
Comment #88
bojanz CreditAttribution: bojanz commentedDo we want to re-examine this in light of recent talks (#1255674: [meta] Make core maintainable)?
Comment #89
catchSo with this one I see the following options:
- someone volunteers to maintain it in contrib
- deprecate it in favour of one of these (the top one has a new maintainer!)
* http://drupal.org/project/pollfield
* http://drupal.org/project/decisions
* http://drupal.org/project/advpoll
(other projects to add to this list would be great if I missed one)
- just move it to contrib and mark it abandoned, hope someone picks it up.
- leave it in core, requires finding enthusiastic and active maintainer which we should set a deadline for.
Any of these are better than what we have now which is a long running situation of it being the only test module in core with hidden[] = true.
and
http://drupal.org/project/issues/search/drupal?status%5B%5D=Open&categor... shows how bad things are.
One major bug got fixed by marcingy (likely to keep thresholds down), that's it for months.
Comment #90
aaron CreditAttribution: aaron commentedConsidering #24 and #62, assuming Dries hasn't budged yet, I propose we go with deprecating it with one of catch's options.
Comment #91
catchattaching output of git log modules/poll/poll.module | head -500 > patches.txt
- not many commits.
- most are to keep it hobbling along with changes elsewhere in core, that's a direct drain on time that could be spent elsewhere.
The last patch I can find that added any kind of feature to Poll is #360785: Add a timestamp field to {poll_votes} from January 2009. You can tell how rare these patches are because it was committed almost immediately ;)
Before that I think it was #193076: Drag and drop in poll module although that was mainly standardization again.
There might be something in between May 2008 and January 2009 that I missed, just did a quick scan down. I have a feeling some refactoring/modernization happened along the way, possibly as a byproduct of the AJAX framework. It's also possible drag and drop and timestamps are the only two notable patches since #24 was posted back in 2007.
Given the only bugs in poll that get fixed are ones we introduce by core changes elsewhere (i.e. regressions), if we moved it to contrib it could be considered 'mature' and just propped up like it currently is (assuming someone cares for it).
Comment #92
sunThanks for the detailed analysis, @catch. Based on that, +1 for complete removal.
As mentioned on the meta issue, we can look into re-introducing something else, more modern, more generic, more generally useful later in the cycle or whenever we think the time is right.
Comment #93
carlos8f CreditAttribution: carlos8f commentedHere are the poll results for poll removal.
yea (26)
sun
Robin Monks
Frando
robertDouglass
smk-ka
bradlis7
criswellious
ChrisKennedy
BioALIEN
xatoo
chx
Robin Millette
catch
dww
moshe weitzman
TapocoL
Pancho
Litwol
Crell
webchick
aaron
bsherwood
owahab
q0rban
anarcat
carlos8f
nay (6)
Richard Archer
archetwist
Dries
alexandreacine
Gábor Hojtsy
JirkaRybka
Kind of lame that with such a majority and 5 years (!) of discussion, nothing comes of this. I have been increasingly disillusioned with Drupal because of these types of situations. Core has many unusable aspects that an influential minority don't want to give up. Fighting is fruitless. Kick-ass platforms are sprouting up faster than Drupal can close a single critical issue; adjust or perish.
Comment #94
chx CreditAttribution: chx commentedhttp://drupal.org/node/1255674#comment-4916080 first.
Comment #95
amateescu CreditAttribution: amateescu commentedCrossposting #1266336: Modernize Poll module as I have volunteered to bring new life into Poll for D8.
Comment #96
sunComment #97
generalredneck+1
Comment #98
robertDouglass CreditAttribution: robertDouglass commentedRan into this again today. 6 years running and I still believe that this module should be removed from core.
Comment #99
tgeller CreditAttribution: tgeller commented+1 for removal here, due to an apparent bug I found today as well. (No, I'm not reporting it -- that's not the solution.)
Comment #100
Gábor HojtsyUnless poll is modernized enough with something like #1266336: Modernize Poll module, I think it makes a ton of sense to remove it from Drupal 8 for good. It will be near impossible to give it any multilingual support in the fashion we are expanding in Drupal 8 for example, so it will just fall behind even more. I complained above about the request getting traction all to late in the Drupal 6 cycle (which was likely used when "tallying up the votes" above). I do support removal of poll module if a modernization is not being worked on.
Comment #101
amateescu CreditAttribution: amateescu commentedI don't know if I said this in the other issue, but I'm waiting for plugins and the plugin-ification of Field API before starting to work on #1266336: Modernize Poll module. If those happen too late, I agree that removal is the only option.
Comment #102
Gábor HojtsyWell, it will be too late to remove the module then :) What's the problem with working on a field based solution now?
Comment #103
amateescu CreditAttribution: amateescu commentedTo be honest.. I just wanted it to be an exercise for me to learn the new plugins stuff :)
Comment #104
chx CreditAttribution: chx commentedDid anyone review whether the functionality poll provides (node previews, multistep forms, etc) have simpletests w/o poll?
Comment #105
lpalgarvio CreditAttribution: lpalgarvio commentedAdvanced Poll is having some work lately =)
development resumed 33 weeks ago
+1 for drop from core
would it be too hard to place core's Poll on it's own contrib module?
like was done with Blog, issue #233301: Remove blog module from core
Comment #106
jvsouto+1
Comment #107
adammaloneHave to put myself behind removing it. Especially when there are so many fantastic contrib modules to choose from that provide far more extensive functionality.
Perhaps a poll could be placed on drupal.org so all users may enter an opinion!
Comment #108
andypostPoll as Field module approach issue #1266336: Modernize Poll module
Also it depends on
#1785256: Widgets as Plugins
#1785748: Field formatters as plugins
Comment #109
adammaloneI've removed poll module and replaced tests provided by poll as chx stated here.
May as well get the ball rolling again!
Comment #110
adammaloneMight have been an idea to delete the poll directory again this morning after pull...
Comment #112
adammaloneRerolled patch with bleeding edge HEAD
Comment #113
adammaloneComment #114
NonProfit CreditAttribution: NonProfit commented[comment removed by author]
Comment #115
catchDries last posted on this issue in 2008. Poll module has had very few improvements since, so I think it's time to assign this issue again for feedback.
Comment #116
adammalonecatch - would it be worth me rerolling a patch with the latest HEAD?
Comment #117
amateescu CreditAttribution: amateescu commentedI'm very sad that I didn't find the time/energy to work on #1266336: Modernize Poll module and I doubt that's feature freeze exception material :( As the current maintainer of poll.module, I have to agree with removing it from D8..
Comment #118
jcisio CreditAttribution: jcisio commentedI don't see any candidate for Poll in contrib. AdvPoll has only 3000 installs, Pollfield has only 1000 installs, Decisions has 500 installs.
Also, Poll is an important module in core, many many people are still using it. Let's look at the numbers again: http://drupal.org/project/ajax_poll itself has more than 2000 installs, which is half of http://drupal.org/project/ajax_comments 4000 installs. So we can unscientifically say that Poll has as much as 1/2 usage of Comment module, which itself is an very important module.
I'll try to work on #1266336: Modernize Poll module in the next few days.
Comment #119
catchYes the current state of contrib poll modules is still bad. This would probably require moving it to a contrib project and finding a volunteer to maintain in contrib.
Comment #120
sunI'd really prefer to do #1266336: Modernize Poll module instead.
AFAICS, that would rather count as plain refactoring, so personally I don't think it would be bound to Dec 1st feature freeze. I'd rather count it as part of the larger D8 entity/field refactoring. Although it would certainly be good to see an initial >50% patch before freeze for it.
Ultimately, I also think there's no way around getting rid of the node-types-supplied-via-info-hook-code API for D8 due to CMI anyway, so turning poll into a simple field would also be required for that.
My personal impression is that no one really wants to work on it currently, because its architecture and implementation is stone-age. However, once that is brought up to par with the current, modern entity/field design, I'm relatively confident that there will be more interest in a solid and perhaps even re-usable/extensible core implementation.
I'm more or less experiencing the same in #1825044: Turn contact form submissions into full-blown Contact Message entities, without storage, which brings Contact module to the new era. Contrary to its current/old D7 implementation, I can tell you already now that I will certainly use that module on D8 sites. The lesson that I think I've learned there is that some pieces just need to be modernized and re-invented just like the rest of Drupal core, in order to them useful.
And it's not like poll/voting wasn't useful. It's just that the current implementation sucks. So let's re-invent the implementation. :)
Comment #121
adammaloneAfter speaking with catch this morning on IRC it seems that one of two options should be considered:
If both options are on the table it becomes a lot easier to decide which is better suited for the future of Drupal. One of the key things that perhaps should be remembered is that this issue was opened in 2006 with patches and more intent discussion since 2008. It would be good not to let this issue languish for yet another version of Drupal. Instead taking action and deciding which of the above two (or more) options would be best for the eventual closure of this issue.
Comment #122
g089h515r806 CreditAttribution: g089h515r806 commentedSupport remove it to a contrib module.
I have never used poll module in a real Drupal project.
Comment #123
catchI'd be happy with a poll field type, or moving poll to contrib, however I don't think we should keep going with neither of them happening.
Comment #124
andypost@catch, I suppose the better and simple/doable is to move voting api into core and made a field on top of it. This way should allow a contrib to invent a set of widgets/formatters also would be a great help for votingapi-related contrib much easy to follow d8cx pledge
Comment #125
adammaloneI'm not so sure votingapi belongs in core either to be honest. I see what the benefit of widgets and formatters on top of votingapi would be, but as you've said, a contrib can do that and votingapi doesn't have to be in core for that to happen.
Perhaps poll and votingapi could be combined or in some way reworked together, but in my opinion it should happen in contrib.
Comment #126
webchickVoting API in core is too late for D8.
Comment #127
Dries CreditAttribution: Dries commentedThe poll module as it exists today stopped making sense. A poll field type makes a lot of sense though.
I'm ok with us removing the poll module now, but I may choose to bring it back if it is made a field type in contrib before February 18 (feature completion date).
Comment #128
adammaloneHere's a little reroll to the latest HEAD in light of what Dries said.
Comment #130
adammaloneLet's try that again...
Comment #131
catchAll looks sane to me.
Comment #132
catchMoving to Dries since I RTBCed this.
Comment #133
klausi#130: 61285-130-remove_poll_from_core.patch queued for re-testing.
Comment #135
adammaloneIronically most changes that caused the patch to fail were in poll module...
Comment #137
rliComment #138
sunCan we at least defer this removal to the end of the development cycle, right before release?
That way, we can
git subtree split core/modules/poll
into a contrib repository, taking over the entire history, but more importantly, there is a fully working module readily available when D8 is released, so existing sites are not blocked on upgrading to D8.(IMO it's almost guaranteed that no one will work on the upgrade path in the contrib Poll module as soon as it has been split.)
Comment #139
adammaloneI'm happy to work on an upgrade path alone or with amateescu (as I believe he is current poll maintainer)/whoever else wants to volunteer. It's my feeling that since I have patched the removal I should probably see it through in its entirety and complete an upgrade path too!
Comment #140
Dries CreditAttribution: Dries commentedI don't think we should wait to remove it until just before release. That seems inconsistent with how we dealt with module removal in the past. Plus, we have two people that volunteered to write the upgrade path. So ... I'd like to go ahead and commit this now. However, it will need one last re-roll as the patch no longer applies.
Comment #141
Dries CreditAttribution: Dries commented#135: 61285-135-remove_poll_from_core.patch queued for re-testing.
Comment #142
webchickPre-emptively marking needs work.
Comment #143
adammaloneI'll reroll this later today.
Comment #144
adammaloneOk here it is. Again core/modules/poll had changed so needed re-removing.
Comment #145
catchBack to RTBC.
Comment #146
adammalone#144: 61285-144-remove_poll_from_core.patch queued for re-testing.
Comment #147
adammalonePatch no longer applies locally so here's another reroll.
Comment #148
adammaloneSince #1331486: Move module_invoke_*() and friends to an Extensions class has been reverted the patch in #144 still applies.
Marking as RTBC per catch in #145.
Comment #150
amateescu CreditAttribution: amateescu commentedDon't forget about MAINTAINERS.txt :)
Comment #151
adammaloneSince #1331486: Move module_invoke_*() and friends to an Extensions class got committed again here's another patch that takes the changes into account.
I've also included another patch which removes references to poll from MAINTAINERS.txt and a couple of the *api.php files.
Hopefully this can get committed before core changes again!
Comment #152
moshe weitzman CreditAttribution: moshe weitzman commentedBack to RTBC
Comment #153
Dries CreditAttribution: Dries commentedCommitted to 8.x.
I finally gave in. Feeling sad and happy about it at the same time.
Thanks to @typhonius for volunteering to keep working on poll module.
I would still love to see a Poll Field module in core.
Comment #154
sunFollow-up: #1897468: Kernel rebuilds service container on every request when a module vanishes
Comment #155
andypostWhy there's no change notice and link to contrib module here?
Comment #156
htoipa CreditAttribution: htoipa commentedIts project page is here:
https://drupal.org/project/poll
Comment #157
htoipa CreditAttribution: htoipa commentedComment #158
ParisLiakos CreditAttribution: ParisLiakos commentedStill, i don't see any change notification
http://drupal.org/node/add/changenotice
Comment #159
adammaloneChange notice created here http://drupal.org/node/1899976
Comment #161
jwilson3Now that this is in, I've opened a task in the new poll module issue queue about what to do with the open issues in core queue: #1913480: What to do with poll.module issues in Drupal core queue?.
Comment #162
alexpottFollow-up patch created: #1922250: Announce poll removal in CHANGELOG.txt