Help talk:Upgrading MediaWiki

Before proceeding on this page, please note the dates of these posts. Some, or all, are extremely old!

(The "most recently edited" date is found at bottom of the page.)--Eplater (talk) 07:07, 15 January 2018 (UTC)

I am hosting my mysql database on godaddy.

I am also hosting the mediawiki files on godaddy. I am trying to upgrade from 1.5 to 1.7 and am having no luck. I backed up my database, and all the wikimedia files. Then I replace all the old files with the new ones using an ftp program. The last step says to run the update.php using a command line. I am not sure what this means. Opening the command prompt on my windows machine will do nothing obviosly since the program is hosted not on my computer, but on godaddy. I have tried entering RAW commands using my FTP program to no avail. so, How do I run the update.php file located on the server? Thanks!

PP: A different provider, but I have the same challenge. Why is it not possible to run this update script from the godfather-role?

PP: This is the help I got from

1. GNot Says:

October 15th, 2006 at 2:32 pm

The above way of upgrading assumes that the hosting service provides shell access (most probably through SSH) to your account and, furthermore, access to the php interpreter from the command line. It seems that this is not possible in your case.

There are alternative ways of upgrading, which cover your situation, but please look for them in the official Mediawiki documentation.

PP: Question does sanyone know where to find the official Mediawiki documentation regarding this subject

Godaddy requires file extention .php5 in order to use PHP5

The problem I've been having with this same upgrade is that .php files use php4 by default on Godaddy. I've been told that to use PHP5 the files extentions need to be changed to .php5. I am scared to waste this much time and potentially lose or break things. Also, if I choose to do so, I assume I will be able to figure out a way to script this, otherwise that is a lot of file extentions to change. Anyone have any advice here?

• The solution provided by godaddy recommends adding the following to a .htaccess file in the root directory.

AddHandler x-httpd-php5 .php
AddHandler x-httpd-php .php4

(see http://help.godaddy.com/article.php?article_id=1082&prog_id=GoDaddy&isc= for more info)

upgrading/installing on read-only file-system

I may be in kind of a unique situation... I've been using mediawiki on sourceforge for collaboration on a project I'm working on. They've recently changed their file-system to be read-only for the web server. I'm kind of at a loss as to how to go from 1.3.8 to 1.5.2. I tried copying over the LocalSettings.php and running the command-line scripts, but I get a bunch of undefined constant warnings followed by:

PHP Fatal error: Call to undefined function: wfsuppresswarnings() in /home/groups/d/di/dirtywater/htdocs/mediawiki-1.5.2/languages/Language.php on line 2892

I can't run the normal install script, obviously, because I can't make my config directory writable.

Sean (sproctor@gmail.com)

Upgrading from 1.3.x -> 1.4.3, Missing Step?

Hello, I'm wondering what step I may be missing in our update from 1.3.x (I think 1.3.9) to the current 1.4.3 version...I think the PHP side of the upgrade went fine, but it seems the MySQL database was not upgraded as (new) MySQL tables (and their fields) seem to be missing as we get error messages about this... How can we now update the MySQL database to include the new/changed tables/fields without losing all the content they contain? Thanks! Brettz9 17:15, 13 May 2005 (UTC)

Issues upgrading to 1.5

When upgrading 1.4.9 to 1.5 neither the upgrade1_5.php nor the update.php scripts changed my charset on the latin1 tables to UTF8. It would be nice if they did that. --66.125.84.178 20:37, 20 October 2005 (UTC)

Same problem here. And, as I have Umlauts ("äöüÄÖÜ") in article names, these articles are no longe accessible :-(

Any ideas how to fix this or install the update in a proper way?

Same problem here. You can still access the content of the articles with umlauts in their name through the oldid, like so: index.php?action=edit&oldid=1234. You get the oldid when you open a diff from the recent changes or you contributions list.

I only had about 20 pages in my private wiki, so I replaced all the "?" where needed. But of course this isn't an option for larger wikis :-( --Kurt Jansson 03:32, 7 November 2005 (UTC)

Same problem here ... i have an wiki with ~2000 pages - most of them have "Umlauts" ("äöüÄÖÜ") and now, after upgrade to 1.5, this pages not more accessible :( .. exists any solution for that problem? --160.58.8.71 14:05, 1 May 2006 (UTC)

Utter crap

I can't beleive the junk found on this page! between the guy who says the upgrade scripts are run when installing over an old install and the guy who says 'don't run the upgrade scripts' in his 'upgrade guide' - what a joke. The update file given with 1.5.2 is also rubbish! Get your act together we need documentation!

It is confusing, I know, but please remember that this is free software! Maybe if you figure out how to get it working you could come back and rewrite the page so everyone benefits from your new knowledge. --HappyDog 13:04, 24 November 2005 (UTC)

Why is it so hard to perform an upgrade? Is the upgrade script not maintained? I agree with the free software arguement. If I had a choice, I would have gone elsewhere a long time ago, but that is not an option. We need a clear step by step approach (from preferably a developer) that is in english. An approach that doesn't involve the commandline would be nice as well. Most people don't run their own servers and usually in shared enviroments, only have limited rights (I would never be able to restart Apache, and what short-sighted requirement makes this necessary?). I look forward to any helpful response. cody.foss@uleth.ca

I have to agree. I'm trying to upgrade now -- using the command line, and I must say this is the most difficult and frustrating bit of maintenance I've ever done. I'm not sure how this being free software is relevant to the conversation, though. There are plenty of open source packages that upgrade with an easy upload and snap of the fingers. I'm really at a loss for why this should be so difficult. --Wolf530 20:10, 14 January 2006 (UTC)

The point is not that it is free as in "free to the user" but free as in "developer's don't get paid". The software is primarily written to manage the Wikimedia projects, but having developed the software for that purpose it has also been made available to anyone else who wants to run a wiki. The developers listen to and actively help out users, if you use the appropriate channels of communication. They will not, in general, spend their time on documentation as (a) it is not fun and (b) it is not the most productive use of their talents.

Better documentation will come from users bothering to come back and update these pages (as some users have done) rather than just muddling through, figuring it out but not actually telling anyone what they did.

Regarding automating the install process, Mediazilla bug 198 deals with this issue, so perhaps you could make some suggestions there (concrete suggestions, mind - not just complaints!).

I agree that the upgrade process is at best confusing, and outside the ability (technical or practical) of a lot of users. I also agree that an overhaul of the docs *in general* is long overdue. However, shouting at hard-working volunteer programmers is not the way to go about getting it done! --HappyDog 19:35, 17 January 2006 (UTC)

I hate to slag the developers. I'm sure they're all hardworking people and are doing what they can. Unfortunatly the upgrade process is horribly flawed (difficult, commandline driven, and total lack of documentation including meaningful error messages) and is almost exclusively in the domain of the developers. Add to that, this leaves people open to all sorts of malace if they can't figure it out.

The developers are probably the only group that can comment on the process intelligently and give reasonable explanations of why things are not working. I'll take your advice make suggestions on the bugfix page. I look forward to any help people can post to these instructions. cody.foss@uleth.ca 13:39, 3 February 2006

Use update.php from commandline

The Mediawiki documentation in the upgrading section mentions "using update.php" in several places, but doesn't explain how to. The UPGRADE text file distributed along with the wiki even says that the command used should be "php update.php", but what if the response is "php: command not found"? Please explain (maybe in the "prerequisite tools" section somewhere here) what else should be installed to get this to work? Mediawiki works for me basically, just this is the detail I can't find out. FBSD 5.4 82.210.159.30 19:37, 25 February 2006 (UTC)

You have to invoke it using php. It sounds like the php executable isn't in your path. Try typing php --help. If you get back the same message, then you need to find out where it's installed. If you're running Windows, it's wherever you put it (I think the default is C:\php). If it's on Linux, it's probably in either /usr/bin or /usr/local/bin. Once you figure out where it is, you can either type the absolute path to it (C:\php\php update.php, for example) or add it to you path. To do the latter in Windows, look at the properties under My Computer and on the Advanced tab, click the Environment Variables button, and add the path in your PATH system variable. To do the latter in Linux, edit your ~/.bash_profile file (for just yourself, how you'll likely have to do it if you're on a web hosting server) or the /etc/profile file (for all users) so that it has the following line in it:

PATH=${PATH}:/usr/local/bin (or wherever your php executable is located)

Hope this helps, Tony V 09:25, 27 February 2006 (UTC)

Thanks. The problem was that I only had installed php4_mod (this is why the whole thing worked), and not the general php4. I deinstalled php4_mod and installed the php4 instead, which provided the php4_mod back _and_ the required php binary to run the script from the command line. BTW. I run neither Windows nor Linux; the "FBSD 5.4" in my message is the information about the OS I run (FreeBSD 5.4), my excuses for being too short. 82.210.159.30 04:22, 2 March 2006 (UTC)

On Mandrake/Mandriva Linux you may not have the CLI version of PHP installed. If so php -v at the command prompt will return not found. urpmi php-cli should install the binary for you.

My upgrade experience...

Well, I don't know if anyone cares, but I just recently upgraded the Paragon Wiki from MediaWiki 1.4.9 to 1.5.6. My head is still sore from bashing my head against the wall. On my test system, the biggest problem I had was that the media type (img_media_type), mime type (img_major_mime and img_minor_mime) and image dimensions (img_width, img_height, and img_metadata) aren't stored correctly in the new schema's wiki_image table, and the image dimensions (oi_width, oi_height, and oi_bits) aren't stored correctly in the wiki_oldimage table.

As a result, all images were shown only as links, and if I opened the link, it still wouldn't show the image. If I navigated to the image location manually or through the image's article, it would work, but this wasn't very useful. The rebuildImages.php script fails, both on my test server and my hosting server. On the test server, it dies after saying something like, "Surprising mime type." On the hosting server, it dies after the very first line says, "Processing image..."

Eventually I wrote a script to use ImageMagic to suck the dimensions out and autogenerate a .sql file to update the tables with the information manually. I haven't used it yet on the hosting server, because unlike on my test server, the images are working, and when I pull up an image, I noticed that the database is updated. Still, I probably will at some point because I don't want there to be any future issues with the information not being correct in the tables. (And, not to put too fine a point on it, I want to be able to restore database backups to my test server and it actually work...) I hope this won't break anything (anyone?). From what I can tell, since all I have in the wiki are .jpg's and .png's, all images should have the following set:

• img_width: width of image in pixels, given by identify -format %w filename
• img_height: height of image in pixels, given by identify -format %w filename
• img_bits: 8 image depth, given by identify -format %z filename (correct ?)
• img_media_type: BITMAP
• img_major_mime: image
• img_minor_mime: jpeg (for .jpg files), png (for .png files)

Can anyone verify this?

At any rate, I also posted a message in my forum that includes the script I used to upgrade my site, and once I have the image script nailed down that I'm using to bypass the rebuildImages.php script, I'll probably post it there, too. Obviously, you'll have to probably tweak and customize it for your own site, but it worked for me, and I figured I would share it for purely informational purposes. I am not a developer, and getting to this point took me a lot of times, so I'm not sure I'll be much help answering questions, but I wanted to add my 2¢'s worth in case someone finds it useful.

--Tony V 10:07, 27 February 2006 (UTC)

Okay, I have an update of the non-SQL kind. For the last hour or two, I've been poking through the rebuildImages.php file trying to figure out why it's crashing on my host. It's crashing on this line:

$ret = mysql_query( $sql, $this->mConn );

in the file includes/Database.php, at line 349. I snagged the value of $sql just before the command runs, and if I plug it into my mysql client and run it manually, it runs fine. (That is, there's nothing wrong with the SQL syntax that is being run, and it looks like a normal command.) A sample SQL statement being executed is as follows:

/* ImageBuilder::buildTable */ UPDATE `wiki_image` SET img_width = '32',img_height = '32',img_bits = '8',img_media_type = 'BITMAP',img_major_mime = 'image',img_minor_mime = 'png' WHERE img_name = 'RadiationBurst_CosmicBurst.png'

I don't know why the function is failing, but it might be worth noting that the query is actually working. I can't imagine a problem with the mysql_query function, because isn't that pretty much the same function that is used elsewhere to, well, generate every page in the wiki? (Which, incidentally, is working fine...)

Here's a blow-by-blow of what's happening. When I run php rebuildImages.php, it loads the first image and runs that query and hangs on it, but after the query has updated the table. I stop it (Ctrl-C), and run php rebuildImages.php again, and it skips the first image and hangs on the second, again, after the query has updated the table. As long as I keep typing php rebuildImages.php, it will keep updaing one row and hanging. If I put something to output text to the console just before and just after that line, what is programmed to output before gets written, but not what is programmed to be output after.

Any ideas? --Tony V 13:51, 27 February 2006 (UTC)

How do you run script?

How do you run the upgrade1_5.php script on Mac OS X? i.e. what command do I need to type in the Terminal? Thanks.

Rebuilding thumbnails

I recently upgraded from 1.4.10 to 1.6.6, via 1.5. However, my thumbnails are not being found, because they aren't in the proper directory. Is there an easy way to regenerate all of the image thumbnails?

Migration from TWiki

Anyone have any ideas on doing a semi-automated migration from TWiki to MediaWiki? I'm mostly concerned with preserving table formats (we have a lot of them) and attachments. Thanks in advance!

Upgrade from 1.4.14-1ubuntu1 to 1.9.3

Hi,

I installed the 1.4.14-1ubuntu1 package in Ubuntu. Then I decided to use another machine. I installed there MediaWiki version 1.9.3. Is it possible to export the data from the previous instalation to the new instalation?

The problem is that I do mysqldump, and then restore the database in the new machine. At first, it seems to be fine. At least I have the users created in the first wiki. Also recent changes works. But then all the content of the pages created before is gone. And also when I click on "edit" or "discussion", the page cannot be displayed (HTTP 500 - Internal Server Error), so I cannot edit further pages if I restore the database from the old MediaWiki. Does anyone know how to proceed to recover all the data? Thanks

Is your MySQL database in InnoDB or MyIsam format? The MySQL dump for InnoDB works fine if you just specify "Complete Backup" under Backup / Advanced options. The MySQL dump for MyISAM works only if you specify "Complete Backup" and "Lock all tables". If forgot this the first time, and encountered the same problem you have.

upgraded 1.5 to 1.12 painlessly

Thanks to ALL of the Wikimedia community for such a great piece of software. I upgraded my outdated 1.5 installation of MediaWiki, and it was easy as pie. I just followed the directions on this page, and the script did the rest. I had to look up how to change the wiki logo again, but that was my fault for forgetting which files to pull out of the backup and overwrite into the new version's directory.

Specific problem with upgrading on Go Daddy

My wiki is hosted by Go Daddy, and, as has been mentioned, they don't support shell logins. I got around this by installing PHP Shell. The real problem is with extracting the upgrade archive: the .tar contains an extra level in the path that needs to be discarded. Normally, this is done by passing the '--strip-components=1' or '--strip-path=1' option to tar, but Go Daddy uses an old version of tar that doesn't support either. It seems that there's no way to extract the original upgrade archive into my existing MediaWiki subdirectory, which is what the developers intended.

Unless someone knows of an equivalent to --strip-components or --strip-path on tar 1.13.25, I'm not sure of the correct course of action here. Maybe it's time for Go Daddy to upgrade their tar package.