I have just started working with dynamic albums, and understand that I can manually edit the .alb file for complex searches, which is fine. (FYI, I have been unable to edit the stored search field after the album is created.)
Not sure what the role of the cookie is, but what I'd like to be able to do is embed the results of the last search in the .alb file (ie: the names of the selected images), and then set a 'static' flag which means, use the list in the .alb file rather than updating the search. I'd also like to have the option of storing the .alb files in an area not part of the published gallery tree, and then access those albums from custom zen 'pages'.
In other words, in order to access one of these static-dynamic-albums, the user would have to go to the specific page setup for that purpose. The rationale here is, suppose I have a group of photos relating to some specific event (like a vacation) that would only be of interest to 3 of my registered users. I'd like to make it possible for any of those 3 to go there, make comments, etc., but they would know that the pictures and the comments were "for their eyes only".
Another way of looking at it: I want to setup an ad-hoc "discussion group" of sorts, concerning some arbitrary group of photos taken from various public galleries. No need to secure or segregate the original photos individually, but I might want to secure and segregate the dynamic-album & the commentaries etc. In this context, I suspect there's no need for the cookie, and no need to rerun the search every time the album is accessed.
It appears there are plenty of ways to do this, and I'm starting to search them out. However, if there's some obvious methodology for doing this already, a heads-up would be appreciated.
Zenphoto
Comments
You can only set user rights on top level albums. See:
http://www.zenphoto.org/news/an-overview-of-zenphoto-users#zenphoto-users
However, if you are up to some coding you could create this. Start with the `favoritesHandler` plugin as a basis. It keeps a "list" of albums and images and presents them as an "album".
What you would have to add would be two things.
First something to intercept the rewrite rules for albums so that your kind of album would be recognized and directed to your "album" stand-in. The `load_request` filter would be the place to handle this.
Second would be the code to "freeze" the search by storing the results like `favoritesHandler` does. You could use the `admin_toolbox_album` to create a link to your code for doing this.
This coding would not be trivial, but certainly is doable.
as an example of what acrylian said, you could see my website http://www.vincentbourganel.fr/
I created a dynamic album with tag portfolio.
this album is unpublished and I create a specific page called Portfolio which presents pictures of this album with a specific design.
of course, there is some code in codeblock to display this album in the page.
but another solution is to use album rights, to allow part of your registered users to see some of your albums.
as you said before, there are plenty of ways to suit your needs...
After reading through the album security options, for that I suspect I'm going to have to go around the generic authorizations and store what amounts to a fixed auth list, and then let the page_auth.php layout validate access to a set of objects, authorized users, and a series of comments forming a thread.
At the moment, I'm struggling to figure out where to get reliable information about the user name for a given browser session. I see references to $_SESSION, but attempts to access it return NULL. Can't seem to read the cookie with zp_getCookie('<name>') either, even though I know the cookie is out there under 'zp_user_auth'. I have found $_SERVER and getOptionList(), also tried hacking into sbillard's security-logger.php (which appears to get $_zp_current_admin_obj->getUser()&getName()), but haven't quite figured out how to transplant that into my page_auth.php layout.
These are clearly due to my novice status with Zenp, and will just require a bit more reading/trial & error. (That said, any clues welcome!)
Thanks for the suggestions on the overall problem. Love the dynamic album concept. Needless to say, Zenp is a lot more than just a top-notch photo-gallery platform!
PS:Apropos the static .alb file, as long as my page_auth.php can be secured as gatekeeper (which I think it can), I can manage that part reasonably easily.
You can probably make use of the `plugin_storage` table for keeping your access lists, so you just need an interface to set them up. That presumably can be done by a plugin that makes an appropriate tab on the back-end pages.
I think your biggest issue will be in handling pagination. Unless you filter out the restricted items in the object handler there will be a discrepancy between the count of items according to Zenphoto and the count according to your `page_auth.php` script and the automatic pagination routines will just not work. This is mostly why I suggested an approach based on extending the album object similar to what the `favoritesHandler` plugin does.
In one forum post I read, I believe you told the person "we don't do that" ($_SESSION), but then I saw it mentioned in the reference manual as part of one of your regular function definitions.
Also, apropos cookie vs. database entry to maintain a persistent login state, are there technical docs that explain this things (I couldn't find any).
Thx.
Sessions are a at the whim of the browser and are typically very short lived. Cookies normally are longer lived, but some viewers will dis-allow their use. Cookies are stored on the viewers computer and can be forged.
Database entries are there until you delete them and are only accessible by your PHP script.
URL /page/favorites not found.
I'm continuing to try and figure out where this error is coming from. (It seems odd, since there is no root '/pages' folder) Any suggestions on what might be going wrong appreciated.
BTW,It appears your suggestion to adapt the favorites plugin as a basis for creating what amount to arbitrary-static-collections of things is spot-on. Anxious to get going on that, once I know I've got the favorites plugin configured properly.
Note: I found this line in favoritesHandler.php: (had to alter the text above slightly to get it to appear)
I suppose if I figure out why I have no root folder '/page' in my installation (1.4.4.3), that could be a clue.
thx.
No, there is no such folder. `/page/something`is the standard url of a static custom theme page. The favorites page is such a page. See also:
http://www.zenphoto.org/news/theming-tutorial#custom-pages-with-the-example-of-archivephp-and-sl
1. I enabled the favorites plugin
2. Made no changes in the default settings.
3. Set some favorites.
4. There is already a favorites.php page setup in the cloned theme.
I'm assuming the existing default favorites.php page is the custom page Zenp is trying to load with url /page/favorites
(or)
Do I need to create a new custom page based on the archive.php or slideshow.php examples?
My assumption here is that the favorites plugin works by default, assuming the theme has provided that custom page. Since I just enabled favorites, and didn't change anything, I'm wondering if this is a bug in the plugin, or perhaps it only works if the theme is actually the original 'zenpage' theme, and not working due to the clone?
/page/something is the standard link assuming you use modrewrite. Otherwise the links would be /?p=something.
Did you look into your logs for errors? Is the favorites link option set?
I also examined the favorites.php page which is included in the theme, and it appears to substantially match the archive.php example referenced in the theming tutorial.
The only other issue I can think of here has to do with mod_rewrite. I believe I do have mod_rewrite enabled on my Apache2 installation. However, I did not enable it when I configured the Zenp website I'm developing. Given this reference from the tutorial: (I'm assuming that since my site has zenphoto as it's root, the 'zenphoto' prefix is not required.)
Could it be the favorites link generated by the handler is providing the mod_rewrite version, when it should be providing:
/index.php?p=favorites
Frankly, I'm reluctant to proceed with attempting to modify the favorites handler without a starting point that works.
Thanks for any suggestions as to how to resolve this.
2. The only favorites related options I found were in the favorites plugin config page, and the closest thing I found was 'Link text', which I believe simply sets the label on the menu option. I could not find an option anywhere that addressed the 'favorites link' specifically.
3. I confirmed that I did not enable the mod_rewrite option in the site setup (which was intentional), and it remains disabled.
However, when I initially setup the website, I also disabled the 'deprecated functions' plugin, thinking I'd prefer to build the site using non-deprecated functions. However, after adding some additional plugins, I found that 'deprecated functions' had been enabled, I presume as a dependency of one of the plugins I added, and all the deprecated functions are enabled.
On the list of deprecated functions that plugin supports, is one:
rewrite_path_zenpage
Which is enabled. I'm wondering if that might explain why I'm getting the mod_rewrite version of the favorites link?
I will wait for your response before posting any more information.
(thanks)
Forgive I don't remember but does any of the links modrewrite/nonmodrewrite work on your site? If so you can edit the sidebar.php of your zenpage theme clone to add a static one of course.
I put a generic link in place of 'printFavoritesLink()' and it worked, got me to the actual favorites page.
Also, checked favoritesHandler.php, and there is a reference to getOption('favorites_linktext') and getOption('favorites_link'). It may just be that the snippet referenced above needs to be modified in some way to take into account whether or not the site is setup to use mod_rewrite or not. Not sure why there isn't an option input on the favorites plugin config page, but since I'm customizing the plugin anyway, I can deal with that.
Sorry if these questions are a little dumb. Since I'm not familiar with the coding environment, I'm trying to avoid tinkering with anything unnecessarily. I think I can now go ahead and setup a clone of favoritesHandler as Sb suggested.
thanks again for your help.
Favorites works with or without mod_rewrite. But if you change the default for the name of the script page (defaults to "favorites" then you also have to make sure that you have a script of that name. That is pretty much the gist of what acrylian was trying to convey above.
Also, the favorites handler plugin will give arbitrary visitors a 404 error if they try to access it. Pretty hard to maintain a set of favorites if you are not a user. So if you are not logged in, expect that the page is not available.
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.
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'):
`
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; ?] <a href="[?php echo FULLWEBPATH.$my_pageref; ?]">[?php echo $text; ?]</a> [?php`
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.
Please correct me if I misunderstood the tagged-search thing, but I see it as very useful value added, to the originally suggested method.
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.
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.
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.
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> ...
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!)
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