Remove poll module from core

+1

Robin
I ♥ Bugz

Polls 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?

Polls 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

-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.

Why 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.

Google 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 :-)

+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

Ok, +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..

+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.

The 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.

+1

Good question, I hadn't even though of the need for that. I'll add that to the roadmap & issue queue.

+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.

+1 for removing it. Drupal is a light weight modular framework and polls aren't suppose to be a vital part of that.

Let'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

I don't know if poll.module is really considered "core" in the same sense as the truly core parts of drupal. it's a nice module and all, but it's optional, not central to the proper functioning of all drupal sites.

Also, the poll code is simply bizarre at some places. It really seems noone cares.

I read back more -- four years and no features added...

the poll code is simply bizarre at some places

Amen to that, brother.

        <div class="content">
          <form action="/drupal/node/5"  method="post" id="poll-view-voting">
            <div>
              <div class="poll">
                <div class="vote-form">
                  <div class="choices">
                    <div class="form-item">
                      <label>Poll question?</label>
                      <div class="form-radios">
                        <div class="form-item">
                          <label class="option">Poll Answer

Anybody agree with this insanity?

+1 to remove it, since nothing is built on top of it.

Almost 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.

Poll module stays in core, and I'm accepting patches for improvement.

You mean, you accept voting API in core?

-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.

1-Not assigned
2-Dries said it stays
3-This issues is close.

In case anyone is interested, Advanced Poll now has a migration path from Drupal Polls as of two weeks ago: http://drupal.org/node/102139

I 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

Bump: 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:

Migration: convert regular Drupal polls into Advanced Polls.

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.

I 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.

I 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:

asking users to migrate to something with many features that they've never seen, and likely don't need, could be confusing.

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.

Good 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.

+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.

Guys, 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.

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.

Similar arguments apply although less dramatically in those cases because I'm not aware of any release blockers for those modules.

Whenever 7.x opens for development, make sure to propose this sooner then past beta 4, if you are serious.

robertDouglass - May 1, 2006 - 18:14

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.

+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:

• (Quite) nobody uses poll.module.
• Nobody develops for poll.module.
• Nobody cares about poll.module.
• For those who want to use it, we have it in contrib for D6.
• For those who want to move to advanced poll, we're having an upgrade path.

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.

@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

Well, 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.

@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.

I 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.

Well, 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:

1. Do we want to have some kind of voting capabilities in D7?
2. If yes: How generic or how special should it be? More APIish or some features that allow us to say "We also have voting!"
3. If APIish:
   • Let's collect the features and capabilities our core Voting API should have.
   • Are there good starting points in contrib or do we want to develop something new?
   • Finally: How can we make sure this is generic enough, so it will be the basis for some 95% of all contrib voting modules out there?

Think that this will lead us towards a more encouraging discussion.

In 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.

robertDouglass: 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"?

@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... ;)

I 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.)

I'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.

I'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.

Note 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.

Here's a patch.

Hohum. 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?

There'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.

A few people have mentioned that poll.module currently provides core's best FAPI regression test
As soon as SimpleTest is in core this point should be moot, shouldn't it?

@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.

The 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.

-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.

see 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..

We 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 :)

I'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.

<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...

Never say never.

If it stays in, we ought to unbreak it though: http://drupal.org/node/216515

+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.

+1 for a poll API in core but not a whole module.

How do you report bugs in poll since it's a core module?

Hilalsuhaib open a new issue at http://drupal.org/project/issues/drupal/bug and choose the 'poll.module' component.

It's been a couple of months since this was discussed. Any progress on this issue?

1) 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.

This 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.

Has there been any attempt to turn poll into a field instead of its own node?

Tagging.

Dear g-d, +1

whoops

subscribe

subscribing

It's not going to happen this release, we should renew the hate-fest in D8 though.

+1.

http://buytaert.net/8-steps-for-drupal-8 let's stop saying smallcore.

Something 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. ;)

I'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

Decisions seems pretty active (they just added AJAX in CVS). Advanced Poll hasn't had an update since May '09.

pollfield 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.)

Pollfield 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.

subscribing

Hopeless subscribe.

Do we want to re-examine this in light of recent talks (#1255674: [meta] Make core maintainable)?

So 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.

MAINTAINERS.txt
Poll module
- ?

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.

Considering #24 and #62, assuming Dries hasn't budged yet, I propose we go with deprecating it with one of catch's options.

attaching 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).

Thanks 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.

Here 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.

http://drupal.org/node/1255674#comment-4916080 first.

Crossposting #1266336: Modernize Poll module as I have volunteered to bring new life into Poll for D8.

+1

+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.)

Unless 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.

I 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.

Well, it will be too late to remove the module then :) What's the problem with working on a field based solution now?

To be honest.. I just wanted it to be an exercise for me to learn the new plugins stuff :)

Did anyone review whether the functionality poll provides (node previews, multistep forms, etc) have simpletests w/o poll?

Advanced 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

+1

Have 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!

Poll as Field module approach issue #1266336: Modernize Poll module
Also it depends on
#1785256: Widgets as Plugins
#1785748: Field formatters as plugins

I've removed poll module and replaced tests provided by poll as chx stated here.

May as well get the ball rolling again!

Might have been an idea to delete the poll directory again this morning after pull...

Rerolled patch with bleeding edge HEAD

[comment removed by author]

Dries 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.

catch - would it be worth me rerolling a patch with the latest HEAD?

I'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..

I 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.

Yes 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.

I'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. :)

After speaking with catch this morning on IRC it seems that one of two options should be considered:

1. Remove poll from core in its entirety. Poll becomes a contrib module and someone/some people volunteer to maintain. (I would offer to co-maintain but feel poll would be best served with someone else in addition to me with more experience).
2. Remove the poll module as we know it and instead focus on making a poll field type. This already has an issue addressing it: http://drupal.org/node/1266336. If I can help with that I will!

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.

Support remove it to a contrib module.
I have never used poll module in a real Drupal project.

I'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.

@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

I'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.

Voting API in core is too late for D8.

The 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).

Here's a little reroll to the latest HEAD in light of what Dries said.

Let's try that again...

All looks sane to me.

Moving to Dries since I RTBCed this.

#130: 61285-130-remove_poll_from_core.patch queued for re-testing.

Ironically most changes that caused the patch to fail were in poll module...

Can 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.)

I'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!

I 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.

#135: 61285-135-remove_poll_from_core.patch queued for re-testing.

Pre-emptively marking needs work.

I'll reroll this later today.

Ok here it is. Again core/modules/poll had changed so needed re-removing.

Back to RTBC.

#144: 61285-144-remove_poll_from_core.patch queued for re-testing.

Patch no longer applies locally so here's another reroll.

Since #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.

Don't forget about MAINTAINERS.txt :)

Since #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!

Back to RTBC

Committed 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.

Follow-up: #1897468: Kernel rebuilds service container on every request when a module vanishes

Why there's no change notice and link to contrib module here?

Its project page is here:
https://drupal.org/project/poll

Still, i don't see any change notification
http://drupal.org/node/add/changenotice

Change notice created here http://drupal.org/node/1899976

Now 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?.

Follow-up patch created: #1922250: Announce poll removal in CHANGELOG.txt