About a week ago, my Zenphoto site started presenting me with an error when I try to access the gallery -- though, strangely everything works for the administrative pages...
Quote: OK
The server encountered an internal error or
misconfiguration and was unable to complete your request.
Please contact the server administrator,
webmaster@MY_DOMAIN and inform them
of the time the error occurred, and anything you might
have done that may have caused the error.
More information about this error may be available in
the server error log.
Additionally, a 500 Internal Server Error error was
encountered while trying to use an ErrorDocument to
handle the request.
Except for installing some plugins, I haven't done much to fiddle with the basic site configurations or .htaccess, and I can't think of anything that I might have done around the time this problem started...
I'm currently running:
The most recent errors I see in the Debug Logs are from September 23 and 24, and those all seem to be about errors while attempting to cache and crop image thumbnails.
For example,
Quote:{12737:Mon, 23 Sep 2013 09:17:28 GMT}
cacheImage(/Photography/[ALBUM NAME]/IMG_1097-1_100_cw100_ch100_thumb.jpg) exception: unable to extend cache `/PATH/TO/WEBSERVER/zenphoto/albums/Photography/[ALBUM NAME]/IMG_1097-1.jpg': @�˶ @ error/cache.c/OpenPixelCache/4138
{15415:Tue, 24 Sep 2013 00:10:56 GMT}
cacheImage(/Photography/[ALBUM NAME]/IMG_1123-2_100_cw100_ch100_thumb.jpg) exception: Unable to crop image
I'd uploaded a bunch of photos all at once around then, so it took a while for the thumbnails to appear properly -- but at that time, the gallery webpage itself otherwise still worked. The problem I have now, with the error message and the gallery not appearing at all, was a little while after that.
This looks like the server cache exceeds caused by the image processing for generating thumbs etc. Either you uploaded to many and/or too big images for your server to process. Please review: http://www.zenphoto.org/news/problems-with-albums-and-images
@acrylian
The page you linked probably solves a different issue from the one I'd originally started this thread about, but yeah, thanks. As suggested there, I turned off some of the image processing options and added some of the lines about memory limits to my phprc file (I don't have access to php.ini), so hopefully I'll have an easier time caching image thumbnails next time I dump a big upload to the server.
@sbillard
Since the frontend/gallery still presents the same error, I've looked through the Logs some more, but I don't know... I'm guessing the Security and Setup Logs aren't relevant, right? I don't know how a list of times I logged in or installed standard plugins would help in this situation.
Reviewing the Debug Logs some more, other than the image-caching errors I posted last night, I see two other sorts of errors before those.
Quote:{31671:Thu, 12 Sep 2013 09:58:30 GMT}
WARNING: imagepng(/PATH/TO/ZENPHOTO/INSTALLATION/cache/[ALBUM NAME]/zp-core_images_imageDefault_100_cw100_ch100_thumb.png): failed to open stream: No such file or directory in /PATH/TO/ZENPHOTO/INSTALLATION/zp-core/lib-GD.php on line 114
imagepng called from zp_imageOutput (lib-GD.php [114])
from cacheImage (functions-image.php [441])
from i.php [165]
or
Quote:{14861:Fri, 13 Sep 2013 08:33:21 GMT}
cacheImage(/Animation/zp-core_class-video_m4vDefault_100_w100_h100_thumb.png) exception: unable to open image `/PATH/TO/ZENPHOTO/INSTALLATION/cache/[ALBUM NAME]/zp-core_class-video_m4vDefault_100_w100_h100_thumb.png': @G @ error/blob.c/OpenBlob/2489
I honestly don't entirely understand what these mean. Based on the albums mentioned in the path, I'm guessing it has to do with initial issues when I was trying to setup the class-Video and class-AnyFile plugins?
However, these logs are even older than the image-caching errors I posted last night. It would be strange, if these were the source of the problem, for it to not break the frontend/gallery until nearly a month later.
And there actually are no other errors in the Debug Log -- none more recent than September 24, when the gallery still worked, anyway.
I found the server logs, but I wasn't really sure what to look for as I was skimming them. What I did find didn't really make sense to me. Then I noticed in the Zenphoto admin overview that there was an update available, so I thought screw it, I'll just reinstall...
I ran a backup of the database, deleted all the zenphoto folders and files, except for /albums and /backup and the cache folders, and uploaded the new version of Zenphoto. Now when I try to run setup.php, I get
Quote:Error 310 (net::ERR_TOO_MANY_REDIRECTS): There were too many redirects.
Chrome and Firefox suggest that it could be an issue with cookie settings (allowing all cookies doesn't fix it, though), or a server configuration problem. What's wrong now? I thought starting from scratch would fix it.
That is a server issue indeed. It could be permissions related. Different CMS but same issue here: http://stackoverflow.com/questions/14532520/redirect-loop-on-wp-admin-or-wp-login-php
See here what permissions should have been set:
http://www.zenphoto.org/news/permissions-for-zenphoto-files-and-folders
Okay, maybe I spoke a little too soon, thinking everything was fixed.
Fixing the file permissions let me finish the reinstall -- but now I'm back to my original problem, where the admin pages work fine, but the gallery presents the error that I copied into the original post. I notice I'm actually even able to access all the [i]images[/i] here, if I type in the URL directly, but I can't see any of the regular Zenphoto webpages.
Think you could give me a hint of what I should look for in the server logs?
Strangely, the Zenphoto page at Options > General, next to the URL Options, it says "Setup did not detect a working mod_rewrite facility," even though there is some code for mod_rewrite in .htaccess.
This is a fresh install, so this is the .htaccess file. I tried every combination of checking or unchecking the mod_rewrite option in Zenphoto, and commenting out the mod_rewrite code in .htaccess or leaving it as it was. No effect.
(Since nothing changed, by the way, I put both to their original settings: mod_rewrite checked in Zenphoto, and the code written in .htaccess .)
Looking again through the server logs, I also found these errors, if this means anything to you. (I've been in contact with my web host as well, but they have not been very helpful so far...)
Quote:[Tue Oct 15 16:18:01 2013] [error] [client 98.176.193.1]
Request exceeded the limit of 10 internal redirects due
to probable configuration error. Use 'LimitInternalRecursion'
to increase the limit if necessary. Use 'LogLevel debug' to
get a backtrace.
[Tue Oct 15 16:30:07 2013] [error] [client 98.176.193.1]
Request exceeded the limit of 10 internal redirects due
to probable configuration error. Use 'LimitInternalRecursion'
to increase the limit if necessary. Use 'LogLevel debug' to
get a backtrace.
[Tue Oct 15 16:30:21 2013] [error] [client 98.176.193.1]
Request exceeded the limit of 10 internal redirects due
to probable configuration error. Use 'LimitInternalRecursion'
to increase the limit if necessary. Use 'LogLevel debug' to
get a backtrace.
Zenphoto works so far on all standard shared hosts I know so far. I never encountered this issue. Do you have the right htaccess 1.4.5 file? It should be rather short and not contain much modrewrite redirects at all.
Or is there other htaccess in case you use it side by side with another CMS like Wordpress or something?
I'm baffled too -- because it [i]was[/i] working for a while. In fact, the Zenphoto instance I'm using for a different website with the same host still works, but for some reason this one does not. I've triple-checked, but the .htaccess file is the same one that ships with the current release of Zenphoto. I [i]am[/i] running a WordPress for this problem domain, but the WordPress is at www.MyDomain.tld, while Zenphoto is at media.MyDomain.tld. I'm pretty sure there is no .htaccess file which would affect both subdomains.
My web host's support representatives are insisting that it's an issue with the application, not a server problem, and therefore outside of their purview. One did notice that the Zenphoto cache folders (which I'd saved from before I'd tried reinstalling Zenphoto the other day) had sym links pointing to locations which no longer exist, so I tried cleaning those out, and then changing the name of the cache folders (instead of deleting them)... All to no effect.
Regarding the symlinks. If the server allows Zenphoto will create those to the full images if the size cached is the same to avoid double images. Otherwise they would be copied. Clearing the image cache should fix that.
A mysql issue could be involved but that has actually nothing to do with redirections. But the error says actually about redirects which is just htaccess/modrewrite redirecting. Unless we have some more info what is redirected the server complains about we cannot help much. Your host should help with that. If you still get that error try to disable modrewrite on the zp options.
Disabling mod_rewrite, either through the Zenphoto admin or through commenting out the script in .htaccess, doesn't seem to make any difference.
Maybe an interesting development, though: I was looking around in the admin pages, just reviewing any options that had anything to do at all with the frontend/gallery, even though it's all running the default PHP, HTML, and whatever other scripts from unzipping the current release. Since clearing the image cache, the only files I've added or changed without changing them back to their default setting is the images in albums/ and the database which I'd backed up before reinstalling... But I looked anyway, and eventually I tried changing the themes. Here's what happened.
[list]
[*][i]Default[/i]: This is the theme I had been using before, so it presents the same error as the original post.
[*][i]Effervescence+[/i]: The gallery web page actuallys renders! But it doesn't show any albums on the front page. Browsing through the archive (sorting by date instead of album) still seems to work, though.
[*][i]Garland[/i]: like Effervescence+, gallery doesn't show any albums on the front page, but the archive pages work.
[*][i]Stopdesign[/i]: error from the original post.
[*][i]Zenpage[/i]: error from the original post.
[*][i]zpMobile[/i]: in the gallery, a web page renders, but only showing the header and footer; it doesn't display any of the albums, and the archive pages don't work either.
[/list]
I've looked through the server error logs some more, and in the last couple days' logs I notice another error cropping up...
There's more of the errors I'd posted the other day about too many redirects. But then there's also a bunch of these...
Quote:[Fri Oct 18 14:51:17 2013] [error] [client XX.XXX.XXX.X] Premature end of script headers: [i]index.php[/i], referer: https://media.MYDOMAIN.tld/
[Fri Oct 18 14:51:27 2013] [error] [client XX.XXX.XXX.X] Premature end of script headers: [i]index.php[/i], referer: https://media.MYDOMAIN.tld/index.php?p=pages&title=
...
[Fri Oct 18 15:30:56 2013] [error] [client XX.XXX.XXX.X] Premature end of script headers: [i]i.php[/i], referer: https://media.MYDOMAIN.tld/index.php?p=search&date=2013-06
[Fri Oct 18 15:31:07 2013] [error] [client XX.XXX.XXX.X] Premature end of script headers: [i]i.php[/i], referer: https://media.MYDOMAIN.tld/index.php?p=search&date=2013-06
Quote:Strangely, the Zenphoto page at Options > General, next to the URL Options, it says "Setup did not detect a working mod_rewrite facility," even though there is some code for mod_rewrite in .htaccess.
This means that at least as far as testing is concerned your server does not support mod_rewirte. So you definately should have that Zenphoto option set off. BTW, only that option would be able to help. Just because there is .htaccess code does not mean it works. That is standard code.
A web search quickly returns http://www.liquidweb.com/kb/apache-error-premature-end-of-script-headers/ I admit that I do not understand all these, but we have seen problems related tp suEXEC (#3) and file/folder permissions(#5) have also been known to cause these kinds of errors.