I'm not sure if this qualifies as a bug or not, but I interpret it as deviation from expected behaviour so here goes.

Using a [flickr-photoset:] filter tag in a Basic Page, with global configuration set to show 10 photos. The set is manually rearranged "by date uploaded (newest first)" when new uploads are added, but the set of images shown on the page never updates. It's necessary for an administrator to clear the cache before the changes are picked up.

Is this breakage, or is it simply the case that filter usage is assumed to be static so the cache is never freshened? Or does the need for manual rearrangement of the set after uploading to Flickr (really annoying in itself, awfully poor usability on their part) short-circuit the process somehow?

Comments

lolandese’s picture

lolandese commented
Status: Active » Postponed (maintainer needs more info)

To give the authenticated user the possibility to flush the cache of a single page, I suggest to use http://drupal.org/project/flush_page_cache, http://drupal.org/project/page_rebuild_cache or similar. Can you test if this is a viable solution? Let us know.

Thanks.

headbank’s picture

headbank commented

Hi, I think I worded this badly, apologies. My point was more that, as I understand it, the cache for a page using the filter tag (or any other page for that matter) should auto-refresh eventually even if nobody is logged in, but this is what's not happening. The global (page and block) cache mechanisms are working fine, and so it appears is the Flickr module's, at least for blocks.

Currently I've replaced the filter tag with a Flickr block displayed only for that page, using the "Recent Photos" block type. With this approach the page is updating when new photos are uploaded. This is fine when the Flickr user is only uploading photos to one set anyway, but if they were also uploading to another set with which my page wasn't concerned, those would appear too.

So the issue is that when a photoset is added to, and/or rearranged manually within Flickr, the flickr-filter module doesn't seem to pick up on these changes to begin with. As the page should be rebuilt periodically anyway, this has to be because either (A) flickr-filter is not checking for changes to the photoset (or to the requested subset, I should perhaps say), or (B) the API call is failing to give any indication of the new uploads or rearrangement.

dakku’s picture

dakku commented

Hi,

Can you try out the API here: http://www.flickr.com/services/api/explore/flickr.photosets.getPhotos

This is so we can work out if Drupal or Yahoo API is responsible for caching the results?

lolandese’s picture

lolandese commented
Issue summary: View changes
Related issues: +#146683: Photosets not updated

Added related D5 issue. Some info about the underlying caching mechanism.

lolandese’s picture

lolandese commented
Version: 7.x-1.0 » 7.x-1.x-dev
Status: Postponed (maintainer needs more info) » Closed (works as designed)

It's necessary for an administrator to clear the cache before the changes are picked up.

That is normal behaviour. Cache is also cleared on cron run. Making a Flickr API request on each page load would impact the performance.

Try the latest dev, as it has some settings related to the block cache. Furthermore it offers alternative sort options for photosets, like date taken, date posted, number of views, photo ID descending, random and unsorted.

You might want to consider to use cache warming. See https://drupal.org/node/1576686.

Thanks.

headbank’s picture

headbank commented

Sorry, the phrase you highlighted there was in fact the nub of the matter: the automatic cron runs that are supposed to happen just through configuration did appear to otherwise clear the page cache, but only when I did a manual cache-clear did the page containing the flickr-filter tag show the rearranged photoset order and the newly-uploaded content.

It's a little academic as I'm now using the "Recent photos from a Flickr user" block instead, and the said Flickr user doesn't anticipate creating any further sets to complicate matters, but I'll try to revisit this and re-test the filter behaviour when time allows.