I have had another thought on this. How about if you could "tag" the results of the search with a new tag. Then you could make a dynamic album based on just that tag. It would reflect the search at the time it was made, except, of course if any of the images got removed, etc.

If that sounds good, give the development build a try--there is now an option when you create a dynamic album to do just this.

@Sb, thanks for that additional input. I want to think about your alternative suggestion, so won't comment on that until I have.

Apropos the 'favorites' solution...

I've implemented a clone I'm calling 'tigvnet' for the moment. The first iteration does exactly what favorites does, with the exception that it stores the records in plugin_storage slightly differently. The 'aux' field, rather than containing the user id alone, adds a suffix I'm calling 'sset'. The default is '<user>#sset_def', so in effect, by doing it this way, I can create named-favorites per user (author). Although I haven't added this yet, there will be a 'SaveAs' feature which will effectively rename 'sset_def' to something else, and in effect purge 'sset_def' from plugin_storage.

Of course, this requires some UI additions to the 'Show Favorites' page, but I'm planning to use the contact us page as a template, so the user can provide the unique name, and a caption of some kind. Since these 'albums' will have a list of authorized users who are allowed to view and possibly edit them, I'm planning to add some fields to the serialized data array for that.

Once that's working, I may externalize things by creating an alternate form of your .alb files, stored in a separate part of the albums branch, or perhaps give them their own branch.

For what it's worth, I added what (I think) will fix the mod_rewrite/no_mod_rewrite problem with 'printFavoritesLink' (TigvNet eq 'Favorites'):
`
[code]
function printTigvNetLink($text=NULL) {
if (is_null($text)) {
$text = get_language_string(getOption('tigvnet_linktext'));
}
$my_link = getOption('tigvnet_link');
$my_modrew = getOption('mod_rewrite');
$my_pageref = ($my_modrew) ? '/page/'.$my_link:'/index.php?p='.$my_link;
?]
][?php echo $text; ?]
[?php
[/code]
`
Thanks for suggesting this approach, since even as is, I'm pretty sure it will work for what I have in mind. Will think about the 'tagged search' alternative, and then post a reply.

Sorry, I don't know how to properly isolate code snippets from the bb, so some of that may have been lost in translation...

Apropos tagged-searches. Assuming I'm understanding that correctly, you are adding the ability to save a search under a specific name. I think that's a great idea. However, by using your originally suggested method, I end up with a list of album-object-references (files) which don't change after the fact, and that solves the original problem with using dynamic albums. At the same time, by providing tagged-searches, I could easily integrate a reference to one or more tagged-searches into the (modified) favorites structure, and then, if one of those was found when opening the collection, run it again and display new matches.

Please correct me if I misunderstood the tagged-search thing, but I see it as very useful value added, to the originally suggested method.

Regarding code snippets escape them using `backticks` works quite well once you found were backticks are on the keyboard..;-)

Dynamic albums are saved searches that can be based on tags as well. But whenever you add new things to your site that match that search it will update itself.

My colleague suggested to add a new unique tag after saving so you more or less have the fixed status of that time. Since only the items at that time have that unique tag.

I'm a little confused here... (please bear with me)

How do you add a 'unique tag after saving'? Are you saying: create a tag that looks like (for example) 'asof1303181201', and then assign it to all the files in the collection that make up that album (or favorites list)?

(or)

Are you saying create a tag 'MYLIST_ASOF'=<yymmddhhmmss>?

I'm just not that familiar with tagging images. And would like to understand this new feature of dynamic-albums. In my application, it seems to me there would be the potential to assign lots of tags to one or more of the images/documents, since the same image/document might be included in dozens of these 'threads'.

The basic idea here is to create little ad-hoc albums of a few pics/docs, which are viewable only by an arbitrary sub-set of the community's registered members. Conceptually, if you had an album called 'Travel Photos', this would enable you to create an album (thread) which referenced a handful of pics from that gallery, and was shared with just the people who went on the trip.

Bottom-line, I think the 'favorites' paradigm, with the additional ability to assign a unique name to a given set of favorites, turns out to be perfect, because a favorites list (unlike a search) contains the full name of the pic/doc in the album, and does not change.

That said, I can certainly see how 'named searches' could be very useful. An easy way that could be done:

@<name>="search criteria"

Then, when search encounters @<anything>, it looks it up and plugs in the "criteria". The reason this would be so useful is that most people (me included) have a hard time remembering how to specify a complex search.

Thanks for setting me straight on what Sb was referring to in his previous post.

The actual tag you use is up to you. The implementation will suggest a tag based on the query, but you can change that. Whatever tag you choose is assigned to all the items of the search. Then the album is created with a search on that tag as its criteria.

Maybe best you just make a test installation of the development branch and play with it. But you are right. The tagging is not frozen in concrete. If an item has the tag removed it is no longer in the album. On the other hand, if you have a list of items and the item is removed then you will have an issue of trying to display something non-existent. Not changing can be a blessing or a curse.

The view-ability of the album is a different topic. You do that with various protections and user rights. There is a topic on user rights that covers this in the user guide. Of course, since the "favorites" concept does not make an album that shows on the administrative pages, all this rights management on the album must be done by your UI.

Thanks Sb for that explanation. I'm curious: when you say 'tag', do you mean the tags that would be in the image file itself, or as an alternative, in the .xmp sidecar? Or, are you talking about an independent tagging construct (like a table for example)?

Does Zenp support tagging for other than .jpg files (by extending the sidecar concept as in: filename.png.xmp for example), or is tagging now a part of the image file standard?

It seems to me there would be significant benefit to adding options to the .alb file spec which would allow you to optionally implant the file paths found by the search (perhaps including their size and date), such as:

CONSTRAINT=&static|&relocate|&ifdate|&ifsize

'static' = don't rerun the search unless instructed;
'relocate' = if <relpath><file> not found, search for <file> at another location starting at /albums,
'ifsize' = require <size> to match
'ifdate' = require <date> to match

FILES=
<fspec1.dt.sz>,
<fspec2.dt.sz> ...

After re-reading my previous post and consulting the Zenp docs, I realize now there are quite a number of different uses of the term 'tags'. 'short tags', html meta tags, 'cloud tags', EXIF tags.

Sorry about the dumb questions on tags, I found what I was looking for under 'tags':

http://www.zenphoto.org/support/tags.php?tag=tags

(Duh!)

If we talk about "tags" we mean "keywords" in this case. You can tag anything on Zenphoto via the backend: albums, images, Zenpage pages or news articles. Those are the tags added via the backend.

You can also store tags in meta data of images before uploading. That would be EXIF tags for example or XMP sidecar files. PNGs or GIF in my knowledge don't support meta data like JPEGs do. Also if you use Adobe software of older age and the "save for web" feature these date is stripped to make the files smaller (CS6 has an option now to keep certain ones).

If we meant HTML or PHP tags we would specifically refer to those in context.

So again: If you create a dynamic album by a search or tags (keyword) search it is not static if the original elements are removed or if new elements matching the search are added.

If you wish to keep the state of the search statically you have to code something to make the search unique. You could do that by assigning a specifc new tag to the elements matching the search at that point of time and base the search on that one only. Then the items of the search would stay "fixed" until you remove one of them. Since the tag is unique for this one search it will not update with new items unless you add items with that tag specifially.

Also this is something we suggest for you to add to get your functionality. It is not that way implemented (unless sbillard did meanwhile do something in the dev build which I haven't checked).

UPdate: He did indeed add something to the dev build to aid with this concept:
https://github.com/zenphoto/zenphoto/commit/19311a0c81982b6ea3f1aa3652a748848d767d04

Thanks Ac, I'm going to download the github version and try it out. Appreciate the detailed explanation.