I've added a quick maintenance/update.php which runs the updaters from the command line, as a first step along this path.

cody.foss wrote:

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.

robchur wrote:

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)".

ayg wrote:

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.