Hi,
I do not know if someone experienced this problem before ?
I can access the /gallery/ index page, but if I click any album I get a 404 non found. I know that all albums are in place. The sql did generate any error. After I logged in the control panel, I could see all albums, but if I click to cache images, the script did not detect any images !!!
After many attempts, I decided to reinstalled the zenphoto v1.4.11 script. To do this, in my server cpanel, I deleted the sql db, deleted all files in /gallery/ folder EXCEPT the /gallery/albums/ folder then unzipped [zenphoto-zenphoto-1.4.11.zip] and proceed with the installation. After everything's done, I deleted the [albums] and [images] db using phpmyadmin THEN upload these two tables from the previous version. I did not want to rewrite all title in 2,000+ images gallery.

I noticed something weird about this gallery before reinstalling, the [options] table was about 3 or 4 times bigger than all my other gallery. It really looked like a corrupted db. I found out about this table, is when I wanted to change the number of thumbs per row and per page. The script did not save the new data. It kept displaying the old values.

At this point, my gallery works, but I am worry that the same problem might occur again.

Thanks.

I'm sorry but apart from much guessing there's no way to tell when, where or how things got messed up.

Note that writing a database table individually might cause issues since Zenphoto is filesystem based and matches the images/albums table with the actual files/folders found in the `/albums` folder.

But as fretzl said we can only guess. A corrupt database may cause all sorts of issues.

Hi,
This morning I experienced the same problem. The index page is ok, but no other albums can be accessed as the page shows a 404 non found.
Do you have an idea on how an index page can be displayed correctly, but no other albums ?
I know this is not related to the theme, as I used another one and I am experiencing the same problem.
I forgot to mention that all albums and files are there. When I look the url that says 404 not found. The path exists.
Thanks

Well, could be that you set the site to modrewrite but your server doesn't support it or is not an Apache server. Or it does but the htaccess file is wrong, corrupt or missing. Setup should tell about that. Also a view into the PHP server error logs might help.

Hi,
The content of the .htaccess in my gallery folder is the one created by the script during installation:
---------------------------------------------------
# htaccess file version 1.4.5;
# Rewrite rules are now handled by PHP code
# See the file "zenphoto-rewrite.txt" for the actual rules
#
# These rules redirect everything not directly accessing a file to the Zenphoto index.php script
#
<IfModule mod_autoindex.c>
IndexIgnore *
</IfModule>
<IfModule mod_rewrite.c>
RewriteEngine On

RewriteBase /gallery

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [L]

RewriteRule ^.*/?$ index.php [L,QSA]

</IfModule>
-------------------------------------------------------------

My server is an LiteSpeed.

I do not know about the modrewrite. I always do what the setup tells me to do during installation.

What bothers me the most is I can fix the problem and everything is fine, then for whatever reason, it suddenly stops.

I have just (again) reinstalled my gallery.
1. Delete the sql db and recreated it.
2. Delete all files in folder (except albums) then unzip the script.
3. Proceed with the installation.
This time I did not overwrite the gallery_albums nor the gallery_images table in MySQL. My gallery looks not good, but I have to solve this problem then having google webtools wrote to me about an increased number of 404 error !!!

That might be the problem then. I am not a server admin but about LiteSpeed I don't know anything. Maybe your server or litspeed does not support modrewrite via htaccess. Then you need to disable it on the options. Better ask your host about these questions.

Zenphoto might run on LiteSpeed – I think people did in the past as on IIS – but it is not tested or supported. We do test Apache and nginx (which our own site runs on) only.

I am contacting server to help me with this matter.
But, I have four other zenphoto gallery on this server and they all works fine.
I thought the problem was about the gallery_albums and gallery_images that I dropped and recreated from backup, but the problem reappeared again few minutes ago.
Is modrewrite via htaccess a standard procedure in zenphoto ?
I will ask the server.
thanks

Ah, ok, if you have other installs working then it probably won't be that.

Is modrewrite via htaccess a standard procedure in zenphoto ?

Yes, setup will try to find the server type, note about possibly non supported one and find if it supports modrewrite. It also creates the htaccess file if it finds that, otherwise notes that (as on nginx which does not support modrewrite or htaccess).

Generally if the database tables for albums/images doesn't match the albums on the filesystem it should sync the database with it if someone visits the site. Just adding tables to the database might or might not cause issues.

Just a 404 can mean a lot different things. But we are just guessing. You still didn't tell about log (ZP and server) entries that might shed a light on this.

Here is the content of debug.log within /zp-data :
--------------------------------------
{845548:Tue, 05 Jan 2016 14:34:09 GMT} Zenphoto v1.4.11[codeedited]
USER ERROR: MySQLi Error: ( INSERT INTO `[prefix]images` (`filename`, `albumid`, `show`, `mtime`, `width`, `height`) VALUES ('14E-Hotel-MeliaCayoCoco-Disco-06.jpg', '83', '1', '1428882806', '600', '450') ) failed. MySQLi returned the error Duplicate entry '14E-Hotel-MeliaCayoCoco-Disco-06.jpg-83' for key 'filename' in /home/myserver/public_html/mywebsite/gallery/zp-core/functions-db-MySQLi.php on line 78
trigger_error called from query (functions-db-MySQLi.php [78])
from PersistentObject->save (classes.php [359])
from PersistentObject->load (classes.php [310])
from PersistentObject->instantiate (classes.php [94])
from Image->__construct (class-image.php [152])
from newImage (class-image.php [52])
from AlbumBase->sortImageArray (class-album.php [1059])
from Album->getImages (class-album.php [1324])
from AlbumBase->getNumImages (class-album.php [385])
from loadAlbum (cacheImages.php [42])
from loadAlbum (cacheImages.php [29])
from loadAlbum (cacheImages.php [29])
from cacheImages.php [367]

Yes, that indicates a possibly corrupt database table. Possibly the database was already corrupt as you mentioned issues being the reason to re-setup it.

For the future if you can embed titles and description into the image's metadata, too. But you have to do that with some EXIF tool as ZP can't do that. Alternatively there is an XMPmetadata (an Adobe specififc EXIF/IPTC variant) that might be of help.

But what I do not understand is ... I only keep the /albums/ folder then reinstalled everything from scratch. After that, in the main control panel page, I click the [Cache Manager] to re-create the image cache for all files. That's it!

This way it should not create any problem ? or am I missing something ?

What happens if you move your existing zenphoto to another server ?

If your database is corrupt for some reason or not setup correctly as your duplicate entry log entry suggests, that will not help it. Why that might happen I cannot answer without further investigation. A database is just a file so it can break like any other because of write errors or whatever. Which as you might understand exceeds the forum quite a bit.

Here is a diagram trying to explain how the image/album discovery works: http://www.zenphoto.org/news/caching

Otherwise on a corrput database the best is to create a fresh one without importing anything. Even if that means having to re-add titles. That's why frequent backups are recommended, too. Zenphoto has a plugin for that.

interesting the caching.
by the way, what should be the CHMOD (permissions) of the .htacces in /gallery/ folder

If created by setup it it generally 444, if copied or edited manually probably 644 which is the general recommended default for files: http://www.zenphoto.org/news/permissions-for-zenphoto-files-and-folders

Generally you can set permissions as strict as your server allows/works with. That differs a bit from server to server.

Hi,
My script is running ok now. The server fixed the problem, but their answer is quite troubling.
They said the .htaccess was set to 400 ????? After I reinstalled the script, I saw it to 444 as you mentioned.
I tried by myself to changed it back to 400 to see the problem with my own eyes, then set it correctly to 644.
But (here is the punch) I am not able to change it to 400. It always reset to 644. So who set it 400 ??????
I am trying to get an answer from them.
According to your knowledge Acrylan, if it set to 400, is that normal that the index page will display correctly but ALL other albums that I click from the index page will generate a 404 not found.
Many thanks for your help

444 is what setup generally should set. As said it depends on the server configuration which permissions work. My server does not allow the strictest setup offers (except 444 for htaccess). Some servers use different users for script execution and FTP access so you have to switch before one or the other can edit or change files.

I know at least one host (gladly not mine) that has this by default.So to edit a simple php file you have to switch permissions on the host's backend. And then reset so the script itself can do its work. Very inconvenient but for some security reasons. I am not server admin so I cannot exactly help with these things. I let do that part by hosts for me as well.

thanks.
The server did not answer my question. Anyways, it works now BUT the mystery remains.
I was able to try 400 permissions using file manager in cpanel. The results was predictable : error 403 permission denied! BUT NOT 404 not found.
Many thanks for your help. If I get more information, I will update this post, in case it might help others.
This forum is a great tool!
Keep the good work.