Zenphoto
The simpler media website CMS
ZenphotoThe simpler media website CMS
Forum search only. You might also want to search on the main site's user guide.
Your support helps pay for this server, and helps development of zenphoto. Thank you!
Visit the donations page
Hi. New user, first post. I'm migrating a photo site from Gallery3 to ZenPhoto. In Gallery3 I had some SEO optimisations that set album URLs to end in .html rather than /. In hindsight that probably wasn't smart, but at least there's not so many of these so I can probably deal with them via server redirects. The bigger problem is the image pages. The urls I had in Gallery3 were:
www.mysite.com/album/imagexxx.html
whereas ZenPhoto results in
www.mysite.com/album/imagexxx.jpg.html
Are there any suggestions for how I might deal with this? Where would I hack the mod rewrite code to do this? I could perhaps edit the .htaccess, but like others I find this difficult and confusing.
Comments
Due to restrictions on the length of posts, I had to edit the following vote of thanks out of the initial post.
My congratulations to the team for such a great piece of software, especially Stephen Billard whose work I'm already familiar with from QTRGui, and to Vincent for the zpArdoise theme. I did a fair bit of customisation and hacking of Gallery3 so I'm able to resolve most of my issues myself, but have a few questions where some help would be appreciated.
Thanks! Please note that Stephen Billard is not involved in Zenphoto anymore.
Sorry for the post limit but that's to help against spam. It should only apply on the first post(s).
Zenphoto's single image urls are always
www.mysite.com/album/imagexxx.jpg.html. The.jpgsuffix is required because you could also have images likeimagexxx.pngorimagexxx.gifor even non image files likeimagexxx.mp4. Without the suffix Zenphoto would not know which it should use.You would have to put redirection from the old urls to the new ones right at the beginning of the htaccess file.
To add: Also the
.htmlsuffix (called modrewrite suffix on Zenphoto which can be customized) is required as otherwise search engines think these are pages pretending to be images which naturally is bad for SEO as well.Thanks. My images are all JPG, in which case I could presumably hack the code to do the image redirect and assume JPG. That may or may not be a great idea long-term. It may be better to generate a new sitemap asap rather than rely on a fairly deep hack long-term. I guess the question is how many hard links there are out there in the wild to individual images. If it's not so many I could also redirect them via the server.
[I realised that Stephen Billard is a former team member, but I thought perhaps that he still visited and read the forum.]
It would indeed not be a good idea to hack this in the code as the url generation is really core stuff. That may result in other issues.
You could surely redirect your old links via htaccess to the new ones. Especially if the old links all are jpg that would be quite easy. Otherwise it would have been quite impossible.
Not familiar with Gallery but the only problem might be if Gallery's album urls are the same. Then there is no way to differ between album and image.
I do still visit the forum. The "jpg" bit is there because zenphoto supports multiple types of images (jpg, png, etc.) and needs to know the full name of the image in order to find it. If you have only jpg images you can check the "unique image" option and the suffix will be removed from the links.
As I explained above already. Zenphoto actually has no "unique image" option.
It should.
I agree with Stephen. xxxx.jpg.html looks funny to me, especially if it's redundant, which is probably why I opted to remove the jpg part in Gallery3.
It's still only early days, but one thing I like about ZenPhoto is its relative simplicity. I probably made the mistake with Gallery3 of too much customisation, plus I had to rely on some fairly flaky plugins that in effect did deep hacks to the base code to do simple things like virtual albums. Out of the box ZenPhoto seems to work much closer to what I want, especially when some of the supported plugins are enabled (most of the key ones for me have Stephen's name on them). So I hope to have a simpler life with a less customised and hacked web gallery install that I used to have.
That said, I'd vote for a "unique image" option.
Sorry, no plans for such an option currently.
But we may have a general url change for image page urls in the future. But too early to tell as this can have several drawbacks.
Well, I actually moved my gallery from Gallery3 to Zenphoto and my image pages ended with "/" so my
.htaccessrewrite rules were kind of funky since album pages also ended on "/". The one that catches most of the image pages is:So yours would be something like
Thanks @MarkRH, always good if someone with the same problem/setup helps out.
Agreed. Thanks. I guess I could do something similar and use a similar kind of rewrite rule to put the jpg in a url if it's not already there, which would deal with the redirect issue.
What it won't deal with is the Facebook issue, because unless I can construct URLs exactly as I had them, I've lost all the FB likes and FB comments. At the moment I'm stuck with that as part of the migration.
I am not sure but won't those still work if redirected?
In short no. I could use the RewriteRule to turn a requested imagepagexxx.html into imagepagexxx.jpg.html in order to do the redirect, but that jpg-based url is what the Facebook code sees, whereas it was the jpg-less URL that was liked previously.
I need the reverse of the RewriteRule. I'd need to take the jpg out of the Zenphoto URL for FB to recognise it. I guess I could take the jpg out in the PHP code that inserts the FBcode. Hmmmm......... Maybe .....
I am not that familiar but isn't there is a way to update the url on FB, too, so you don't loose everything?
For the actual images, I used some thing like:
Now to get this to work I had to modify my theme to use a constant width image of 520. Also had to use my own versions of some functions to deal with just the width of 520 and no height in the image URL; otherwise, I could not predict what an image's URL would be as the hXXX part would always be different.
I did a little research and found this article on keeping likes etc when content is migrated to a new url:
https://developers.facebook.com/docs/sharing/webmasters/crawler#updating
The problem with this is that it seems to require the old site to co-exist, and I can't readily do that. I'll need to consider ways of fooling it. There are a couple of options that come to mind.
@MarkRH : I'm not sure why I need to redirect image requests. I'm mostly concerned about links that I have posted around to album and image pages. I thought that if these redirect then the images should take care of themselves. I don't think that there are any links to to actual images. I guess a Google images search will have broken links for a while, but that concerns me less in my case.
Actually the normal way to update any crawler is to setup 301 redirect as @markRH did. The old site does not need to co-exists actually since you are catching the old urls and direct them to the new ones.
The redirection of the images could also be important because FB & Co use them to embed them. Zenphoto caches images so the originals are not used so on these embeds the image may also be broken otherwise.
Facebook way != normal way
I've done a little more research on this and this problem has tripped up a lot of people. It occurs for example when you switch a site from http to https. You can fool FB by having your og:url meta tag and the url fed to the FB code snippet both point to the old url, but then you are forever getting likes and FB comments against those older urls.
Too bad. Then there is apparently no way. I really would have assumed that Facebook could handle redirections…
Actually, it gets worse. Based on the research I did, I thought I could work around this at least for the album pages by setting the og:url meta tag to the old url and also setting the url that is fed to the facebook code snippet to the old url. It's the album pages where most of the likes are. I also wrote some code to do this just for older albums, so that I wasn't tied to the old url structure permanently for new albums.
When I tested this it worked! But only once. The first time I visited such an album my likes were back. Visit a second time and more and they're gone. Wiped. How is this possible? I guess you really do have to keep the old site still live with redirects for this to work. This is insane. As you say, I'm out of luck. Completely.
The 'unique image' idea floated earlier isn't going to help. My main problem is albums, and the URL change for them is from www.mysite.com/album.html to www.mysite.com/album/ and nothing short of a deep and ill-advised code hack is going to help solve that problem. If I hadn't done that silly album URL rewrite then I'd have no problems now. Groan.
My original post was about rewrites and redirection. I've got that working now. I've created some rules in htaccess that are working well. So there's no pressing need for 'unique image', as it's not needed for redirection, and it isn't really needed in practice for FB likes. Unique image would solve the FB like problem for me on image pages, but image pages aren't the main cause of that problem, so the practical benefit would be negligible.
That said if 'unique image' ever gets implemented, I may well use it.
The end.