Hey guys,

This seems like a fluke issue I'm having, so I haven't bothered posting this until today. I have spent a third weekend in a row trying to figure out why in the world anonymous visitors cannot vote, and I give up.

We have a "Daily Poll" on our front page, using the mostrecent block (admin/build/block/configure/decisions/mostrecent), and it averages 250-300 votes every day. On precisely November 23, this number dropped to just 27 votes, and since then we haven't seen more than three dozen votes in a day.

If I open a new browser, or use my iPhone, as a visitor not logged in, all I see are the results of the poll. I am no longer presented with the option to place a vote. Once I log in then I see the poll options and I may vote.

There are no role restrictions on the block itself
I haven't made any changes to our permissions, and guests have permission to vote
I rebuilt node access permissions (admin/content/node-settings), no change
I disabled all performance options (admin/settings/performance) including caching, no change.
I've emptied block cache tables and all other cache tables, no dice

I installed AJAX Blocks (drupal.org/project/ajaxblocks), which is totally awesome, and I played with all the options of loading the mostrecent block on cached and uncached pages, still no change.
I moved the block to a different page and even to a different theme on our website, no change.

Last night I had the idea to look back at the vote history, find out what date the votes dropped, and then check what modules have been updated since then. That is when I discovered things were normal up until Nov 22nd, and then they took a serious dive starting with Nov 23rd's poll.

According to datestamps on our server, I've only updated two modules since 11/22:
mimemail (11/22 - updated from 6.x-1.0-beta2 to 6.x-1.0)
decisions (12/7 - updated from 6.x-1.7 to 6.x-1.x-dev to see if it would fix the problem, it didn't)

I did update mimemail the day before this issue started, but how could mimemail have anything to do with persmissions/caching and preventing anon users from voting?? So I just updated mimemail to the newest dev version, made no change as expected.

Has anyone else recently started having issues with anonymous voters?

Thanks
Mike

Comments

BigMike’s picture

BigMike commented

Ahhhh this may also be a PHP 5.3 issue. I forced a full cPanel update a few weeks back, can't recall when exactly. Ever since I've been getting this error:

warning: Parameter 1 to profile_load_profile() expected to be a reference, value given in /home/sitename/public_html/includes/module.inc on line 461.

Could this be another Namespace collision?

This is a sticky one

BigMike’s picture

BigMike commented
Status: Active » Fixed

Ok guys, I got really upset over this and dove into the decisions module and I _finally_ figured it out.

The decisions module checks anonymous voter's IP address, and only allows 1 vote per IP right? Well, I installed Nginx awhile ago, clearly it must have been on the 23rd of Nov, which is a PROXY -- and I just learned that server proxies replace the user's IP address (for instance $_SERVER['REMOTE_ADDR']) with the IP address of the proxy.

Therefore, when the first anonymous visitor of each day comes to the site, and places his/her vote, the Decisions module sees that the IP address of the user proxy! has in fact already voted and therefore the user is no longer able to vote (based on the function _decisions_can_vote on line 871 of decisions.module). This effectively locks out all other anonymous voters for the remainder of the day (or the vote's active duration).

Here is what I did to figure this out:
1) Carefully reviewed decisions.module
2) Removed the check to see if $node->vote is empty (line 874)
3) Wa-la anonymous voters suddenly were able to vote
4) Called print_r($node) from my page.tpl.php to see what $node->vote looks like, but of course I don't want just any anonymous visitor to see this, so I added a check to only allow my machine access (if($_SERVER['REMOTE_ADDR'] == 'xxx.xxx.xxx.xxx') { print print_r($node); }, using my IP number) and suddenly I discovered that $_SERVER['REMOTE_ADDR'] was in fact NOT my IP number!
5) Searched Google to see if I was using the wrong PHP command to get my IP number and I learned that this only works on servers without a proxy!!
6) Uninstall Nginx and KA-POW it starts working.

SHEEEEEEEEEEESH. What a mess :'(

Therefore, I have learned that the Decisions module is not compatible with servers operating through a Proxy.

I am marking this as fixed but not closed because ultimately this needs to be addressed so other people can use the Decisions module with a proxy, or the maintainer needs to update the project page to let others know that it is not compatible.

Regards,
BigMike

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.