The share buttons seem to be caching their choices along with the standard website cache. In other words, if I have several articles written and I share the "New Website is here" article, everything is fine. But when I move to another article, let's say, "The weather was great today," when I click on the share button, it brings up the URL data for the previous share instead, ie. "New Website is here."
The only way to resolve this behavior is to flush the caches. This obviously isn't going to work when tens or hundreds of people visit the site and attempt to share certain articles.
The share buttons should not cache their results, or, there needs to be a way to turn off caching of button choices.
PS: I am using the block for sharing, not the content field. However, I have activated the field in structure/content types, but chose not to activate the field. Could this be causing the buttons to cache choices?
Comments
Comment #2
zoon_unit commentedOkay, it appears that block caching is the issue. Even if I turn off all caching, the behavior persists with the share block. It remembers the last share regardless of the page I'm on at the time.
However, if I activate the share FIELD and place it at the bottom of the display, the content share buttons work as intended whether I have caching turned off or not.
In a bizarre situation, with both field level sharing and block sharing turned on, the field share will display the proper url, while the block share will have the "previous old" url showing.
I guess the workaround is to only use field level sharing, but this is a critical flaw and needs to be fixed asap.
Comment #3
zoon_unit commentedComment #4
adamps commentedThanks for the report, that's useful information.
NB v8.x is not yet ready for production use. Check out the status on this issue. All our testing so far has been on dev sites, and one of the major remaining items to do is to test caching.
The D8 port is a community effort and the two of us already working on it are giving our time for free. It will be ready when it's ready. We welcome any help which will speed things along. Patches very welcome. Your continued tested with caching enabled is also very welcome, please keep sending in bug reports. Also feel free to join the D8 issue above and list what areas you have tested.
Comment #5
zoon_unit commented@AdamPS, your time is greatly appreciated! I used your buttons in production, or would have been forced to go with another product. Took the gamble on the dev version, after initial testing. Had to drop addtoany because it doesn't render shares properly on Facebook. Plus, it's slow.
The good news is, except for the caching issue, the rrssb module seems to work beautifully on a live site. Facebook and Twitter appears to scrape the page properly, (as long as metadata is setup) which addtoany couldn't accomplish on a live site. :-(
The workaround for the moment is to use the field level buttons, which don't seem to be affected by the caching issue. My suggestion would be to focus on block caching in any subsequent updates. Don't want to break the one functioning part. :-)
Sorry I can't help with patches, as I am not a developer. But I'm good at finding bugs. :-)
PS: As a point of info, I'm also using Display Suite, and so far the rrssb field buttons seem to play well.
Comment #7
adamps commentedShould now be fixed in dev.
Comment #9
alan d. commentedI haven't tried dev, but I just resolved this using caching flags on the block build.
Having nada means cache globally in Drupal 7, I guess the same happens in Drupal 8.
Looking at http://cgit.drupalcode.org/rrssb/commit/?id=9d76317, it is hard to see how that would resolve the issue, but like I said, I haven't tested that