We recently moved our site (artiraq.org/maia) to a new server. It worked properly before we moved it. Now it still works fine on the front end, but I'm having trouble with the admin end. Since moving it, I'm now unable to edit the database. I am a superuser and I cannot move items around or edit the metadata on items. If someone contributes an item, it shows up in the database, but then I can't go in and move it to a different collection. Any advice would be appreciated! Thanks.
PS We are able to update items using PHPmyadmin to update the database directly using SQL. But obviously this is not an ideal solution!
Could you be a little clearer about exactly what's happening?
- Can you log in to the admin panel at all?
- Do you see the "Edit" links on admin/items/browse?
- If so, what happens when you try to save edits?
- Do you get any error messages?
Thanks for your response. I can log in to the admin panel. I can see "Edit" and view items as usual as an admin. The problem occurs when I try to update any field for an item, add an item, add a collection, or switch an item to another collection. I make the changes in the admin interface, and when I hit "Save" it looks like it's saving, but then it goes back to the original item, unchanged. So, it seems when we moved to the new server, we lost the capability to update via admin, but there are no error messages and I can still login normally as an admin. The Contribute plugin also still works (for outsiders) but then I can't edit contributed items as an admin.
Can you successfully add items through the admin interface?
Try deactivating any plugins you have active to isolate the problem.
No, I can't add an item through the admin interface. The only way an item can be added now is through the Contribution plug in. I'd rather not deactivate plugins-- turning off simple pages would destroy the site and I don't feel I can do that at this time.
Is there a code snippet that we can stick into the admin interface that would allow us to track the error?
You can turn on error logging (
application/config/config.ini). This will log to
application/logs/errors.log, so make sure that file is writable.
As a stab in the dark, I'd also check to make sure your 'archive' directory and its subdirectories have the correct permissions to be writable by the server, and that your MySQL user in db.ini has all the permissions it needs.
Those types of error should produce an error or warning message when you try to save the file, though.
You're saying that when you click "Save Changes" on an item edit page, you get directed to the items/browse page and Omeka displays the green success message, but nothing is saved?
When I click "Save Changes" on an item edit page, the page refreshes and then I'm right back on the same item edit page but whatever change I made does not show. No green success message. Just back to the item edit page as it was before I tried to make changes.
I'll turn on error logging and check the archive directory, etc.
Thanks for your quick responses!
Ok, the MySQL database user has all privileges, and we turned on error logging and the error log is writable. But, the error log shows no errors when I try to make a change and fail.
Follow the steps at the documentation page on retrieving error messages (particularly the first section), to see if you can get some errors printed.
The behavior you're describing basically shouldn't occur. Even when there's some problem with saving an item, Omeka should display some message to you. It's acting more like you didn't submit the form at all.
The only setting I can think of off the top of my head that would cause this is PHP's
post_max_size setting. You can check this value either in your php.ini file, or by creating a script that runs
<?php phpinfo(); ?>. The default, which should work, is 8 megabytes.
So it turns out we were looking in the wrote place for the error messages. Now looking in /admin/error_log, the error reads:
[19-Mar-2011 14:39:46] PHP Warning: POST Content-Length of 8072 bytes exceeds the limit of 100 bytes in Unknown on line 0
The PHP ini settings have the post_max_size = 128M
We also tried adding these lines of code here and there: ini_set("post_max_size", "8M");
To give you a bit more info-- As an admin, I can update the simple pages the contribution form without any problems. I just can't change anything in an existing item or add new items.
Does the output of phpinfo confirm that your
post_max_size is actually set to 128M? Somewhere, PHP is getting that setting as only 100 bytes. This low setting would potentially account for the fact that some of your forms actually work, if your input to them was only 100 bytes or less.
It's possible that your setting in php.ini is either in the wrong place or is being overriden. You can't actually set
ini_set, but you should be able to do so in your Omeka
.htaccess file by adding
php_value post_max_size "128M"
<IfModule> section at the top of the file.
Yay!! It worked! :) So, in the end, it was the quotes. The 128M setting was there, but for some reason there were no quotes around it. Thanks SO much, John, for your persistence with this. What a relief!
I have just installed Omeka 2.1.2 and am having this problem. However, adding the php_value post_max_size line to .htaccess didn't solve the problem anything else it could be?
- a postscript: my ISP is running Linnux, PHP 5.2 and 5.3 and I'm using FireFox V 24.
I don't see here that your problem was fixed or even replied to. I am having similar problems with the administrative interface. I can add input to item metadata which is successful but deletions of old values fail with no error message.