When cache is enabled anonymous users can see the comment controls but using them results in nothing (or just web traffic). Maybe if the user then visits uncached node this will result in inconsistent comments view for all guests, but I have not tested this.
Since there's no setting about this in the access control page I 'hacked' the comments.module. Please check the attached patch, which works for me.
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | drupal-6.0-beta3-comment_anon_cache.patch | 493 bytes | nkruby |
| #13 | drupal-5.2-comment_anon_cache.patch | 608 bytes | nkruby |
| #6 | comment_ctrls_cache_50_1.diff | 1.47 KB | pwolanin |
| #5 | drupal-4.7.4-comments-01-controls_visibility_for_anon_and_cache-1.patch | 806 bytes | mr700 |
| drupal-4.7.4-comments-01-controls_visibility_for_anon_and_cache.patch.txt | 738 bytes | mr700 |
Comments
Comment #1
dries commentedAnonymous users should be able to control the comment settings. If they cannot, then that is a bug/regression. Disabling the settings for anonymous users is the wrong solution -- unless we're all OK with dropping support for that. If so, we can probably clean up a bunch of code.
Comment #2
mr700 commentedDries, I think you missed my point. I was talking about the situation when the cache is enabled. Without cache you are right, but with cache enabled all anonymous users are getting the last cached page. If every anonymous user is able to control the way the comments are rendered, then there's no point of caching any page... every anonymous user should have his own personal page cache (the page cache caches the comments on the page too, right?).
To see what I mean try this: Ignore my patch and install a new drupal somewhere. Write a page, put 2 comments and turn on cache. With this setup try as anonymous user to change the comment settings on the page (I am not able to with 4.6 and 4.7).
Comment #3
killes@www.drop.org commentedmr700: I agree with your assessment, but I move it to the right place.
Comment #4
drummThe nested ifs can be merged into one line with &&. Use
global $user;and$userinstead of$GLOBALSComment #5
mr700 commentedOk, fixed, updated for 4.7.5 and added a short comment.
Comment #6
pwolanin commentedpatch needs to be for HEAD first- see attached. Using the 5.x #access element in this case for the form.
Also, there is a second spot where this condition needs to be checked (I think) : function _comment_get_display_setting()
This is also in this patch.
Tested with the latest HEAD and I think I got the boolean logic right after a couple tries ;-)
Comment #7
moshe weitzman commentedpretty simple. i have no idea why it took us years to find this bug. i guess anon users are used to stuff not quite working.
Comment #8
dries commentedThis used to work for anonymous user. Either way, this needs a code comment. This also needs to be documented for administrators.
Comment #9
mr700 commentedOT: another thing that does not quite work for anon users when cache is enabled are polls (the block)...
Comment #10
pwolanin commented@Dries - can you please be more specific about what/or where else there need to be code comments?
As far as letting admins know, do you mean, for example adding text at /admin/content/comment/settings under the "Comment controls:" radios?
Comment #11
Uwe Hermann commentedStill valid in 5.0. I can reproduce this on my site, see http://www.hermann-uwe.de/blog/upgraded-my-website-to-drupal-5#comment-4....
Can this be fixed somehow even when caching is enabled? Otherwise admins are forced to choose between working comment settings and better performance through caching...
Comment #12
catchversion change.
Comment #13
nkruby commentedThe following patch enables anonymous users to control comment layout when page caching is enabled.
After the patch is applied, the comment_controls_submit function will add the control parameters to the URL (only for anonymous users if page caching is enabled). The effect is that all combinations of comment controls will be cached as separate page entries. This could lead to a large number of the same page being cached, however - but we think it is a viable solution.
The patch is made against Drupal 5.2
Thanks :)
Comment #14
catchThis needs to be applied to 6.x then backported. Could you re-roll against that release?
Comment #15
nkruby commentedThe following patch is for drupal-6.0-beta3
Comment #16
catchComment #17
westbywest commentedIs there a corresponding bug report for v5.x-dev or any other 5.x versions of comment.module? This thread includes patches for v5.2 and for v6.0beta3, but the current stable release of Drupal core (including comment.module) is now v5.5. Perhaps I'm not familiar enough with Drupal's issue tracking system, but it looks like the v5.2 patch has not been selected for integration into Drupal core v5.x.
Comment #18
catch@westbywest
All changes to drupal core happen in the development release - which is 6.x
If it's fixed in 6.x there's a chance it will be backported to 5.x (so maybe included in 5.6) - assuming it's the kind of change that won't break something else.
So the only way you'll see this fixed in 5.x, is if someone tests the patch for 6.x at http://drupal.org/node/101013#comment-643909
instructions on how to apply and review patches are at http://drupal.org/patch
Comment #19
Rico Heart commentedSubscribing
Although it would be better if the comment controls worked even if caching is enabled.
Comment #20
thedavidmeister commentedDefinitely fixed in 8.x, must be a duplicate of something that happened in the past 7 years.