New parameter 'location' (TODO: also for Blocks)

A first shot. Not ready for review. Only posting to save the work done so far.

Although not completed, above patch gives the desired result already.

The dsm() or dpm() functions are used to display some info about objects or variables for developing purpose. Enabling https://www.drupal.org/project/devel makes those functions available.

Hi,

The dynamic context sensitive blocks are on the wishlist as a next step. First implementation as found in the patch only applies on Flickr Filter. The Eiffel Tower example is working. For now you can even create blocks that include a Flickr Filter, but it will show static content (one or more specific locations). Just put the example tag in a new block.

Beware. For now Devel should be enabled and it breaks some other parts of the Flickr module, so consider it experimental (not ready for a production site). I'll try to fix this ASAP.

Thanks for testing.

After applying attached patch

[flickr-user:id=public, size=q, num=5,location=48.85837/2.294481/0.2,filter=interesting]
[flickr-user:id=public, size=q, num=5,tags=kids,location=30.3217076/35.4517729,sort=views]
[flickr-user:id=lolandese1, size=q, num=5,tags=kids,location=30.3217076/35.4517729]

results in

Fixed for Flickr Filter.

From the issue description:

After we can also add two blocks that dynamically grab a Geofield from the node to display photos from that location.

TODO

It is similar to the patch at https://www.drupal.org/node/2024133#comment-8728979, but instead of using a taxonomy field it should use a Geofield.

Feel free to work on it. Patches are always committed with attribution. I will review almost instantly.

If not, I will get onto it, but I am a bit busy until Christmas.

Yes. Of course also the Location field could be used as a source for the latitude and longitude. I guess a simple number field could hold the radius if there is the need to vary this parameter per content. If not, it could be set in the block configuration.

The block caching mechanism as introduced in https://www.drupal.org/node/2227669#comment-8654119 uses the functions cache_get and cache_set. The first parameter $cid (the cache ID) is used as a unique key for a block. If it contains the 'location', it uses a separate cache for each location. Maybe easier is to use the 'nid' as the block displays only once for each node, but should be unique per node.

I see now that somehow the above mentioned patch did not go completely into http://cgit.drupalcode.org/flickr/tree/block/flickr_block.module. I have to check if this is the case, if something went wrong there and what the implications are for our block caching. EDIT: All fine. Some part has moved to flickr.inc into the _flickr_album function. TODO: Write some lines on the caching mechanism in the module's developer documentation.

There seems to be three layers of caching

Correct.

Inside _flickr_album

Ah, yes. I probably moved it there to have it only in one place, but forgot about it. All fine.
So you could use cache_get that uses the nid there inside $cid, but only in case we use a 'dynamic' block that changes on every node. Maybe it's better to implement the block caching once the rest is working?

$delta is used so many ways. (Except for backwards compatibility.)

Yes, we didn't want to break blocks on an existing site when they upgrade the Flickr module. In D8 we'll probably make one dynamic block that contains all configuration settings combined. The new block system will give the site builder the possibility to use it multiple times, even on the same page.

Once a filter block is constructed, it won't change.

Just to clarify, as I understand from the line above you create a new block through admin/structure/block/add and use a text filter that contains the Flickr Filter, right?

You can create blocks with Flickr content that way, but it will be hard to make their content dynamic depending on the node that is on the same page as the block.

If you create a block from inside the module's code as done in the patch mentioned in #16, the module's own caching mechanism kicks in. From function _flickr_album() in flickr.inc on line 502:

  $cache = cache_get('flickr_block_' . $delta . '_' . $id . '_' . $tags . '_' . arg(0) . '_' . drupal_is_front_page() . '_' . $page);
  // If $delta is a number it is a block that could be cached.
  if ($cache && is_numeric($delta)) {
    $output = $cache->data;
  }
  // In any other case we generate an album, including a heading and counter.
  else { ....

This piece of code is called each time you render a programmatic created Flickr block, using the unique $cid caching key, resulting in context sensitive blocks. It is not called when rendering a "Drupal system created" block containing a text filter. The text filter that you put in a block's text field uses the same piece of code, but it is called only when saving the block. That version remains in the block until the site cache is cleared.

Let me know if what I described is indeed your case or not.

I guess the problem is that the Flick content is in a text field within the block that is generated on block save or after clearing the cache. Excluding a block from being cached probably does not cover this case as it does not clear the cache actively for the block but only prevents the block from being cached. Note: This might be not true.

You could try the CacheExclude module on the pages with the blocks that you want to target. If I understood right, it concerns all page content, including the blocks.

Personally I would not sacrifice site performance just to solve this problem. The proper solution I have already given and is not too difficult. A possible approach:

• Copy and paste the code to generate block with $delta=3 (everywhere you find it).
• Change the delta to the next available block number (17 I guess).
• Change also this piece of code on line 50 in flickr_block.module:

  for ($i = 0; $i < 18; $i++) {
      $blocks[$i]['cache'] = DRUPAL_CACHE_GLOBAL;
  }
  

• See if you can get that working. It must be similar to the existing block 3.
• Save a copy somewhere.
• Start to hack those pieces to pass $lat and $lon to function _flickr_album(). Leave out $radius for now.

Probably yes. I have to study https://api.drupal.org/api/drupal/includes%21common.inc/group/block_cach.... I wonder even if it is still used.

Feel free to fill me in on this one.

Logic tells us that the module now handles it's own cache for all blocks that use function call _flickr_album() through flickr_block_view(). We should run a test using DRUPAL_CACHE_CUSTOM for those and see the impact. Probably none as the cache gets overridden anyway by cache_get()?

It is probably a remainder of the old code base.

Back to the new Flickr Filter functionality.

The example tag in the text filter tips ([flickr-user:id=public, size=q, num=5,location=48.85837/2.294481/0.2,filter=interesting]) currently provokes the following error:
Warning: htmlspecialchars() expects parameter 1 to be string, array given in check_plain() (line 1566 of /home/martin/www/brown/includes/bootstrap.inc).

As is was working properly before, this is due to a probably temporary Flickr API bug that we just reported at https://www.flickr.com/groups/api/discuss/72157649006719348/.

Nevertheless we will build a safety catch in case $place_name = $place_id['places']['place'][0]['name'] returns an array instead of the usual string.

Safety catch patch.

Setting back to active to implement static and dynamic location based Flickr blocks.

Additional feature request:

Block 'Flickr photos near you optionally tagged as term from node'

For example an article tagged with 'graffiti' would automatically show a block titled 'Most interesting Flickr photos tagged graffiti near you (Asnières-sur-Seine, Île-de-France, France)'.

HTML5 Geolocation transparently asks the browser for the user's current location. Works great on Chrome and smartphones with GPS. It is part of the Geofield module.

Attached patch adds dynamic block grabbing the location from a geofield. The radius is auto expanding until the required number of results are found.

TO DO:

• Include lat lon data to the block's cache ID.
• Extend it to all relevant blocks.
• Write some integrated help.
• Make the auto expanding radius also apply on Flickr Filter.

Commit candidate.

To see if to integrate before commit or open new issues for:

• Additional feature request: Block 'Flickr photos near you optionally tagged as term from node'.
• Support for the Location module.

Added support for the Location module.

Opened a new issue for the additional feature request: #2438241: New block 'Flickr photos near you optionally tagged as term from node'

TO DO:

• Adapt the administrative block descriptions.
• Test the 'gallery' blocks. Separate if necessary from the 'user' type blocks.