Intermittent dropdown due to block caching

Check /admin/user/permissions under addtoany module. I suspect that "view addtoany" is disabled for anonymous users.

I have the same issue:

permissions are set for anonymous users to see addtoany.
Problem is only using it in a block, in content everything works fine.
The button is shown, the "dropdown" menu is not.

Workaround was: deactivating the block, clearing the cache and reactivating the block and clearing the cache again solved the problem for now.
But I can not say if this(caching) was the problem, because I'm almost sure, that I cleared the cache several times since activating the block....

Problem keeps coming back.

Again the menu doesn't show for anonymous users unless I clear the cache first.
I suspect that might have to do with caching of the javascript-files?! Because the menu is renderd via a javascript-call, no?

same here.
check out what I read on http://drupal.org/node/362722#comment-2232772

sometimes it makes sense.

I'm having the same problem. Chromium 5 and Firefox 3.5, with AddToAny in a block. There are no JS warnings or anything, just the menu fails to appear for anonymous users.

Updating the role access for anonymous fixed the issue for me.

Same problem for me. I installed addtoany and print modules. Both have the same behaviours.
If I flush all caches, this will work on the first page visited but not on the next one. If I save again the settings for one or the other module, this will have the same effect on the drop down behaviors.

I have noticed that the CSS and js list are not the same when the behavior is correct or when it's not (check the prints screen)

This behaviour happens only if the module is used as a block (see the settings page)

Hope these information will help to find a solution :)

Thank you,
Julie

(Sorry for the bad english)

Here is a partial solution:
In the page /admin/settings/performance, disable the block cache.

This seems to still be a problem in 6.x-3.x-dev as of july 6th. disabling block caching seems to fix the problem at first glance.

Interesting, because the following line was placed in addtoany.module to hopefully resolve this issue:
$block['cache'] = BLOCK_NO_CACHE;

With this, the AddToAny block should not be cached. Can anyone shed some more light on this issue?

No dropdowns for me either.
Tried latest release, and dev.
Tried all browsers.
Disabled block cache.
Nothing works.

@marcjohnson, is it just Anonymous users that cannot see the drop-down menu, or everyone? If you can't get the menu to display at all on your site, please post a new support issue and we'll go from there.

I've updated to 3.3 and this problem is still there. Anonymous users don't see the dropdown menu if block caching is enabled. Works as advertised if Block Caching is disabled. Here's more info if it helps...

My dropdown menu is at the bottom of the page so technically for me it's a drop-"up" menu. It's in a "content bottom" block, center-aligned within the container (skinr/fusion).

Drupal 6.17
AddToAny Share/Bookmark Button 3.3
Theme: Acquia Prosper 6.x-1.0-beta4 (skinr/fusion)
Fusion 6.x-1.0
Skinr 6.x-1.5

admin/settings/performance settings:
caching mode: normal
min cache lifetime: none
page compression: disabled
optimize css: enabled
optimize javascript files: enabled (is addtoany's js "optimized" by this?)

A final clue. This may be unrelated, but the dropdown-less addtoany button sometimes seems to show the wrong page from my site in the link. As if caching is confusing addto any as to which page it is currently on.

This may be related to http://drupal.org/node/235673

Similar problem to the others noted here. But from my testing, it is not anonymous vs logged-in, but depends on the order of changes.

Briefly, I have add to any in a fixed region as a block.

Here is the logic I have discovered (on Chrome and Firefox, not checked on IE):

If it works and I log in, it works. If I then log out, it will stop working. If I then clear the drupal caches (all of them), it works again. If I log in, it still works, but when I log out it is then per above.

Seems that this is an upstream core issue as pointed out by toomanypets:
#235673: Changes to block caching mode not caught

Please post if you know of a better solution than the already implemented "BLOCK_NO_CACHE". Thanks!

subscribe

Subscribing. The dropdown doesn't work for me either using the AddtoAny View Link.

Updating to the dev version didn't help. Block cache isn't causing the issue for me as it was never enabled.

+1 I am having the same issue. Sometimes the dropdown will appear, but it links to the wrong page. It depends on the first page I was on when activating the addtoany button (by mousing over it). After doing this the first time on a page since opening the browser, the addtoany link refers to that page no matter what other page I go to. Only until I clear the sites cache does the addtoany link refer to the right page (but then it constantly refers to that same page unless I clear the cache again).

Any updates on this?

subscribing

+1 The dropdown doesn't work for anonymous user

as for title.. my block is not being cached yet on some pages dropdown does not work.

If anyone subscribed could provide a link to a site that demonstrates the issue, that would help a lot.

You can try my website, adambadlotto.com. Click on 'work', then click on any of the thumbnails. At the bottom of the next page will be the addtoany share button. Sometimes the dropdown appears and sometimes it doesn't so you may have to click around a few times for the problem to occur.

@thrash632 I couldn't get your drop-down menu to appear at all. Viewing the source code (of this page of yours), your issue seems to be that the module JavaScript code is not outputting in the footer/closing area. This necessary output should have a number of lines including da2a.html_ready = true;

Check out #447512: No dropdown (due to missing $closure variable in theme) to see if your theme's page.tpl.php needs the required $closure variable.

I checked the bottom of my theme's page.tpl.php and here is what I found:

print $page_closure;

print $closure;

It's already printing the closure variable. I am using a custom theme made from the zen theme. I a tried the module using the Garland theme and it worked fine. I'm not sure what could be causing the problem. Any ideas?

For people who have already created an addtoany block, they also will have to manually set the addtoany block cache to -1 on the their SQL db. This will make the BLOCK_NO_CACHE working.
On your db run: update blocks set cache = -1 where module = 'addtoany'

The attached patch fixes the issue, which is that the caching for the blocks was in the wrong section of hook_block. Additionally, this creates an update function to fix it in existing sites, as you must change the {blocks} table as pointed out by jlbretton once the module's been enabled.

Same issue: Doesn't matter if user is logged in or anonymous, the drop-down does not function within a block. It works fine if I include AddToAny within page content ... just not in a block.

- Disabled block caching
- DB shows cache set to "-1"
- Applied patch, with errors:
> patching file addtoany.install
> patching file addtoany.module
> Hunk #1 succeeded at 7 (offset -1 lines).
> Hunk #2 succeeded at 17 (offset -1 lines).
> Hunk #3 succeeded at 28 (offset -1 lines).
> Hunk #4 succeeded at 44 (offset -1 lines).
> Hunk #5 succeeded at 76 (offset -1 lines).
> Hunk #6 FAILED at 124.
> Hunk #7 FAILED at 146.
> Hunk #8 FAILED at 178.
> Hunk #9 FAILED at 200.
> Hunk #10 FAILED at 215.
> Hunk #11 FAILED at 231.
> Hunk #12 succeeded at 273 with fuzz 1 (offset 30 lines).
> 6 out of 12 hunks FAILED -- saving rejects to file addtoany.module.rej

Drupal v.6.21-dev
AddToAny v.6.x-3.4

@aaron you are right about caching info being at the wrong place. See

http://api.drupal.org/api/drupal/developer%21hooks%21core.php/function/h...

Not sure I see the use of the rest the patch though, as just changing that one line fixed my site.

Here is a simpler patch.

Instructions:

(1) make sure you are running 6.x-3.4 or 6.x-3.x-dev version of this module
(2) apply enclosed patch
(3) clear all you caches

This issue seems to still be happening, with 6.x-3.x-dev as of today (2013-09-13). Is the patch in post #34 in the current dev?

This issue seems to still be happening, with 6.x-3.4 as of today (2013-10-16). I've emptied my cache. I have not manually set the addtoany block cache to -1 on my db as mentioned in #31 above.