I was looking in the code and it looks like you do have the ability to display certain pages of a photoset. I want to build the following and will submit it back once I have finished, just wanted to check this wasn't already operational but I just hadn't seen it:

[flickr-photoset:id=72157594262419167,size=m,num=5,rand=false,page=true]

num being the number of photos to display
rand being a random selection or in order
page being show a pager to navigate through the photoset (via AJAX with a page refresh fallback)

I'll also create a plug-in for FCKeditor where you can browser photosets and insert a pre-made filter tag like the one above into your page.

Let me know your thoughts.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Anonymous’s picture

Please feel free to work on this, thanks :-)

Anonymous’s picture

Title: Browse a whole photoset within a filter tag » [BEING WORKED ON] Browse a whole photoset within a filter tag
jdelaune’s picture

I just made this since I needed a solution for my company fast. Will be happy to merge it in with the Flickr module. Feel free to take any bits you want. It's not perfect and I'm pretty sure I have modified it a bit from the the dev version there. But the grounds are there.

http://drupal.org/project/flickrinsert

cookiesunshinex’s picture

Was there ever a plug-in for FCKeditor created which will browse and format the filter correctly and place it into the body field?

lolandese’s picture

Title: [BEING WORKED ON] Browse a whole photoset within a filter tag » Additional parameters for a filter tag
Version: 6.x-1.x-dev » 7.x-1.x-dev
Issue summary: View changes

Media type is another one to add here (e.g. media=photos).

Moving this to D7.

lolandese’s picture

It would make most sense to use the functions from the sub-module Flickr Block also for Flickr Filter. They render user, group or set photos currently with the following parameters:

  • random or recent
  • with the number of images specified
  • with the media type specified
  • with the size specified (as for the current filter tags).

This would imply that those functions have to be renamed, probably rewritten and be moved to the main Flickr module (as they are then used by multiple sub-modules).

lolandese’s picture

We could even simplify a tag to something like [flickr-id=72157594262419167,m,5,random,photos].

A flickr-id can be analysed to see if it is a photo, set, group or user ID.

lolandese’s picture

Status: Active » Needs review
FileSize
18.46 KB

Attached patch allows for a tag like:
[flickr-photoset:id=72157634563269642,size=s,num=8,media=all,random=true]

It borrows the rendering functions _flickr_block_photoset_random and _flickr_block_photoset_recent that have been renamed and moved to the flickr.inc file as they are now used by more than one submodule. Actually the number of code lines remains about the same with this patch while extending the functionality.

Something similar can be done with the filter tags flickr-group:id and flickr-user:id. Practically it allows to use similar output as for the blocks in the node body, with exception of the block title. That could be a next step.

lolandese’s picture

Corrected a bug that broke the cache of the blocks that use the same functions.

Furthermore added the parameter 'count=false' that allows to suppress or force display of the counter (e.g. 4 out of 11 in set on Flickr). Thus:
[flickr-photoset:id=72157634563269642,size=s,num=8,media=all,random=true,count=false]

  • Commit af3bb23 on 7.x-1.x by lolandese:
    Issue #383792 by jdelaune: Additional parameters for a filter tag.
    
lolandese’s picture

lolandese’s picture

Version: 7.x-1.x-dev » 6.x-1.x-dev
Status: Fixed » Patch (to be ported)

Created two child (follow up) issues:
Comment #7: #2253603: Simplify filter tags
Comment #8: #2253641: Extend parameters for group and user IDs.

lolandese’s picture

Status: Patch (to be ported) » Closed (won't fix)
lolandese’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev
Status: Closed (won't fix) » Closed (fixed)

Setting this back to D7 and being 'fixed (closed)'.

Main reason is the fact that links to this issue show the status on hover without revealing the version (6 or 7). This might give the impression that the mentioned issue will not be solved, while in fact it is already fixed for the D7 version. 'Fixed (closed)' reflects the current status correctly for D7. 'Closed (won't fix)' is only valid for the minimally maintained D6 version of the module.