Topic on Project:Support desk

Database returned error "1054: Unknown column 'rc_moved_to_ns' in 'field list'

I'm getting the same error in 1.21.1 that people have reported previously.

I was running on 1.16.4 and decided to update.

I downloaded and applied in sequence 1.17.5, 1.18.6, 1.19.7, 1.20.6 and all worked fine! I applied 1.21.1 in the same way and got the above error.

By applied, I mean: 1.) Untarred mediawikix-x.y.z.tgz into a reference directory. 2.) Copied old working LocalConfig.php into that directory. 3.) “cd maintenance” 4.) Php update.php 2>&1 | tee update.log 5.) Linked into my http URL "wiki".

By “worked fine”, I mean: 1.) Navigated to a page and it shows up okay. 2.) Edit page and apply a trivial change to the page, it saves okay, and it redisplays the page with the change. 3.) Edit page and remove the trivial change, and it redisplays the page without the change. I received the above error at step #2 upon clicking save.

I am running PHP-5.4.13, MySQL-5.6.13, and apache-2.4.4.

I grepped the 1.21.1 sourcecode and "rr_moved" is gone except in patches. I grepped the sql dump of the database it's also gone there. So, where does this come from? Is there some external caching going on? (I cycled apache & mysql to be sure to flush things.)

Any ideas?

Many thanks,

David david_denny@verizon.net

It's not necessary to update from version to version (unless your wiki is too old). But anyway. It's not clear from your message if you unpacked the new MediaWiki installation on top of the older installation or in a new (clean) directory. Unpacking over an old installation can cause errors because of conflicts with old files that shouldn't be there anymore, so I suggest trying to unpack 1.21 on an empty directory and then copy the required files from the old one (see Manual:Upgrading#Unpack the new files for details)

The field rc_moved_to_ns was removed from recentchanges table on 1.21, and it shouldn't be used anymore. Are you using any outdated extensions? Uninstall/Disable all extensions and try again.

Hi Ciencia,

Thanks for the note! In fact, the first time I simply jumped to 1.21.1, but restored database and went back through the installation process incrementally to determine at which step the modification functionality broke, and it was at the transition from 1.20.6 to 1.21.1. This is a repeatable observation.

No, I did not overlay the old installation but untarred without modification into unpopulated directories (/mnt/sdb1/mediawiki-1.21.1, /mnt/sdb1/mediawiki-1.20.6, /mnt/sdb1/mediawiki/1-19.7, etc.) Once untarred, I moved over ONLY the LocalSettings.php file over and then ran the update.php script.

I don't have any extensions included in 1.21.1, however any extension data stored into the database would still be there. Previously I only had ".svn" in the extension folder (can't even recall putting it there.) I did not carry it into the later releases, however I note that the extension directory in 1.21.1 has a number of directories in it, which appear to be legitimate extensions installed by default.

David

Well, if you did a grep and found nothing, that's very strange, indeed. I've also done a grep and nothing found except for patches.

I have 1.21 and it has no problems for saving edits. Maybe you can try Manual:How to debug to get a stack trace of the error, identifying what file and exact line was trying to execute that SQL sentence to see where that field comes from.

Or maybe you forgot to point your webserver to the 1.21 installation directory and it's still pointing to the old one, while you ran update.php from the command line?

Hi Ciencia,

Thanks once more for your note. I did do a grep, and the issue is very confusing to me also!

I will rerun and attempt the stack trace, probably tonight my time (EST).

I may not have redirected the web server to this installation! That is a possibility for sure! I will be sure to do that BEFORE running the update (I thought the directions carefully, but cannot recall explicitly if I did this before or after the update step!)

Either way, I'll check it out and post back!

Once again, thanks for the help!

David

Dear Ciencia,

Well, our dialog is a keen lesson in humility for me! The problem is "fixed" and of course it is a "stupid problem" that was all my fault!

I have always installed mediawiki in an obscure part of my disk space, and then done a "mount bind" to put it into a better logical spot for access by Apache. All my keen installation work was basically for naught as the system clung onto the inode of the directory it was "bound" to rather than to the "name" that I was installing to. It was, of course, the old 1.16.4 installation and so the error messages were very appropriate for it.

Having fixed my mount and done a proper re-install, all is now working fine very nicely.

The real clue was when I put in the debugging you suggested and NOTHING CHANGED. I knew then that it had to be a much more fundamental problem. I should have checked the Special:Version, but I simply did not think of that.

I don't believe I would have found this for a very long time without your help, and so I am very grateful for your time, patience, and assistance!

Best regards,

David

Well, that's good news, and a likely cause for the reports other people posted about that. Thanks for explaining the fix!

This is likely due to bugzilla:34960. Also see https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Database_error_after_updating_to_1.20.4

Another one Thread:Project:Support desk/Images Don't Work on 1.19.2/reply although for that user, recreating the database solved the issue. That doesn't make any sense!