# Update previous MW 1.16.5 to 1.17.0 throws an 500 internal server error

MediaWiki: 1.17.0 (files), 1.16.5 (db)

PHP: 5.2.17 (cgi)

MySQL: 5.0.91-log

I recently updated from 1.16.3 to 1.16.5 and now wish to upgrade to 1.17.0.

using the new web installer, I was able to get to the point where it upgrades the DB, but it then throws an "Error 500 - Internal server error"

Here is an example of the fact that the DB is not updated.

When editing a page.

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

   SELECT iwl_prefix,iwl_title FROM mw_iwlinks WHERE iwl_from = '1473' FOR UPDATE

from within function "LinksUpdate::getExistingInterwikis". Database returned error "1146: Table 'db278724580.mw_iwlinks' doesn't exist (db738.perfora.net)".


I already looked at this Manual:How_to_debug and I cannot get the debug .txt file to work. Calebrw 23:47, 27 June 2011 (UTC)

Calebrw23:47, 27 June 2011

I habe the same 500 error but was able to trace it down to:

Invalid or missing localisation cache.

Backtrace:

1. 0 C:\inetpub\wwwroot\_sdwiki\includes\LocalisationCache.php(268): LocalisationCache->initLanguage('en')
3. 2 C:\inetpub\wwwroot\_sdwiki\includes\LocalisationCache.php(536): LocalisationCache->getItem('en', 'deps')
4. 3 C:\inetpub\wwwroot\_sdwiki\includes\LocalisationCache.php(358): LocalisationCache->recache('de')
5. 4 C:\inetpub\wwwroot\_sdwiki\includes\LocalisationCache.php(268): LocalisationCache->initLanguage('de')
7. 6 C:\inetpub\wwwroot\_sdwiki\languages\Language.php(2853): LocalisationCache->getItem('de', 'fallback')
8. 7 C:\inetpub\wwwroot\_sdwiki\languages\Language.php(179): Language::getFallbackFor('de')
9. 8 C:\inetpub\wwwroot\_sdwiki\languages\Language.php(142): Language::newFromCode('de')
10. 9 C:\inetpub\wwwroot\_sdwiki\includes\StubObject.php(126): Language::factory('de')
11. 10 C:\inetpub\wwwroot\_sdwiki\includes\StubObject.php(103): StubContLang->_newObject()
12. 11 C:\inetpub\wwwroot\_sdwiki\includes\StubObject.php(57): StubObject->_unstub('getCode', 5)
13. 12 C:\inetpub\wwwroot\_sdwiki\includes\StubObject.php(121): StubObject->_call('getCode', Array)
14. 13 [internal function]: StubContLang->__call('getCode', Array)
15. 14 C:\inetpub\wwwroot\_sdwiki\includes\MessageCache.php(525): StubContLang->getCode()
16. 15 [internal function]: MessageCache->get('mainpage', true, true)
17. 16 C:\inetpub\wwwroot\_sdwiki\includes\StubObject.php(58): call_user_func_array(Array, Array)
18. 17 C:\inetpub\wwwroot\_sdwiki\includes\StubObject.php(76): StubObject->_call('get', Array)
19. 18 [internal function]: StubObject->__call('get', Array)
20. 19 C:\inetpub\wwwroot\_sdwiki\includes\GlobalFunctions.php(781): StubObject->get('mainpage', true, true)
21. 20 C:\inetpub\wwwroot\_sdwiki\includes\GlobalFunctions.php(744): wfMsgGetKey('mainpage', true, true, true)
22. 21 C:\inetpub\wwwroot\_sdwiki\includes\GlobalFunctions.php(688): wfMsgReal('mainpage', Array, true, true)
23. 22 C:\inetpub\wwwroot\_sdwiki\includes\Title.php(318): wfMsgForContent('mainpage')
24. 23 C:\inetpub\wwwroot\_sdwiki\includes\Wiki.php(122): Title::newMainPage()
25. 24 C:\inetpub\wwwroot\_sdwiki\index.php(60): MediaWiki->checkInitialQueries(NULL, 'view')
26. 25 {main}

any help would much be appreciated!

213.227.166.11907:45, 28 June 2011

I unfortunately can't access the command line. There must be a way around this? The help suggest "Use the confic script", which is a nice doom loop... There are hundreds of people that have this exact problem, but somehow nobody posts a solution (just the problem ^^)! The installation of MediaWiki was tricky enough, why does the update have such obstacles? i've never had any problems with any script installation, exept with mediawiki, it's allways a huge hassle... So help would be very much appreciated!

92.73.220.11417:35, 8 July 2011

If you're referring to the "Invalid or missing localisation cache" - it has nothing to do with this thread, and has nothing to do with the updater (If you're referring to that problem, please bring it up on a new thread instead of hijacking this one). For generic problems with the upgrader, you can try something like extension:MaintenanceShell if you're desperate. Or you can apply the sql updates in maintenance/archives by hand (but first you have to figure out which one's you need which can be tricky)

Bawolff17:54, 8 July 2011

i have the very same problem, any help would be appreciated

178.198.5.6009:14, 22 August 2011

There are multiple problems described in this thread. Which one are you having?

Emufarmers(T|C)09:44, 22 August 2011

It'd help to know what the error was that the web installer threw. The debug.txt file is generally not very important for 500 errors (honestly, it almost never contains useful information unless you're a mediawiki programmer). More important is making sure that php displays errors (Its best to set that setting in your php.ini file if possible). Also check your apache error log too (If it was a very plain black writing on white background 500 error, it could be an apache issue, although that'd be weird)

However, the fastest way to fix the problem would be to try to run the update.php script from the command line if possible

The localisationCache issue 213.227.166.119 posted is totally different from your issue. I'm very doubtful they have anything to do with each other.

Bawolff07:47, 1 July 2011

I finally was able to run update.php from the Command Line, but after trying to load a page, I got the following error:

Fatal error: Out of memory (allocated 30670848) (tried to allocate 35 bytes) in /homepages/2/d276811108/htdocs/w/includes/parser/Preprocessor_DOM.php on line 925

Calebrw00:00, 4 July 2011

Increase PHP's memory limit.

Emufarmers(T|C)07:08, 4 July 2011

I can't access the root php.ini files and local php.ini does nothing, but every time the script maxes out memory on /includes/parser/Preprocessor_DOM.php. Any ideas?

Calebrw04:03, 5 July 2011

The preprocessor is probably one of the more memory-hungrey parts of MediaWiki if you're rendering a very complex page (I assume anyways). Also check your LocalSettings.php file. Some really older versions of MediaWiki had a line setting the memory limit to something way too low. (However, MediaWiki 1.17 will automatically try to raise the memory limit to 50 mb if it detects if its lower than that).

You could also try adding a line like ini_set( 'memory_limit', '50M' ); to the bottom of LocalSettings.php, but MediaWiki already does something similar, so it probably wouldn't work.

Bawolff04:50, 5 July 2011

FYI

Code at the above location is:

\$outStack = array( '', '' );

Calebrw05:03, 4 July 2011

I'm having a similar problem. For some reason unknown to me I can't start a new thread, so I've posted on the talk page instead: http://www.mediawiki.org/wiki/Project_talk:Support_desk

Cavila14:14, 13 July 2011

This well documented problem seems to be on the "ignore list". Will there ever be a solution to it? Very frustrating to follow instructions to the letter and have this occur.

SNEWebmaster15:14, 30 July 2011

There are multiple problems described in this thread. Which one are you having?

Emufarmers(T|C)01:40, 31 July 2011

The one as shown by the original poster. Further, the following error message now shows whenever a page edit is made. The edit is successful, but just with this error showing up upon clicking Save Page:

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

   (SQL query hidden)


from within function "LinksUpdate::getExistingInterwikis". Database returned error "1146: Table 'db369199228.iwlinks' doesn't exist (db369199228.db.1and1.com)".

SNEWebmaster14:19, 31 July 2011

You need to run the upgrade script. In the OP's case, his memory limit was too low; you should check your error log to see what the problem is in your case (assuming you're getting 500 errors when you try to upgrade).

Emufarmers(T|C)22:00, 31 July 2011

I actually solved the problem by installing PuTTY and using SSH. Once logged in I followed the instructions and it worked like a champ (php5 upgrade.php in the maintenance directory).

That said it still doesn't explain or eliminate the fact that the web interface did not work for me, and seemingly many others. I had never even used SSH before today; the web interface has always worked without fail for me despite not being the "ideal" way to upgrade.

Thanks for your help, I hope others are able to resolve their issues with this.

Scott

SNEWebmaster23:29, 31 July 2011

Edited by author.
Last edit: 19:54, 12 September 2011

MediaWiki: 1.17.0 (files), 1.16.5 (db)

PHP: 5.2.14 (cgi-fcgi)

MySQL: 4.1.24-max-log

Using a shared hosting provider. URL: http://musicnotation.org/wiki/

Like the original poster, I ran into a similar 500 internal server error while using the web installer. At the point where it was to upgrade the database from 1.16.5 to 1.17.0, it immediately returned this server error (black text on white screen):

Error 500 - Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator and inform them of the time the error occurred, and anything you might have done that may have caused the error.

Apache Server at musicnotation.org Port 80


(Unfortunately I'm not savvy enough to know how to access the server error logs.)

After clicking the back button, the web installer indicated that installation was complete. Surfing through the wiki, everything seemed to be fine and working, Special:Version showed 1.17.0. The only problem I noticed was the links at the top left of the page. The usual "Page" and "Discussion" links had no text in them (but the links were still there if you hovered over the blank tabs). On category pages these links read "Category" and "Category" instead of "Category" and "Discussion." Finally on special pages the link text was "& l t ; vector-namespace-special & g t ;" (but without the spaces).

I found my way to this discussion, and so I tried restoring the database from backup and running the update.php file from the command line using SSH. (I had to learn how to use SSH, which was new to me, and enable SSH access with my hosting provider.) At first it wouldn't work because it was trying to use PHP4, until I found this advice on the Upgrading page that tells how to force it to use PHP5. (Maybe it was using php4 that caused the internal server error?) Then update.php ran successfully. However, the links at the top left of the page are still not fixed, and still appear as described above.

Any advice on how to fix them is welcome, thanks.

Waltztime19:22, 12 September 2011

That's the sort of weirdness I'd expect if you had had the Vector extension in 1.16 and kept it installed in 1.17 (where Vector is built in).

Emufarmers(T|C)19:50, 12 September 2011

Thanks for the reply. That's probably it, as I did have the Vector extension installed under 1.16.

But I removed it before upgrading to 1.17. At least I thought it was fully removed -- I deleted the files from the extensions folder and removed the references to it from LocalSettings.php. I have installed the newer version of it (for 1.17) after the update and it did not affect the link problem. Was removing it before upgrading the right thing to do? Any suggestions for how to fix it at this point?

Also, not sure if this is relevant or not, but I followed these instructions at the bottom of the Manual:Upgrading page to do the update. So setting up a separate 1.17 directory, and then copying over the relevant files (extensions, skins, images, LocalSettings.php, etc).

Waltztime20:03, 12 September 2011

Vector extension isn't compatible with 1.16 (perhaps thinking of usability intiave). Also Vector skin and vector extension are totally different.

It sounds like you forgot to upgrade the Language files (in the languages subdirectory). That would cause the issue you described above

You should try to find your apache error log (common place /var/log/apache/error_log ) the 500 error you described doesn't sound like a MediaWiki issue but more a server config problem.

Bawolff20:57, 12 September 2011

Yep, I meant the usability initiative extension under 1.16 (the vector part of it).

Following your language files suggestion, I replaced the languages directory with the old one from the 1.16 install (since the links appeared correctly under the old install). This didn't work, the wiki pages wouldn't load at all because of some error in accessing a language file (not surprising).

But when I put the original languages directory back, what do you know but the page links were fixed and had returned to normal! Maybe this refreshed a cache somewhere? Now that I think of it, I don't believe I even tried clearing my browser cache, which could have been causing the problem (duh).

The only thing I've noticed now is that on the Special:Version page, it shows "<version-poweredby-credits>" and "<version-license-info>" instead of the usual text under License. That wasn't there before, but maybe an old version of that page was in the browser cache too?

I'll see if I can find the error log for more on that 500 error. Thanks to you both for the assistance!

Waltztime21:43, 12 September 2011

I spoke too soon. The links are now back to their broken state, not sure what I did. Text is back on the Special:Version page, so that's good. It does not seem to be related to the browser cache. Still working on finding the 500 error log.

I also tried using a fresh copy of the languages directory from the 1.17 .tar download. But that didn't seem to change anything.

Update 1: I had previously made some customizations to the Vector skin, and copied that modified vector skin over to the new 1.17 installation. But I find that switching to the Vector skin that ships with 1.17 fixes the link problem!

Update 2: So, it seems that was the problem. The Vector skin changed a significant amount between 1.16 and 1.17. So my modified vector skin from 1.16 was not working right under 1.17. I re-did the modifications to the 1.17 Vector skin, and all is working great now.

My only remaining problem is that I ended up having to modify the Vector skin itself rather than duplicate and rename it as described here, because I couldn't get it to work when I tried it. I got the same error (Call to a member function getGroup() on a non-object in /var/www/runa/includes/OutputPage.php on line 2707) described by someone else at the top of that page's talk page. I did not know what "register your skin's module: in FooBar.php's global scope:" meant.

Waltztime22:32, 12 September 2011

Global scope means outside of any function definitions (So like after the <?php but before anything else.

Bawolff19:26, 13 September 2011

Waltztime04:48, 14 September 2011

Hi our WIKI has a similar problem, can you point me out in the right direction or some kind of check list on how to fix the problem? 109.64.217.2 13:49, 19 September 2011 (UTC)

109.64.217.213:49, 19 September 2011

You're going to have to be more specific. This thread is about at least 9 totally unrelated problems. (Actually it'd probably be best if you created a new thread, instead of adding to this one). I can't see anything wrong from a quick glance, other then you're missing some language files from the looks of it.

There is a list of things to do to debug at Debugging

Bawolff23:31, 19 September 2011

it's the same problem with tab names, after upgrading our wiki to MediaWiki 1.17.0, Something got messed up with the tab names, most of the tab names has lost it's names, here is an screenshot to ilustrate the problem. Mor2 17:44, 20 September 2011 (UTC)

Mor217:44, 20 September 2011

To ask the obvious question, are you sure you upgraded the language files properly?

Bawolff21:43, 20 September 2011

Thanks for your help. the language files were correctly updated, but like 'Emufarmers' suggested before, we too had the Vector extension installed under 1.16 and after the upgrade. removing it and purging the cache doesnt seem to be make any difference. any suggestions on how to proceed?

Mor221:28, 23 September 2011

Mor2, Try changing your wiki's skin to the version of the Vector skin that ships with MW 1.17. I was able to fix the same tab problem you're seeing by switching to the Vector skin that ships with MW 1.17. (See above in this thread.)

Waltztime17:17, 23 September 2011

maybe it fix that problem but it brakes everything else (screenshot)

Mor221:36, 23 September 2011

That's the (old) standard skin. If you're getting that it means the vector skin does not exist, and you did something very wrong. The version of vector that ships with 1.16 is not going to work with 1.17. Please just download MediaWiki and use the version of vector that is in the tar file you download (The only thing that you should keep from your older version when upgrading is the extension directory, the image directory, the math directory [if using texvc] and your LocalSettings.php). Upgrading only some directories of a MediaWiki install and not others is just going to screw things up...

Bawolff02:09, 25 September 2011

Ok we manage to fix that problem, however there is another tiny problem, that I would appreciate some help with. The 'new pages' tabs do not show in red and the new pages itself has some weird numbers popping at the corner of the screen. i realise that my description probably isnt that good so I have created an illustration for you guys.

Any ideas what the problem might be or what is the relevant code that we should be looking into? Mor2 12:57, 9 October 2011 (UTC)

Mor212:57, 9 October 2011

that's rather odd. If i were to guess, looks like someone inserting some debugging code or something like that.

Bawolff14:18, 11 October 2011