printAlbumURL adding unneeded page numbers, resulting in 404s

david1pro

Hello. I am coming along nicely with my site, with great thanks to those here who have been helping me.

On my image.php page, since images can come from a number of sources (the album/sub-album itself, a tag link, a direct search, etc.), I wanted to put a link to the original album an image is pulled from, so the viewer can browse that album. To do this, I have used the following on my image.php page:

From the album: <?php printAlbumURL(getAlbumTitle(), getAlbumTitle(), null, null); ?>

This works, unless the search result brings up more than one page. For example, If I search for "Mary" I will get over 400 results. Whether I use infinite scroll or not, once I get to an image past the first page, the "from album" link attaches the page number of the search results.

This means that if on the 5th page of "Mary" results, I pull a picture from a small album with only 20 pictures, the link the above code gives me will be for "that-album/page/5/" even though that album does not have a page five. This results in a 404 error when someone clicks on the link. Interestingly, if I click the "back" button after hitting that 404, I go back to that same image page and then refresh the image page, it does not append the "/page/5/" and the link then works correctly.

It seems to be getting "/page/5/" not from the album it pulls the image from, but from the initial search position, and only when directly called from the search position. The link itself, if refreshed after moving away from it, or if the link to that image page is copied and pasted into a new browser, the "From the album" link works as expected. Also, when refreshed in a new tab (or after moving back from the 404 page the breadcrumb reflects the original album the image is from and not the search link.

Google brought me to this page on github: https://github.com/zenphoto/zenphoto/issues/669 and I played around with my print_album_menu.php a bit, but clearly that php page has changed a lot since 2014, and I could not fix the issue.

Additionally, this feature does cause an issue with images pulled from second pages of albums when using infinite scroll, as the /page/x/ link, while correct if the image was derived from the album itself (rather than via a tag link or search), only loads the second (or x) half/portion of the infinite scroll page, making it impossible to see the full album from which the image comes. So whether the page is legit (as when an image is called directly from its album) or not legit (as when the page number is from the page in search results and not actually from the page of the album where the image originates), having it attached to the URL gives undesirable behavior.

Thoughts on how to have my link above not add the page number- especially the fictitious page number it seems to be gathering from the image's position in search results?

I would greatly appreciate any ideas.

acrylian

You mention search somewhere in your long post… Search results context and pagination is working differently than normal albums.

Infinite scroll is not a feature any official theme uses so I cannot really tell if it is doing this correctly or not.

Besides I belieave Zenphoto 1.6 will have fixes in this area but is not yet ready for production use.

acrylian

Try to use a link using the object model directly instead:

<a href="'. html_encode($_zp_current_album->getLink(null)).'"><?php printAlbumTitle(); ?></a>. Or instead of null try 0 probably to not append any page number at all (doc say null should prevent that but I think is not correct).

https://docs.zenphoto.org/1.5.x/source-class-AlbumBase.html#591-610

david1pro

Thank you so much. Your tip got me on the right direction and it now works. The code you gave me added this portion of itself

'.%20html_encode($_zp_current_album->getLink(null)).'

after forming the correct link (as if the code did its job in forming the link, then revealed itself as well by tagging itself onto the end of the URL), which resulted in a correct link with the extra code tagged on, leading to a 404, so I changed it to:

<a href="<?php echo html_encode($_zp_current_album->getLink(null)); ?>"><?php printAlbumTitle(); ?></a>

and that worked fine. This was better than my workaround which was to use my currently unused Custom Data section of each album to copy and paste in the album path located right after Edit Album: on the back end and then use this custom data to get the correct path without a page number:

<a href="<?php echo FULLWEBPATH;?>/<?php echo getAlbumCustomData(); ?>"><?php echo getAlbumTitle(); ?></a>

That would have been tedious, though, as I would have to remember to add that to every album.

To note, infinite scroll is moot with the search results, as whether one uses that or not, you still can get search results that go beyond a first page, and that page appears in the search results URL as you either scroll or click to them. Once you do, the code I was using (printAlbumURL) adds the search page number to the albumURL link, whether or not the album which the image it is pulled from has a second or greater page (based on the album's image count), resulting in it not being possible to use printAlbumURL to get the album link of an image from a search result after the search results go into a second search result page, as the page number attached isn't from the original image's album (though coincidently the original album may also have a second or greater page). That's the part that seems a glitch. With the popularity of infinite scroll, for regular album pages, people may appreciate the option to either have the page number or not, but with the search results, it messes things up.

Sorry I'm verbose. I appreciate the help. I'm really liking the software and am excited / nervous about 1.6, as I wonder if I've done stuff that will be messed up with the next release, lol.

Again, thank you!

acrylian

Sorry, my code was for echoing the whole link instead of adding it to plain html. So your change is of course correct.

Yes, search mode is a bit different and also the breadcrumb is different than within album. Search results with infinite scroll certainly will work in general, any pagination can be setup to do so with some extra JS.

I wonder if I've done stuff that will be messed up with the next release, lol.

We really hope to have the beta ready - currently alpha status - later this month to be finally ready for PHP 8 (as some hosts already announced to switch of PHP 7 end of November).