(I'm opening this for 6.x, as this is the only version where I'm able to test and roll a patch. My testing environment is not able to run 7.x yet, due to old MySQL version, so someone else is needed to forward-port to 7.x if needed.)

Summary: The Most recent poll block depends on current user viewing the page, rendering either the vote form, or results, depending on whether the user already voted or not. Currently, it's cached per-role, which is wrong. Also, the cache is not flushed on cancelling a vote. This patch fixes that, and adds update function to reflect the new caching mode to {blocks} table.

How to reproduce:
- Enable poll module, enable the Most recent poll block, create a simple poll.
- Enable block caching
- Create two users A and B (other than uid 1), with the same role, having poll module's permissions enabled.

- Log in as user A. Observe the voting form in block, and cast a vote. See how the block correctly changes to vote results.
- Log in as user B, who didn't vote yet. See the incorrect display of vote results in the block cached per-role from previous user A's visit.
- Flush block cache manually, reload the page, observe correct display of vote form in the block.
- Cast a vote. (The block changes to results correctly.)
- Go to the poll as full node (page), and click "Cancel my vote".
- See how the node page changes back to voting form (correctly), but the block stays (incorrectly) as outdated vote results (because the cache didn't get flushed).

The fix: Poll module lacks a caching mode definition on the block. It should be BLOCK_CACHE_PER_USER quite obviously. Also poll_cancel() lacks cache_clear_all() similar to its vote-casting counterpart. The patch just adds that.

Also there's update function, modelled after system_update_6047(). However hard I try, I didn't find a way to rebuild {blocks} information from (changed) definition in hook_block() - I tried:
- flushing all caches from Performance page
- disabling and enabling poll module
- submitting Blocks page
None worked. Unless I manually delete the block from {blocks} and then re-enable it from blocks page, stale caching data stays in DB - this might be another bug, but unrelated here. For now, the update function fixes the change.

CommentFileSizeAuthor
#20 poll_disable_block_cache.patch459 bytesEugene Fidelin
#19 poll_disable_block_cache.patch407 bytesEugene Fidelin
poll-block-cache-D6.patch1.49 KBJirkaRybka
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

JirkaRybka’s picture

JirkaRybka CreditAttribution: JirkaRybka commented
Version: 6.x-dev » 7.x-dev
Status: Needs review » Needs work

Seems like not much attention, due to 6.x version probably. I can't really test 7.x on my environment (yet), but looking at the code, I believe the same problems are in there, too.

Setting to 7.x CNW, as someone is needed to forward-port the patch to 7.x, before it may be fixed in 6.x too. The port should really be just minor cleanup inside the patch, as I believe that poll.module is nearly identical in both the versions (apart from DBTNG and such Drupal-wide stuff).

steff2009’s picture

steff2009 CreditAttribution: steff2009 commented
Version: 7.x-dev » 6.15

I have exactly the problem you describe.

I still run Drupal 6.x an in my site it is not possible to vote from the Most Recent Poll block: after an anonymous user voted the first time, now the block only shows results to everybody.

It is possible to vote only by clicking on "Older polls", which redirects to the Polls page where choices appear.

I'm not an expert, but I would like to apply your patch: is there a way I can do it myself?

Thank you.

JirkaRybka’s picture

JirkaRybka CreditAttribution: JirkaRybka commented
Version: 6.15 » 7.x-dev

The 6.x patch is in the initial post here, and instructions how to apply a patch are somewhere in the documentation ( http://drupal.org/patch/apply ), or in the worst case you can just replicate the changes by hand in your copy of Drupal (always keep a back-up copy). It'll go away once you upgrade to a newer version, though (as that involves replacing the files with fresh new ones).

This issue here aims to get the fix included into a new Drupal release, which is required to go into the most recent version first (so resetting this thread to 7.x, although I can't currently do more in that direction).

steff2009’s picture

steff2009 CreditAttribution: steff2009 commented

Hi, thank you.

However I do not have access to the server, as I'm running my websites on a commercial host - so the patch instructions are not applicable to me. Should I want to replicate the changes manually, which files exactly in the poll module folder do I have to amend with the new code?

I also have another question: I don't like the IP addresses of poll voters to be displayed in the page "Votes". I believe this is against users' privacy (some of my users have also complained). Besides, Google does not appreciate direct relations between websites and personal information like IP addresses.

If I do not allow anonymous users to inspect votes through Admin > Users > Permissions, then they get a "You are not authorized" message when they click on the link. I just want the IP not to appear: how can I achieve that?

Thank you so much again for your support.

JirkaRybka’s picture

JirkaRybka CreditAttribution: JirkaRybka commented

In the patch file, there are headers mentioning the files - the first part is about poll.install, but it might be better to skip that and just execute the query manually in PhpMyAdmin, so that you don't add new update functions that are not in official release. The second part is about poll.module

No access - I haven't full access too, but there's no problem to download - then patch - then re-upload. As said, such trivial changes are easy even with a simple text editor.

The IP addresses part is another issue, maybe you should open one.

steff2009’s picture

steff2009 CreditAttribution: steff2009 commented

Hi, there is a post on hiding IP address of the poll module http://drupal.org/node/422676 but unfortunately nobody has replied!

Thank you.

gregarios’s picture

gregarios CreditAttribution: gregarios commented

I am having the same issue with poll block caching and cross-user inconsistencies in Drupal 6.1x. Subscribing.

venusrising’s picture

venusrising CreditAttribution: venusrising commented

Same issues. why does this Poll module suck so bad?

JirkaRybka’s picture

JirkaRybka CreditAttribution: JirkaRybka commented

BTW - another one is deletion of user account that voted in a poll, where the uid is set to anonymous, but no IP address recorded. If you delete ANOTHER user account that voted on the same poll, you have a duplicate index error in database layer. Strictly taken, I should open a new issue for that, but it's really not worth the trouble, given how no-one works on poll module.

ndstate’s picture

ndstate CreditAttribution: ndstate commented

sub

rich.3po’s picture

rich.3po CreditAttribution: rich.3po commented

Further to this, it seems the problem will persist unless you disable caching for the page on which the block appears, although i find it quite incredible that the block caching system can be this fundamentally flawed...

See: http://www.drupaler.co.uk/blog/page-and-block-caching/114

Thanks for the post btw

gregarios’s picture

gregarios CreditAttribution: gregarios commented

I've gotten completely around the block caching issues with the following method, for the original version this post was created for anyway, Drupal Version 6.x. It may work with 7, too:

1) Create a file in your theme folder named get_jqblocks.php containing the following code:

<?php
$drupal_path = "../../../../";
chdir($drupal_path);
include_once './includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
$block = module_invoke('poll', 'block', 'view', 0); print $block['content'];
?>

2) Create a block containing the following code, and place it wherever you want the poll-block to appear on your site. Remember to substitute the correct directory name for your theme in the <your-theme> spot:

<div id="latestpoll"></div>
<div class="clear-block"></div>
<script type="text/javascript">
//<![CDATA[
$('#latestpoll').load('/sites/all/themes/<your-theme>/get_jqblocks.php');
//]]>
</script>

Let me know if this works for you, or if I've forgotten to give you some crucial part of it -- it was a while ago I did this so I may have forgotten a step, but I'm pretty sure that's it. Oh, you need JQuery on your site for this to work of course. It even gets around Boost caching problems.

JirkaRybka’s picture

JirkaRybka CreditAttribution: JirkaRybka commented

rich.3po: If I understand right, you still have the problem after applying the patch. That's because caching info in blocks table is never updated in core, and that's why the patch includes also update function (that needs to be run through update.php, but you'll be better off to execute the query manually, so that you don't mess with updates numbering in your install - you see, the patch is a proposal for core inclusion, not a ready solution for users).

gregarios: Sorry to say that, but this is really a dirty hack, and please note that this place is not a support forum for sharing workarounds - this is a core issue (or "ticket" as some call it) aiming for a proper fix to the bug in core.

gregarios’s picture

gregarios CreditAttribution: gregarios commented

this is really a dirty hack, and please note that this place is not a support forum for sharing workarounds

Actually, your solution is more of a "hack" by Drupal standards than mine, since it changes a core module of Drupal. I was just offering an alternate solution that actually works. Good luck with the patch.

JirkaRybka’s picture

JirkaRybka CreditAttribution: JirkaRybka commented

Actually, your solution is more of a "hack" by Drupal standards than mine, since it changes a core module of Drupal.

You misunderstood the purpose of this place (i.e. core issues), I'm sorry to say. This is where core modules are created, improved and fixed (by proposals/patches like this one being discussed, improved, and included into next core release in the end, or declined if that's the decision). Proposing a fix for inclusion into a core module, that works around the bug through abuse of theming and javascript, rather than actually fixing the module, is not the preferred way here. I see that you were not really proposing a fix for core inclusion, but in that case you should've gone to the support forums instead, rather than sidetracking the discussion here. No offense meant, I'm just trying to resolve the misunderstanding here.

rich.3po’s picture

rich.3po CreditAttribution: rich.3po commented

Jirka:

To clarify, the problem still persists even after applying your patch and running the update SQL. The reason is that the block caching scheme is ignored (or at least appears to be) when global page caching is enabled.

The only workaround i could find was something like this:

function hook_init() {
	if (drupal_is_front_page()) {
		// Disable caching on this page
		$GLOBALS['conf']['cache'] = false;
	}
}
JirkaRybka’s picture

JirkaRybka CreditAttribution: JirkaRybka commented

If there's not another problem I'm not aware of, we have two levels of caching: Block cache AND page cache. Blocks are cached (by role, by user, whatever), and THEN the entire page might be cached for anonymous, bypassing the rest on reloads (which may look like a setting didn't work / was ignored, but actually "doesn't apply" or "code doesn't run" is more exact description). The bug discussed here is a wrong mode in relation to block caching, causing various authenticated users to see each other's cached blocks, which they shouldn't in this case.

Page caching is entirely different matter, it's whole concept is based on assumption that all anonymous pages (with exceptions like POST data, messages etc.) are uniform across anonymous audience. If you allow anonymous users to vote (which I never tried, in fact, seems like bad idea in my use case), you might get in trouble with page caching - which (if happens) would be non-trivial to solve in poll module, it's just incompatible with page caching. It would be a completely different bug, with a different solution. (I seem to recall vaguely, that problems of poll module with page caching and anonymous voting were mentioned years ago, already, but I didn't follow the topic later.)

I'm just trying to keep this issue focused, in hope that the fix will make it into core eventually (which is unlikely, if it gets sidetracked).

caktux’s picture

caktux CreditAttribution: caktux commented

This patch might fix the issue for blocks, but I've also had cache troubles on poll pages with anonymous users. The workaround was using CacheExclude for those pages... In other words, subscribing...

Eugene Fidelin’s picture

Eugene Fidelin CreditAttribution: Eugene Fidelin commented
FileSize
poll_disable_block_cache.patch407 bytes

If you want be sure that anonymous users can vote and see results using "recent poll" block - then the easiest way is to disable caching for this specific block.

Here is the patch for D7

Eugene Fidelin’s picture

Eugene Fidelin CreditAttribution: Eugene Fidelin commented
Status: Needs work » Needs review
FileSize
poll_disable_block_cache.patch459 bytes

Updated patch with correct paths

ivnish’s picture

ivnish CreditAttribution: ivnish commented

I confirm this bug. I have strange redirect after anonymous vote in poll