Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Hi,
I'm trying to use 'Vote Up/Down' 6.x-2.x-dev from 2010-Mar-12 to allow anonymous users to vote on content (nodes). According to the project page, this release should allow this. However, anons get an "Oops! There was an error in submitting your vote!" error message when trying to vote with the 'Alternate' widegt.
Watchdog logs:
Could not vote on node 54912, with value 1, tag updown and token de093a99ff917b73881a2c413368474a
Permissions:
* vud module - "use vote up/down" (checked for all roles)
* vud_node module - "use vote up/down on nodes" (checked for all roles)
Any ideas or suggestions?
Thanks & greetings, -asb
Comment | File | Size | Author |
---|---|---|---|
#20 | Clipboard-5.jpg | 60.67 KB | idflorin |
#11 | watchdog-vud.jpg | 224.99 KB | asb |
Comments
Comment #1
asb CreditAttribution: asb commentedUpgraded to 6.x-2.x-dev from 2010-Apr-19, anons still can not vote. Error message from Watchdog log:
I do have these lines in
robots.txt
:Anyone?
Thanks & greetings, -asb
Comment #2
Oleksa-1 CreditAttribution: Oleksa-1 commentedI think, some how related to http://drupal.org/node/554360#comment-2749260 . Looks like problem with ctools integration
Comment #3
lyricnz CreditAttribution: lyricnz commentedI can confirm this behaviour. I'll have a look at it now.
Comment #4
lyricnz CreditAttribution: lyricnz commentedThis is caused because the permission being checked during voting (for all users) is 'use vote up/down'. Please add that permission to anonymous users, and let us know if this fixes your problem. There is some work going on in this area, but that should get you going for now.
Comment #5
asb CreditAttribution: asb commentedI think I have this allowed.
Current permissions for "Anonymous user"
vud module:
vud_node module:
Just upgraded to 6.x-2.x-dev from 2010-Apr-23, re-checking:
Greetings, -asb
Comment #6
marvil07 CreditAttribution: marvil07 commentedThanks for the info, but I can not reproduce the problem.
Can you please give us the options you have in
admin/settings/voteupdown/node
?It would be great if you provide steps to reproduce the error from a new vud install.
Comment #7
asb CreditAttribution: asb commentedSettings from
./admin/settings/voteupdown/node
:Steps to reproduce? Sorry, no idea. On my sites it behaves always like this.
It might be relevant that I'm already using 'Voting API' and 'Fivestar' on those sites; maybe 'Fivestar' and 'Vote Up/Down' can not be used together?
Settings from
./admin/settings/votingapi
:Anything else I could check?
Greetings, -asb
Comment #8
marvil07 CreditAttribution: marvil07 commentedOk, I tried the module in a new installed drupal, following the permissions and the configuration options(for vud and vud_node) you mentioned, and also modifying robots.txt, but I'm still unable to reproduce the bug for anonymous.
I also tried installing fivestar and activating it in the same content type I used to try vud and I'm still unable to reproduce the bug.
So, I really do not understand what is happening here.
If you can try to reproduce it in a new drupal at the same environment, please provide all the information about the environment.
Comment #9
asb CreditAttribution: asb commentedOK, I set up a completely fresh Drupal 6.16 site to test this. That's what I got when installing it through 'drush':
At
./admin/reports/status
this gave me a red warning once:Logged out, clicked on the voting widget, logged in again, went to watchdog;
./admin/reports/event/213
says:So basically replicating the voting issue simply 'worked' even on a fresh Drupal installation.
If I understand correctly, anons have per default exactly one vote per day; thus I changed the "Anonymous vote rollover" at
./admin/settings/votingapi
from "1 day" to "Immediately". Logged out; the click on the widget still wasn't counted, but also no error logged in watchdog.During the configuration I stumbled over a setting not mentioned before:
/admin/settings/voteupdown
): Default value is "vote", I changed this to "updown"On the fresh site, I did not change the Voting API tag and hadn't installed other Voting-API-based modules like 'fivestar'. The fresh site also has no 'panels' module installed.
On the old site, I also tried to change this value from the changed "updown" to the default "vote", with no positive effect for the voting of anonymous users (This site is running the 'panels' pages, e.g. on the front page).
Next I switched from the "Alternate" widget to "Default"; this seems to work better on node pages, but not from inside a panels page. Also, these votes with the "Default" widget increased the counter on node pages, but weren't registered when reloading the page. Witchdog logged the usual "Oops! There was an error in submitting your vote!" errors.
The behaviour of panels pages is quite hard to test because several layers of caching are involved (Panels caching is mostly broken at the moment, thus I'm caching through views; also I have several Drupal caches enabled). Caching, oh geez, I'm running APC and memcached on all my sites, maybe even these have side effects. However, the freshly set up site runs on a host with APC, but hasn't memached integrated (no 'memcache' module, but an memcached instance is active on the host, though it shouldn't be used without Drupal integration).
Sorry, that's all I can say for the moment.
Greetings, -asb
Comment #10
lyricnz CreditAttribution: lyricnz commentedThanks for your thorough testing! We will attempt to reproduce from this.
Comment #11
asb CreditAttribution: asb commentedThis is still bugging me (see attached screeshot, excerpt from my watchdog log). Any ideas?
Comment #12
bleen CreditAttribution: bleen commentedI am having a similar issue but for all users (not just anon) ... you can see this in action (via a js popup) when you vote at http://www.techgoesstrong.com/twitter25 (we have simply removed all links to this page from our site so I could keep testing).
At one point everything was definitely working but I'm not exactly sure when it stopped. My suspicion is also memcache which we implemented about 4 weeks ago ... We have a dev environment & staging environment that dont use memcache and this page works fine. Some other similarities to asb's posts include the use of fivestar elsewhere on the site, but I DEFINITELY had both working together at one point.
Any further thoughts?
Comment #13
asb CreditAttribution: asb commented... and we switched to Pressflow a few days ago - #672566: Compatibility with Pressflow
Comment #14
bleen CreditAttribution: bleen commentedI'm 99% sure I found the source of my issue - Akamia (a CDN). On our origin server, vote up|dn works fine, but on out www server (content served through Akamia) we get our error.
Comment #15
userok CreditAttribution: userok commentedFor me the issue lies with surprise, surprise.....IE only. Firefox and Safari don't give me any errors. But if I vote using IE it gives me the same error as described above. IE wont even allow for the voting score to remain permanant after you have refreshed the page either.
I hope someone can confirm this!
Comment #16
asb CreditAttribution: asb commentedSo, I can not confirm this. I'm getting this.
Im geting this for Opera 10.53 (Win):
...and for Firefox 3.6.3:
Greetings, -asb
Comment #17
marvil07 CreditAttribution: marvil07 commentedI finally release a beta1 which includes #807928: Use modal div instead of popup at denying vote and #807934: Let choose vud node view behaviour (no more popup .. kind of related but not so relevant)
In the other hand the error you are getting is on
vud_vote()
, but not sure why you are getting it, but there are only two possibilities: invalid token or not numeric vote. I made another clean installation with the all configuration options you mentioned in a non-cached and in a cached site(normal at admin/settings/performance) and it works fine :-/I suppose I'm going to record a screencast to show how this is working in the next days, maybe that will help
Comment #18
noel.rivas CreditAttribution: noel.rivas commentedIt might be a caching problem.
I have an up/down voting widge on each node of a nodecomment thread. In Chrome, I was getting the error in the messages area. In Safari, not even that. Even for the admin user, votes were not being recorded.
The problem was "solved" by disabling the nodecomments view cache. Voting is working fine now, with the view cache disabled.
Try disabling all caching and see if voting works again.
Comment #19
bleen CreditAttribution: bleen commentedanother possible solution for anyone out there still having this problem ... We had issues when we added some javascript that applied a click event to all anchor tags (in our case it had to do with google analytics). We had to make sure that even was not added to the vote up|dn buttons AND we had to make sure our CDN (akamia) wasn't caching /vote/*
Just one more thing for people to check
Comment #20
idflorin CreditAttribution: idflorin commented6.x-2.0-beta2 with no cache whatsoever and I still get "Oops! There was an error in submitting your vote!"
Comment #21
marvil07 CreditAttribution: marvil07 commentedSince I can not reproduce this problem in drupal, I am marking this as a duplicate of #672566: Compatibility with Pressflow, since that seems to be the real problem and we have a patch there.
Comment #22
rkallensee CreditAttribution: rkallensee commentedI had the same problem - no anonymous votes possible. This started after I uploaded the site to the production server.
I was able to solve it by completely disabling the cache (/admin/settings/performance) - but on sites with higher load this is not an option...
Comment #23
asb CreditAttribution: asb commentedComment #24
marvil07 CreditAttribution: marvil07 commentedI do not understand the reopening without explanation
Comment #25
asb CreditAttribution: asb commentedAre you following the issue queue? There are several new reports not mentioning Pressflow (#20, #22), one immediately before and one after you closed the issue. Also I'm getting this on non-Pressflow sites, so I can't see why #672566 would be "the real problem". I documented this months ago with a fresh Drupal 6.16 (#9), and this sandbox had definitely nothing to do with Pressflow.
Besides this, #672566 doesn't fix the issue on my Pressflow sites, either.
I understand that you as a developer need a procedure to reproduce the posted isssues, but simply ignoring the queue and closing the issue as "duplicate" doesn't help anyone. If this can not be fixed, I suggest to set this to an honest "won't fix".
Comment #26
marvil07 CreditAttribution: marvil07 commentedI am. I also tried to reproduce it several times(#6, #8, #21), but I end up with the conclusion that this is a duplicate of #672566: Compatibility with Pressflow because on that issue we also fixed a general problem about normal caching(not related with pressflow), and here caching is mentioned several times.
I see them, but both of them are from a date before the last commit in #672566: Compatibility with Pressflow gets in, so they are not really valid since they do not have the fixes yet in that moment.
I did not try to ignore this, specially since I tried it three times from scratch.
I am trying to do my best effort helping here, so please stop making those comments, please remember the context we are in(a developer community that want to help as best as it can). I consider your comment not really useful, only aggressive and harmful.
I am moving back the status to needs more info, hoping someone can help me again to get specific steps on a new isolated installation(no other modules installed), so I can really trace the problem again. Please use the last code on 2.x branch for this.
Comment #27
lyricnz CreditAttribution: lyricnz commentedIf someone can explain how to reproduce it, I'll write a testcase for it, so we can fix this once-and-for-all. Simpletest ftw!
Comment #28
marvil07 CreditAttribution: marvil07 as a volunteer commentedClosing D6 issues, D6 releases are not supported now.
Please reopen as D7 if needed.