Last modified: 2010-10-25 23:19:48 UTC
The upgrade procedure is currently a bit of a pain. Making it more transparent would be a help: * Should be able to use info from an existing LocalSettings.php. * Should be able to run without exposing the site to malicious or accidental poking at the configuration script from outsiders. * Should produce helpful messages to visitors trying to get at the wiki itself during the trip.
I've added a quick maintenance/update.php which runs the updaters from the command line, as a first step along this path.
I would recommend something similar to WordPress. Upload new files, run upgrade script from the browser. Ask the user for some sort of key if your concerned about security.
What more, arguably, could we do about this? We have a fairly robust upgrade script, and users who can't use it are able to run the installer again; they seem to have few problems doing this. We have rather good upgrade documentation since the 1.6 branch, see http://www.mediawiki.org/wiki/Manual:Upgrading_to_1.6 et al. and most of the problems associated with the jump from 1.3/1.4 to 1.5 are now gone, since those upgrades were done long ago.
The upgrade procedure when no command-line is available is kind of crappy: you have to remove the configuration file, then run the web installer again. There's two big issues with this, to my mind: 1) It leaves a period during the upgrade where other people visiting your site could get into the installer form and start typing away. Unless you secure it more effectively with HTTP-level authentication this could be open to abuse or trouble 2) The update scripts get run on a fresh default configuration instead of the user's existing LocalSettings.php. This could lead to incorrect treatment of custom namespaces at the least, and maybe other problems.
I'm one person at least who's trying to upgrade from 1.4.9 and wow, it is difficult. I wouldn't think everyone who started a wiki is always jumping to install every new version. It is especially frustrating with the charset issue... One simple thing that could be done for those in the know-how is to double-check the instructions on the Upgrade's Help page. I believe there are errors there (e.g., the parameters to pass to the mysql command) and confusion (just to show how to run something on the command line). I don't mean to be complaining, for as was pointed out in an earlier conversation on the same subject, this stuff has been provided freely by you guys, but understand it really is a nightmare for someone who knows enough to enter a few SQL passwords but who doesn't know enough to perform charset conversions (using tools that aren't even explained where they come from) and so on! Thanks!
Hi, After trying to work through with it on my own, I discovered a few things that could at least get the update1_5.php and update.php files from the commandline to complete without errors. 1) As I was doing testing on a Windows machine (but for a LocalSettings.php file from a Linux machine), I found I had to change the ":" separator in LocalSettings.php to a semicolon. Although changing the colons to just $sep works ok with the updating, it doesn't work on a live site since $sep isn't declared on a live site. 2) Due to what seems to be changes in MySQL 5.? (see http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html ), I ran the mysql command line "set global sql_mode = 'NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'" after discovering that STRICT_TRANS_TABLES was interfering with the script (something about 'blob/text' not having defaults, as I recall). 3) In FiveUpgrade.inc, I needed to take this line so that I wouldn't get a double "maintenance/archives" in the URL and thus an error: dbsource( 'maintenance/archives/patch-interwiki-trans.sql', $this->dbw ); ... and replace it with this line: dbsource( archive('patch-interwiki-trans.sql'), $this->dbw ); Now the database does include new UTF-8 tables, but I still have the following tables with Latin1 data (I really thought the script was going to convert my old data to UTF-8 but it said that these tables already existed and seemed to do nothing with them): brokenlinks, cur, interwiki, objectcache, searchindex, text. There are also these tables with Latin1 but with no data: math, blobs, user_newtalk. While I can also now access my wiki site, it seems that when trying to view a page on the wiki that contains any non-ASCII Latin1 characters (I presume they are Latin1 and not Unicode since "cur" still shows in phpMyAdmin as being Latin1), the page will be blank (besides the title which will show non-ASCII characters without problem). If I click to edit such a page that is blank, the code is available, but the Latin1 characters show up as "?"'s. I've really been trying to go by the book here and do it on my own, but if someone has any ideas about how to fix things (even if I have to do this all over--I've made backups), I'd really, really, really appreciate it... I also very much do want the whole site to be in UTF-8... (Using "iconv" on a dump didn't seem to change the Latin1 collations spelled out in the dump either). I am submitting this issue here, by the way, because the mediawiki.org site is blocked here in China, and you guys also are blocking the proxies that I can use...I'm also hoping you might take pity on someone who really is trying to hack my way through it... thanks a lot (and my appreciation for making this available to the community at all), Brett
Oh, if there is no other way, do you know if it would be a safe (and comprehensive) solution to use PHP and its utf8_encode functions to make a script to retrieve the existing values and after converting them, upload them to an equivalent UTF-8 table? I don't mind doing that, but I don't know if that would make things worse or not be enough to solve the problem...
Sorry to bother you again, but I should just clarify for anyone else reading this, my step in telling MySQL to forget about the default value issue might be leading to this error now when I try to edit a new page: The last attempted database query was: (SQL query hidden) from within function "Revision::insertOn". MySQL returned error "1364: Field 'old_comment' doesn't have a default value (localhost)".
Old schemas aren't compatible with MySQL 5 strict mode. Disable strict mode, or maybe use a more recent schema (I think the 1.9 standard one is supposed to be MySQL 5 strict-compatible).
Yes, I know, that's why I disabled it originally (when I ran the update scripts in order to avoid the blob/text error I referred to earlier). But my latter point was that I got an error message which sounds like it was giving me an error because I did disable strict mode. As far as using a more recent schema, I thought that that's what the update1_5.php/update.php scripts were supposed to do for me--update my old version to the new schema! Thanks, Brett
*** Bug 9063 has been marked as a duplicate of this bug. ***
Solved by r75392.
