Tools
Popular Posts
Upgraded from Itasca on VM and now Error 500 on changing pages
Upgraded from Itasca on VM and now Error 500 on changing pages
I'm running the VM of Itasca and did the updateWiki.sh and apt-get update today. I also made some other changes that shouldn't be responsible ... adding an http proxy to apt-get and svn, and changing from a static ip to dhcp/nat.
I can view pages, but I can't edit them. Or more accurately, once I edit them, when I click save, I get a 500 error message across the top and a message saying something has broken. I rebooted the server, cleared my local cache, and no change.
The log in /var/log/dekiwiki/deki-api.log says the attached error. I can't be sure it's the cause ... but it definitely pops the same error message to the log every time I hit Save.
Some help would be appreciated
Last edited by cody : 05-09-2008 at 03:13 AM.
I can view pages, but I can't edit them. Or more accurately, once I edit them, when I click save, I get a 500 error message across the top and a message saying something has broken. I rebooted the server, cleared my local cache, and no change.
The log in /var/log/dekiwiki/deki-api.log says the attached error. I can't be sure it's the cause ... but it definitely pops the same error message to the log every time I hit Save.
Some help would be appreciated
I am experiencing this same problem.
http://forums.opengarden.org/showthread.php?t=2697
Saving an edit gives an ugly error message, but the edit actually does successfully take place. It is not recorded in Recent Changes. The user it says the page was last edited by is "User:".
Wish I knew the answer
http://forums.opengarden.org/showthread.php?t=2697
Saving an edit gives an ugly error message, but the edit actually does successfully take place. It is not recorded in Recent Changes. The user it says the page was last edited by is "User:".
Wish I knew the answer
Both of these problems are most likely because the db updates haven't been run correctly.
Try running them manually:
Be on the lookout for any errors here - most likely you changed the mysql user and didn't give them proper permissions to make the db changes.
Found a bug? Report it.
Try running them manually:
Code:
cd /var/www/deki-hayes/maintenance/; php update-db.php
mhoydis, when I edit the pages my changes aren't saved.
royk, I did try that update procedure before, I have tried again and get no errors, but page edits still don't work. There are no security restrictions on these pages, they are public. I haven't fiddled with any mysql stuff, except a few days ago I did use the mysql command to reset my password as I had forgotten it - and the new password worked fine.
Resolution: We were without the wiki for a few days. I wanted to back up the database and restore it in the new version of the VM, but the database had somehow been corrupted by the update-db command and now a bunch of links were missing.
So, instead, I created a brand new VM on the new version and I manually recreated each page in the new database. It took about an hour - luckily we only got started a week ago so there were only a dozen pages and a few dozen images to upload.
I had some errors in the WYSIWYG editor (and logged a bug report, although then realised the old version has the same behavior), and on file uploads (only happened once - and I'd since started a new VM since then and it hasn't happened).
So - back to business.
Last edited by cody : 05-11-2008 at 11:48 AM.
royk, I did try that update procedure before, I have tried again and get no errors, but page edits still don't work. There are no security restrictions on these pages, they are public. I haven't fiddled with any mysql stuff, except a few days ago I did use the mysql command to reset my password as I had forgotten it - and the new password worked fine.
Resolution: We were without the wiki for a few days. I wanted to back up the database and restore it in the new version of the VM, but the database had somehow been corrupted by the update-db command and now a bunch of links were missing.
So, instead, I created a brand new VM on the new version and I manually recreated each page in the new database. It took about an hour - luckily we only got started a week ago so there were only a dozen pages and a few dozen images to upload.
I had some errors in the WYSIWYG editor (and logged a bug report, although then realised the old version has the same behavior), and on file uploads (only happened once - and I'd since started a new VM since then and it hasn't happened).
So - back to business.
Roy, I agree that the issue is likely because the update script didn't run right. But I have run it exactly as you describe. It did not give me any errors when I ran it.
You are also correct that I've changed DB users for both wikis, but I've made sure I've added the new user in mysql console and granted it appropriate permissions.
I have a multi-tenant setup, so I did make sure to run it twice, changing my LocalSettings.php file to point to each DB as a "single setup" one at a time.
I'll try giving the update-db.php script the mysql root credentials and see what that does... stay tuned.
edit: ok I'll bite, what kind of permissions would a sql user require to make these changes?
Last edited by mhoydis : 05-10-2008 at 03:37 PM.
You are also correct that I've changed DB users for both wikis, but I've made sure I've added the new user in mysql console and granted it appropriate permissions.
I have a multi-tenant setup, so I did make sure to run it twice, changing my LocalSettings.php file to point to each DB as a "single setup" one at a time.
I'll try giving the update-db.php script the mysql root credentials and see what that does... stay tuned.
edit: ok I'll bite, what kind of permissions would a sql user require to make these changes?
I've put in my mysql root credentials into LocalSettings.php (single instance setup) and run update-db.php against one of my wikis. No change.
Code:
itops@OCSWIKI1:/var/www/dekiwiki/maintenance$ php update-db.php Updating itopswikidb on localhost permission system DB upgrade has already been performed. sprocs update complete Applying misc database updates..done cleanup up special pages anonymous user updated for all tables added 'languages' config key Done.
I have dropped the database, removed the username, flushed priviledges. restored the database and recreated the user. performed the update-db.php script against it again with the root credentials.
no dice. same situation. Though, the output of the update-db.php script was slightly different this time...
no dice. same situation. Though, the output of the update-db.php script was slightly different this time...
Code:
itops@OCSWIKI1:/var/www/dekiwiki/maintenance$ php update-db.php Updating itopswikidb on localhost permission system DB upgrade has already been performed. sprocs update complete Applying misc database updates..done cleanup up special pages anonymous user updated for all tables adding language and display_name columns to `pages` (this may take a moment, please be patient!) added 'languages' config key Done.
Join Date: Apr 2008
Posts:
27
I am getting what seems to maybe a related problem when new users try and create an account:
When I run php update-db.php I get the following error:
When I run patch-specialpages.sql on my database directly I get the same "#1364 - Field 'page_text' doesn't have a default value" error, it does not not having default values. Not really sure how to fix this. If I try to give page_text a value it says:
Last edited by stephencarr : 05-12-2008 at 05:26 AM.
Code:
Request URI:
http://localhost:8081/deki/users?dream.out.format=php&dream.in.host=wiki.lavenderdigital.com.au&dream.in.scheme=http&dream.in.origin=192.168.203.66&accountpassword=xxx
Server response:
Array
(
[exception] => Array
(
[message] => Field 'user_options' doesn't have a default value
[source] => MySql.Data
[stacktrace] => Array
(
[frame] => Array
(
[0] => MySql.Data.MySqlClient.MySqlStream.OpenPacket () [0x00000]
[1] => MySql.Data.MySqlClient.NativeDriver.ReadResult (System.UInt64& affectedRows, System.Int64& lastInsertId) [0x00000]
[2] => MySql.Data.MySqlClient.MySqlDataReader.GetResultSet () [0x00000]
[3] => MySql.Data.MySqlClient.MySqlDataReader.NextResult () [0x00000]
)
)
[type] => MySql.Data.MySqlClient.MySqlException
)
)
Code:
Query "INSERT INTO `pages` (`page_namespace`, `page_title`, `page_tip`, `page_parent`, `page_restriction_id`, `page_content_type`) VALUES (101, 'Tags', 'Special page', 0, 0, 'text/plain'), (101, 'Events', 'Special page', 0, 0, 'text/plain'), (101, 'About', 'Special page', 0, 0, 'text/plain'), (10, '', 'Template page', 0, 0, 'text/plain'), (2, '', 'User page', 0, 0, 'text/plain')" failed with error code "Field 'page_text' doesn't have a default value".
Code:
#1101 - BLOB/TEXT column 'page_text' can't have a default value
ah Ha! i'm pretty sure I figured out what my issue is.
I created a new database with the create script from 8.05, and then imported my databases from 1.9.0x, and then ran update-db.php against it from 8.05.
The script won't run correctly because a lot of the tables already exist because I created the initial DBs with 8.05 to begin with. The script isn't smart enough to detect the situation I created. Basically, it is detecting certain tables already exist (because of the creation from 8.05) and not performing patches that actually do need to be performed.
is this maybe similar to how you guys got into your situation? We seem to all have somewhat similar symptoms, but not exactly the same symptoms. After looking at the update scripts in detail I can tell how not updating the DB from it's original "home" can cause all sorts of funny issues like these.
edit: Confirmed! You can't run the update against a DB which was created with 8.05, even though it may contain 1.9.0x data. You have to create the DB with the creation script from 1.9.0x, then import data, then update-db.php from 8.05.
Last edited by mhoydis : 05-12-2008 at 09:06 PM.
I created a new database with the create script from 8.05, and then imported my databases from 1.9.0x, and then ran update-db.php against it from 8.05.
The script won't run correctly because a lot of the tables already exist because I created the initial DBs with 8.05 to begin with. The script isn't smart enough to detect the situation I created. Basically, it is detecting certain tables already exist (because of the creation from 8.05) and not performing patches that actually do need to be performed.
is this maybe similar to how you guys got into your situation? We seem to all have somewhat similar symptoms, but not exactly the same symptoms. After looking at the update scripts in detail I can tell how not updating the DB from it's original "home" can cause all sorts of funny issues like these.
edit: Confirmed! You can't run the update against a DB which was created with 8.05, even though it may contain 1.9.0x data. You have to create the DB with the creation script from 1.9.0x, then import data, then update-db.php from 8.05.
Quote:
Originally Posted by stephencarr
stephencarr,
This is an interesting find. The reason you're getting these and others aren't is that you're running MySql under strict mode. Many of our queries and upgrade scripts weren't yet tested to run under strict. I did fix the user insert query that you had issues with but there's a good chance you'll run into other issues in the application.
The upgrade script you pointed to will definitely not work under strict because it doesn't define a value for page_text (which is a blob and thus cannot have a default). You can disable strict mode and run the upgrades again and then re-enable it if you like. It's possible though that you'll run into other errors (which we'll be happy to know about!).
Here are some links for ya:
http://bugs.opengarden.org/view.php?id=3989
http://dev.mysql.com/doc/refman/5.0/...sql-modes.html
Thread Tools |
Search this Thread |
Display Modes
|
|
Linear Mode
