Problem came up in 1.4.2, I upgraded to 1.5 and problem still exists.
I enter settings in Omeka admin and hit save. "Settings saved" message appears, but all fields are set to zero.
I can update database directly and entries stay until I use Omeka admin and press "save". This is not an acceptable workaround, as someone will press that button and wipe out all of the settings.
NOTE: site was just migrated from a different host that had
Any help will be much appreciated!
Added info: only plugin we were doing much with was Contribution.
Tried to update -- said it had -- but "upgrade" button remained. Did upgrade to 1.5 anyway -- even though I couldn't deactivate contribution.
After upgrade to Omeka 1.5, and copying Contribution plugin over from 1.4.2 folder, still see upgrade button. "Contribution successfully updated" at top and "New version of contribution -- please upgrade" in plugin list -- after refreshing page.
So, every time you click save on the Settings page, all the settings get reset to zero. Does that include things that don't normally have numbers for a setting (like the administrator email)?
Can you save on other pages (like the Add Item page) without a problem?
I can't think of anyone else reporting a problem like this.
The only fields that are not set to zero are:
image sizes, thumbnail sizes, and items per page (admin and public).
Admin email, site name, copyright, description and path to covert (imagemagick) all go to zero.
My php engineer who I usually consult with and who uses the same hosting company and recently moved to their smart servers too, suggested that after the move there were some php config settings that needed tweaking. Most of my sites on the VPS use Joomla, WordPress or SquirrelCart. The site in question is my only Omeka site.
Can you think of any particular requirements of Omeka?
I ran a complete clean install of Omeka 1.5 with a new database, and with no plugins, themes or content beyond the initial general settings, the clean install failed in the same way. A clean install on a different host was fine, so there's nothing wrong with my install files.
The strangest part of what you described is that the fields that are supposed to be numbers are the only ones that didn't get reset to zero.
I'm not aware of anything that would cause this, but you could check your server's Apache or PHP logs to see if any errors are being logged that might be helpful.
I'm not seeing any errors being logged. I changed httaccess and config.ini to enable error messages -- but don't get any.
The PHP and Apache logs are different from the Omeka logs that config.ini deals with. They're often available via cPanel, if your hosting company is using it.
I see this error:
[08-Mar-2012 01:44:34] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-non-zts-20090626/fileinfo.so' - /usr/local/lib/php/extensions/no-debug-non-zts-20090626/fileinfo.so: cannot open shared object file: No such file or directory in Unknown on line 0
On install there was a message about fileinfo.so, but I read it as a warning, not that it's absence would cause the whole thing to break.
Could this be the problem?
After a week of troubleshooting, installing and testing Omeka on various servers and comparing php settings etc. we finally narrowed it down to the version of mySQLi php library.
The "bad" server was running 5.0.95 while a friend's server was successful with 5.0.92 and BlueHost was successful with 5.1.60.
I had my host update to 5.1.60 and it has solved the pesky problem.
A strange problem, but glad to hear that you figured it out.
Sorry we couldn't be more helpful, and thanks for posting what ended up working for you.
Well, the settings save, but now I have tried up add an image and got several errors:
Mysqli statement execute error : Incorrect key file for table './squareda_omeka/omeka_element_texts.MYI'; try to repair it
How does one repair the data table?
You certainly have had some interesting MySQL problems.
You can run the SQL command
REPAIR TABLE omeka_element_texts through your database admin tool to repair that table (your tool likely also has a graphical shortcut for doing this).
Dropping your Omeka tables and reinstalling them would also probably resolve this (it may be an issue that arose when your host upgraded MySQL).
The host repaired the table for me -- and I'm pretty sure this problem was related to upgrading the MySQLi php library.