Unflag links are "randomly" disappearing from block view for Anonymous users with page caching turned on

I dont' exactely now but drupal doesnt have sessions for anonymous user so flagging wont really work. Does flagging work if you have the caching disabled?

Flag does work with both anonymous users and page caching enabled. It gives anonymous users a cookie to store which content they have flagged, then uses JavaScript after the page has loaded to swap out all the "Flag" links with "Unflag" links for content they have already flagged.

We'll need more specific instructions on how to reproduce this problem. There's likely a pattern here that can be reproduced at will, right now saying "some pages work but others don't" isn't very helpful.

Maybe this is related: #986840: Removing flag for anonymous users returns error: javascript and cookies disabled

It's probably not related.

Is there a place to start debugging this?

Yes.

First, here's a description of how Flag implements anonymous flagging:

1. The HTML document the server sends your browser contains only "Flag this!" links (when you're anonymous). Surprise!
2. But this document also contains, in a JavaScript array (Drupal.settings.flag.templates), a rendition of every possible "Unflag this!" link.
3. A cookie in your browser keeps a record of all the content IDs you've flagged.
4. JavaScript code then runs: it reads the cookie and for each content ID replaces its "Flag this!" link with the "Unflag link!" link from the aforementioned JavaScript array.

(Nate basically explained this in comment #2.)

Now,

You say:

the unflag link is not displayed

This means that the problem is in step #4. Because if we omit this step the page will be full of "Flag this!" links. (Verify this: disable JavaScript and refresh the page.)

And it probably means that Drupal.settings.flag.templates doesn't contain a rendition for all the links. In other words, some "Flag this!" links are replaced by a null string.

We update the block via AJAX using the Component module

Perhaps your setup doesn't merge the new link renditions into Drupal.settings? This seems the likely reason. On the other hand, you say "[w]e eliminated the Component module as a possible reason, because the links are not present even after a full page reload."

Whatever, to get you started hacking, locate this line...

$('.flag-' + flagName + '-' + contentId, context).after(Drupal.settings.flag.templates[flagName + '_' + contentId]).remove();

...and add the following code before it:

if (!Drupal.settings.flag.templates[flagName + '_' + contentId]) {
  alert('Item #' + contentId + ' is flagged, but I wasn't told how its unflag link looks like.');
}

2. I disable javascript, and refresh
-- the on page Link still reads "unflag this"
[...]
4. I disable javascript, and refresh on the same different page
-- the unflag link is there,

(This seems to contradict what I said earlier, that the page the server sends contains only "Flag this!" links, but it might be that we have a bug in that mechanism as well. However, it's unrelated to the "disappearing links" we're discussing in this issue, so for the time being it's best to ignore it.)

=======

3. I navigate to a different product
-- the unflag link in my block is gone (table cell is empty)
[...]
5. I enable javascript, and refresh on the same different page
-- the unflag link is gone (table cell is empty)

Do "View Source". Do you see a "rememberme_XYZ" entry in the Drupal.settings.flag.templates array? (replace "XYZ" with the content ID of the item whose link is gone).

-- the link returns an error because it misses the has_js=1 querystring

(That's a different issue altogether. (You may ask how come we have so many bugs in our module. It's a good question. I guess it could be explained by the Bicycle Shed example: since the anonymous flagging feature was relatively big it might have got a light inspection only.))

(I think I know what the problem is.)

"flag": { "anonymous": 1, "templates": { "rememberme_812":

But I am on node/812 !!!

This part is actually fine: When Flag is asked to print the flag link (whatever the status of the item: flagged or not), it prints the "Flag this!" version of it and it also adds the "Unflag this!" version of the link to the JS array.

the unflag link for node/360 [which is in] the block [is missing].

That's the only problem: the JS array doesn't contain the renditions for the links you have in your block.

And I suspect I know what's the problem: are your blocks cached? Go to your "admin / performance" settings page (I don't know the exact menu path) and turn off caching for the blocks. (Drupal has several levels of caching.)

Because if the blocks are cached, there are times when Flag isn't actually run when they're called for and it doesn't have a chance to add the renditions to the JS array. (We'll think of a workaround later; first let's verify that's indeed the problem.)

(I'll try to check that next week.)

(BTW, turning on a block that runs a view involving some anon flag [is supposed to] turn[s] off the caching for that page. So eventually you'll instead want to fetch the block/view in an onload JavaScript event.)

OK, I found the problem. I opened a new issue:

#996700: Anon flagging: Views may make some flag links "disappear"

(There's another bug that awaits a fix, #996710: Anon flagging: Output of "flag this!" links only isn't enforced)

HOWEVER, as I mention in #13, you shouldn't turn on the block of this view because it will turn off caching for the page (it's a feature, not a bug; because otherwise anon users will see the (stale) state of some other anon user). You don't want this to happen: you want page caching. So instead you'll have to display the block using JS: pull it from the server in the page's onload event.

(Tip: add "<? print 'Time: ' . date('H:i:s', time()); ?>" to your page.tpl.php to know whether the page is cached or not: if the time is current you know the page isn't cached (because, e.g., a view turned caching off (as it should!)).)

Jochen, this isn't quite a bug.

Flag (and many other modules) tell themselves where they need to redirect after they complete some operation (this is usually used only when JS isn't used: either when it's disabled or when using the right mouse button). They default to the path of the "current page". Which is actually the path of the HTTP request being currently served. In your case, since the request is "component/block/...", it's the destination.

You need to override this destination:

    $view_name = 'rememberme-block_1';
    $remember_me_fetcher = url('component/block/views/' . $view_name, array('query' => drupal_get_destination()));
    drupal_add_js(array('jochen' => array('remember_me_fetcher' => $remember_me_fetcher)), 'setting');

    drupal_add_js('
      $(document).ready(function() {
        $.get(Drupal.settings.jochen.remember_me_fetcher , function(data) {

(I may have typos here.)

(I'd move the drupal_add_js() snippet into a JS file (You probably have one anyway if you're using our JS API to refresh things upon flagging).)

(You're welcome. Note that I updated my reply to use Drupal.settings (mainly to make it possible to move the JS into its own file). You may have missed it if you read it before I updated it.)

Patch #986840: Removing flag for anonymous users returns error: javascript and cookies disabled does not seem to work with above AJAX pulling on pages that have no flag links.

Mmm. That's right. To fix this, add "Drupal.settings.flag.anonymous = true;" to your JS (before the call to Drupal.attachBehaviors). This will tell Flag's JS (the anti-crawlers mechanism) that it needs to kick in.

(Ideally, the 'Component' module should merge whatever JS settings were generated during the page request into the page's Drupal.settings.)

To fix this, add "Drupal.settings.flag.anonymous = true;" to your JS

On second thought, this will result in JS error because the '.flag' slot doesn't exist.

So, instead, add this to your PHP:

if ($GLOBALS['user']->uid  == 0) {
  drupal_add_js(array('flag' => array('anonymous' => 1)), 'setting');
}

Indeed. I started a doc page:

Technical notes about "anonymous" flaggings

Feel free to edit it.

(Note: I added a note about efficiency. Search that page for "@todo".)

I've fixed two more bugs related to anon flagging. It will probably take a couple of hours before it's reflected in the 'dev' release. Please use it (in a few hours) and let me know if you encounter any more problems.