Basically, problem is described in topic title.

Environment data: I'm running ZP-1.4.5.5 (current version for this moment) on nginx/1.4.3 with PHP-FPM (PHP 5.3.3), located on CentOS 6. Active theme is "Default", but uses custom CSS file with some changes.

But when I'm trying to change "Standard options" (Admin -> Options -> Theme -> Albums) gallery behavior is quite strange. I have "Thumbnails per row" set to "3" and "Thumbnails per page" set to "9". When I'm trying to change these values, scripts posts data to .../admin-options.php?action=saveoptions with correct parameters, got from form, for example, 5 and 10, respectively. I got "Changes saved" or smth similar and... yes, old values!

Strange for me: request to .../admin-options.php?action=saveoptions ends with status code 302 Moved Temporarily. But response URL is "?saved&tab=theme&optiontheme=default".

Actually, any option reverts to "default" on this page, I got no errors but I can change just nothing. Any ideas?

Error logs?

The only error in nginx log is:

FastCGI sent in stderr: "PHP message: PH P Fatal error: Class 'DOMDocument' not found in /var/www/.../zp- core/zp-extensions/zenphoto_news/rsslib.php on line 85" while reading upstream, client: 188.163.232.*, server: a-photo.in.ua, request: "GET /zp-core/admin.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "a-photo.in.ua", referre r: "http://a-photo.in.ua/zp-core/admin.php"

Debug log (found inside admin panel) is empty, unfortunately. Should I turn it on explicitly somehow? Maybe I've missed it.

I would disable that zenfoto_news plugin and try once more, could be an idea... UPD: it is disabled actually.

Ok, that error means a PHP extension is not installed on your server but the zenphoto_news plugin is not required for anything (just displays news on the admin overview page).

Yes, please turn the debug log on. Maybe something goes wrong with the form submitting.

First of all I'd like to thank you for prompt replies!

I've added appropriate PHP extension so I don't have problems with those plugins anymore.

However, I feel a little stupid but I can't get a point where to turn debug log on. Do you mean ZenPhoto debug log or Nginx?

For ZenPhoto I've found various options in "global-definitions.php":
DEBUG_LOGIN
DEBUg_ERROR
DEBUG_IMAGE
DEBUG_IMAGE_ERROR
DEBUG_404
DEBUG_EXIF
DEBUG_PLUGINS
DEBUG_FILTERS

After I set "DEBUG_ERROR" to true behavior persisted, but debug log has not appeared.

I meant the server error log.

Thanks for confirmation, turning it on...

The only error I got (strange, I didn't mentioned it in Chrome's debugging console, but anyway) is an absence of ".../zp-core/js/jquery-1.10.0.min.map" file. But it is also absent in the archive I've downloaded from this site.

Have you made a copy of the theme before customizing it? If so then you need to be sure to change the "names" of the option to match. Otherwise you are sharing options with the standard "default" theme.

If you did not make a copy then on any zenphoto update your theme changes may become lost. It is always recommended that you make a copy and modify that rather than directly modify Zenphoto files.

It is normal for the redirect after the save.

PHP errors fall into two categories: non-fatal and fatal. The former will be logged into the Zenphoto debug log. But the latter abort the PHP process, so can be found only in the server error logs.

You should try saving options on other not-modified themes to see if the problem is universal or relegated to your theme.

Just to add "jquery-1.10.0.min.map" is not a file that should be there at all. First, we use the file renamed and also ship the older v1.9.1 currently.

Thanks Stephen for providing such a detailed guide to bug hunting!

Unfortunately if I choose Garland theme, for example, setting are not saved also... And my modifications were just copying default style sheet and modifying it to meet my willing, I didn't touched other files. So the problem seems to be universal. More than that, I had this problem earlier with 1.4.4.x version, on Apache server, before moving to 1.4.5.x version & nginx.

Malte, thank you very much for providing details about jQuery. I would investigate that fact also.

One other thing you can try.

Look at your database via something like phpMyAdmin and see if there is a unique key on the `options` table named "unique_options". It will be unique on the `name`, `ownerid`, and `theme`.

If that key is missing then there can be multiple instances of options which might cause your issue. If it is missing, make a backup of your database via the `backup` utility. Drop the options table, re-run setup to re-create the table, then use the backup utility to restore the database.

Finally! That was an issue - I had no unique key in options table. Thank you very much! I guess, something just went wrong during some update or, perhaps, I missed some version. Once again, thank you!

My problem has been solved.

Running version 1.4.5.7
I've come back to this post twice in the past month, as a solution to some issues I've been having. What led me here was the inabity to change anything about the gallery on the options page. I would try to increase the number of thumbs on the main page or albums. I'd get the green stripe of success, but nothing changed. So I followed the process outlined by sbillard, and it seemed to take care of it, until I had to do it again two or three weeks later.

I just did it again, and not only did it fix the inabiltiy to make changes, it sped up the loading times drastically. There near the end each time before deleting the table, it would take minutes for pages to load. Also I kept getting memory errors, ever few days. I'd up the memory, and that fixed it for awhile, but then it gave the error again. Finally passed 512M memory this morning.

Before I deleted the options table this time, I noticed that there were 848,767 rows in that table. Is that normal? I don't have that many options. Could that be what was slowing down the page loads and explains the ever increasing hunger for memory? After I ran setup again, there were 733 rows.

And finally, can you explain what sbillard meant here when he said: "see if there is a unique key on the options table named "unique_options". It will be unique on the name, ownerid, and theme."

I looked at the table with phpMyAdmin, both from the Browse and Structure views, but don't see anything by that name. There is no field by that name, in the options table, and looking all over the page, I don't see the text anywhere. Where can I see if that key exists?

Well, blah blah blah. Thought I could leave you guys alone here, but apparently there's still room for me to get lost.

[i]Also I kept getting memory errors, ever few days.[/i]
What errors exactly? PHP memory or POST exceed errors? The forms on the options sometimes post a lot and that might be more than some hosts allow technically. Although that would be hosts with a bit low limits.

Generally PHP memory issues are related to this:
http://www.zenphoto.org/news/problems-with-albums-and-images

If you have a really lot images you also might need to consider to upgrade your webpackage. Zenphoto can only do what your server allows.

[i]848,767 rows in that table. Is that normal?[/i]
You might have more options that you use as Zenphoto does store options of plugins once enabled as you might wish to reuse them if you re-enable them. But that much is not normal.

[i]"see if there is a unique key on the options table named "unique_options". It will be unique on the name, ownerid, and theme."[/i]
This is a define on the database itself. You see that on phpmyadmin as a red "u" icon on the right site if you look at the structure of a table (however for me unique is "id" and "creator" but not "theme" - I have 1900+ option entries on my local test site).

If that is not set you get duplicated entries every time an option is saved.

Thanks for the reply. I just came back to post a couple more details that may or may not be useful. You didn't ask about them, so they probably don't matter. First, this was already happening before I upgraded to the current version. Second, after the upgrade, I removed all files and did a fresh upload of the new version in case one of the files had gotten corrupted.

I don't want to take up a lot of your time for this, so I'll just bullet point replies to your questions/statements.

To try to speed things up, I had been going through to disable every plugin I wasn't using, and also I read someplace here that specifying album thumbs instead of using random thumbs would speed things up, so I've been going through to change them all to be specified.

I currently have php memory set at 550M. Haven't tried lowering it yet since deleting the options table and rerunning setup.

All my files are 720x480 at 96dpi. I never use zenphoto to upload them - just an ftp program.

My hosting package has 3.5GB memory. I don't mind upgrading if it's required, but on the other hand, I don't want to do it if I don't have to.

I have 141,629 photos at the moment.

Just checked the database, and both are unique, and like yours, theme isn't. (On my version of cpanel, unique is light blue instead of red.)

Do you think I need to upgrade my hosting package?

The server details look fine actually. How much of the 3.5GB webspace do you use already?

140,629 photos are a quite a lot and probably more than an average site has. The more images Since the sized images are generally cached and also various thumbs that might be user a lot. Also it depends on the webhost if database storage (or even mail one) also uses the 3.5GB or is extra also virtual memory of the server.

This all does not really explain those many option entries though. Maybe sbillard has anything to add later today.

Hopefully, is fixed now. Just to be on the safe side, I deleted the options table again, ran setup again, restored the database, and checked that id and creator are unique in the options table. There are now 932 rows in it. I'm not going to drop the php memory yet, but will let you know what happens when I do if you're interested.

Thanks for your help.

For anyone else reading this thread:

With the support builds of 1.4.5.7 Setup will check that all the appropriate unique keys are present in the database and will warn if they are not.

The solution is do do as hackysack did and drop the table, re-run Setup and re-load from the backup.

Re the 3.5GB of Web space: That is most assuredly not "memory" aka RAM. It is Disk storage. It is the RAM available to PHP that matters when you get out of memory errors. Also, the 550M you have set for PHP memory is advisory only. Unfortunately your server may disagree and give you much less. No way for a PHP application to determine the amount so far as I know.