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.
The easiest would be to use a specific tag for that purpose and keep the album itself unpublished so it does not appear in the any menu tree. Unpublished items are alway accessible if you know the direct link.
You can only set user rights on top level albums. See:
http://www.zenphoto.org/news/an-overview-of-zenphoto-users#zenphoto-users
Searches cannot really be static as you desire, so you would have to capture the result of the search at the time you wanted to freeze the "album". There is nothing that does this at present.
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.
hi
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...
Thanks for all of those suggestions. Being able to establish a strict and generally arbitrary list of users who have permission to look at a given subset of objects (usually pictures, but could also be a set of legal documents being used in a multi-party negotiation) is a key requirement for the project I'm working on. Hence, both establishing a static list of objects, and a static list of viewers is important (while leaving open the option of bringing in more objects and more participating members going forward).
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('') 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.
If there is a valid $_zp_current_admin_obj it contains all the information there is about the logged in user. You can use the object model to retrieve such details as you need.
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.
If I may ask: is there in fact a supported $_SESSION object that get's instantiated with each post? Is zp_start_session() part of that process?
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.
Not necessarily. It will be if you enable the gallery sessions option. Otherwise it is only enabled on the back-end. Yes, zp_start_sessions() does the enabling.
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.
@sbillard:
Quote:This is mostly why I suggested an approach based on extending the album object similar to what the favoritesHandler plugin does.
I've enabled the favorites handler, and I am using a clone of the theme Zenpage. The cloned theme has not been altered, other than the addition of some alternate layouts for images.php. I have gone through my gallery and selected a series of favorites. However, when I click on the My Favorites menu option, I get:
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:
Quote:/page/ id="favorite_link">
(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.
[i] suppose if I figure out why I have no root folder '/page'[/i]
No, there is no such folder. /page/somethingis 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
Sorry, unable to get the snippet from favoritesHandler.php to display correctly. Basically...
Quote:[a href=[php echo FULL WEB PATH;?]/page/[php echo getOption('favorites_link'); ?] id="favorite_link"][php echo $text; ?][/a]
Hoping this comes down to figuring out why I have no /page root folder.
So, just to be clear:
- I enabled the favorites plugin
- Made no changes in the default settings.
- Set some favorites.
- 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?
No, archive.php and contact.php are examples. favorites.php is a custom page as well.
/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 tried switching to the generic Zenpage theme, and still get the error.
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:
Quote:zenphoto/index.php?p=pagetitle (non mod_rewrite)
or
zenphoto/page/pagetitle (mod_rewrite)
(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.
We're overlapping here. I will check the issues you mentioned, and then post what I find. (Thanks for the prompt attention to this.)
Apropos...
Quote:Did you look into your logs for errors? Is the favorites link option set?
-
No errors in the debug log.
-
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.
-
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)
Thanks Ac, good idea.
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.
Do understand that the favorites plugin will not do what you are looking to do. Instead it is an example of how you can create an "album" object out of thin air.
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.