Hi all,
I am trying to upgrade an old mediawiki installation (version 1.5.8) to the latest version, following the upgrade instructions here:
http://www.mediawiki.org/wiki/Manual:Upgrading_to_1.14
I backed up the database and files from the old installation and unpacked the new version over the top of my existing installation using the following command:
tar xvfz mediawiki-1.14.0.tar.gz -C /path/to/my/wiki/ --strip-components=1
I then updated AdminSettings.php to be my root mysql user, changed to the maintenance directory and ran:
php update.php --aconf ../AdminSettings.php
This gave me the following output:
# php update.php --aconf ../AdminSettings.php
MediaWiki 1.14.0 Updater
Going to run database updates for ccbi_micklem Depending on the size of your database this may take a while! Abort with control-c in the next five seconds...0 ...have ipb_id field in ipblocks table. ...have ipb_expiry field in ipblocks table. ...already have interwiki table ...indexes seem up to 20031107 standards ...hitcounter table already exists. ...have rc_type field in recentchanges table. ...have user_real_name field in user table. ...querycache table already exists. ...objectcache table already exists. ...categorylinks table already exists. Already have pagelinks; skipping old links table updates. ...have rc_ip field in recentchanges table. ...image primary key already set. ...have rc_id field in recentchanges table. ...have rc_patrolled field in recentchanges table. ...logging table already exists. ...have user_token field in user table. The watchlist table is already set up for email notification. ...watchlist talk page rows already present ...user table does not contain old email authentication field. ...page table already exists. ...have log_params field in logging table. logging table has correct log_title encoding. ...archive table does not exist, skipping new field patch ...have page_len field in page table. revision timestamp indexes already up to 2005-03-13 ...rev_text_id already in place. ...have rev_deleted field in revision table. ...have img_width field in image table. ...have img_metadata field in image table. ...have user_email_token field in user table. ...archive table does not exist, skipping new field patch ...page_namespace is already a full int (int(11)). A database query syntax error has occurred. The last attempted database query was: "SHOW COLUMNS FROM `archive` LIKE 'ar_namespace'" from within function "". MySQL returned error "1146: Table 'mywiki.archive' doesn't exist (localhost)".
When I then browse to the wiki I get the following error:
from within function "Job::pop". MySQL returned error "1146: Table 'mywiki.job' doesn't exist (localhost)".
Having failed on this tack, I wiped everything and restored from backup to attempt "Alternative 2". The web installed gave the following output:
Checking environment...
/Please include all of the lines below when reporting installation problems./
* PHP 5.2.5 installed * Found database drivers for: MySQL * PHP server API is apache2handler; ok, using pretty URLs (index.php/Page_Title) * Have XML / Latin1-UTF-8 conversion support. * Session save path (/var/lib/php/session) appears to be valid. * PHP's memory_limit is 128M. * eAccelerator http://eaccelerator.sourceforge.net/ installed * Found GNU diff3: /usr/bin/diff3. * Found ImageMagick: /usr/bin/convert; image thumbnailing will be enabled if you enable uploads. * Found GD graphics library built-in. * Installation directory: /var/www/WIKI * Script URI path: /wiki * Installing MediaWiki with php file extensions * Environment checked. You can install MediaWiki. *
*Generating configuration file...*
* Database type: MySQL * Loading class: DatabaseMysql * Attempting to connect to database server as ccbi_wiki...success. * Connected to mysql 5.0.27; enabling MySQL 4.1/5.0 charset mode * Database mywiki exists * There are already MediaWiki tables in this database. Checking if updates are needed... * *Warning:* you requested the mysql5-binary schema, but the existing database has the mysql4 schema. This upgrade script can't convert it, so it will remain mysql4. * *Warning:* you requested the InnoDB storage engine, but the existing database uses the MyISAM engine. This upgrade script can't convert it, so it will remain MyISAM.
...have ipb_id field in ipblocks table. ...have ipb_expiry field in ipblocks table. ...already have interwiki table ...indexes seem up to 20031107 standards ...hitcounter table already exists. ...have rc_type field in recentchanges table. ...have user_real_name field in user table. ...querycache table already exists. ...objectcache table already exists. ...categorylinks table already exists. Already have pagelinks; skipping old links table updates. ...have rc_ip field in recentchanges table. ...image primary key already set. ...have rc_id field in recentchanges table. ...have rc_patrolled field in recentchanges table. ...logging table already exists. ...have user_token field in user table. The watchlist table is already set up for email notification. ...watchlist talk page rows already present ...user table does not contain old email authentication field. ...page table already exists. ...have log_params field in logging table. logging table has correct log_title encoding. ...archive table does not exist, skipping new field patch ...have page_len field in page table. revision timestamp indexes already up to 2005-03-13 ...rev_text_id already in place. ...have rev_deleted field in revision table. ...have img_width field in image table. ...have img_metadata field in image table. ...have user_email_token field in user table. ...archive table does not exist, skipping new field patch ...page_namespace is already a full int (int(11)).
This script does not seem to have finished and there was no LocalSettings.php created. When I moved the LocalSettings.old.php to LocalSettings.php and browse to the wiki I get the following error:
from within function "Job::pop". MySQL returned error "1146: Table 'mywiki.job' doesn't exist (localhost)".
So thats it, I'm currently stuck at version 1.5.8 :(
Does anyone have any idea how I can get past this and upgrade to the latest version? Please do not hesitate to ask if you need more information to debug this.
Many thanks in advance, Dan T.
Hi Dan,
It's probably a good idea to go through intermediate version for the upgrade. For example, 1.5 -> 1.7 -> 1.9 -> 1.11 -> 1.13. You may be able to make bigger jumps, but going two versions up should always be safe.
There is an archive of older releases here: http://download.wikimedia.org/mediawiki/
Regards,
Leons Petrazickis http://lpetr.org/blog/
On Fri, May 1, 2009 at 11:34, Dan Tomlinson dan@flymine.org wrote:
Hi all,
I am trying to upgrade an old mediawiki installation (version 1.5.8) to the latest version, following the upgrade instructions here:
http://www.mediawiki.org/wiki/Manual:Upgrading_to_1.14
I backed up the database and files from the old installation and unpacked the new version over the top of my existing installation using the following command:
tar xvfz mediawiki-1.14.0.tar.gz -C /path/to/my/wiki/ --strip-components=1
I then updated AdminSettings.php to be my root mysql user, changed to the maintenance directory and ran:
php update.php --aconf ../AdminSettings.php
This gave me the following output:
# php update.php --aconf ../AdminSettings.php
MediaWiki 1.14.0 Updater
Going to run database updates for ccbi_micklem Depending on the size of your database this may take a while! Abort with control-c in the next five seconds...0 ...have ipb_id field in ipblocks table. ...have ipb_expiry field in ipblocks table. ...already have interwiki table ...indexes seem up to 20031107 standards ...hitcounter table already exists. ...have rc_type field in recentchanges table. ...have user_real_name field in user table. ...querycache table already exists. ...objectcache table already exists. ...categorylinks table already exists. Already have pagelinks; skipping old links table updates. ...have rc_ip field in recentchanges table. ...image primary key already set. ...have rc_id field in recentchanges table. ...have rc_patrolled field in recentchanges table. ...logging table already exists. ...have user_token field in user table. The watchlist table is already set up for email notification. ...watchlist talk page rows already present ...user table does not contain old email authentication field. ...page table already exists. ...have log_params field in logging table. logging table has correct log_title encoding. ...archive table does not exist, skipping new field patch ...have page_len field in page table. revision timestamp indexes already up to 2005-03-13 ...rev_text_id already in place. ...have rev_deleted field in revision table. ...have img_width field in image table. ...have img_metadata field in image table. ...have user_email_token field in user table. ...archive table does not exist, skipping new field patch ...page_namespace is already a full int (int(11)). A database query syntax error has occurred. The last attempted database query was: "SHOW COLUMNS FROM `archive` LIKE 'ar_namespace'" from within function "". MySQL returned error "1146: Table 'mywiki.archive' doesn't exist (localhost)".
When I then browse to the wiki I get the following error:
from within function "Job::pop". MySQL returned error "1146: Table 'mywiki.job' doesn't exist (localhost)".
Having failed on this tack, I wiped everything and restored from backup to attempt "Alternative 2". The web installed gave the following output:
Checking environment...
/Please include all of the lines below when reporting installation problems./
* PHP 5.2.5 installed * Found database drivers for: MySQL * PHP server API is apache2handler; ok, using pretty URLs (index.php/Page_Title) * Have XML / Latin1-UTF-8 conversion support. * Session save path (/var/lib/php/session) appears to be valid. * PHP's memory_limit is 128M. * eAccelerator http://eaccelerator.sourceforge.net/ installed * Found GNU diff3: /usr/bin/diff3. * Found ImageMagick: /usr/bin/convert; image thumbnailing will be enabled if you enable uploads. * Found GD graphics library built-in. * Installation directory: /var/www/WIKI * Script URI path: /wiki * Installing MediaWiki with php file extensions * Environment checked. You can install MediaWiki. *
*Generating configuration file...*
* Database type: MySQL * Loading class: DatabaseMysql * Attempting to connect to database server as ccbi_wiki...success. * Connected to mysql 5.0.27; enabling MySQL 4.1/5.0 charset mode * Database mywiki exists * There are already MediaWiki tables in this database. Checking if updates are needed... * *Warning:* you requested the mysql5-binary schema, but the existing database has the mysql4 schema. This upgrade script can't convert it, so it will remain mysql4. * *Warning:* you requested the InnoDB storage engine, but the existing database uses the MyISAM engine. This upgrade script can't convert it, so it will remain MyISAM.
...have ipb_id field in ipblocks table. ...have ipb_expiry field in ipblocks table. ...already have interwiki table ...indexes seem up to 20031107 standards ...hitcounter table already exists. ...have rc_type field in recentchanges table. ...have user_real_name field in user table. ...querycache table already exists. ...objectcache table already exists. ...categorylinks table already exists. Already have pagelinks; skipping old links table updates. ...have rc_ip field in recentchanges table. ...image primary key already set. ...have rc_id field in recentchanges table. ...have rc_patrolled field in recentchanges table. ...logging table already exists. ...have user_token field in user table. The watchlist table is already set up for email notification. ...watchlist talk page rows already present ...user table does not contain old email authentication field. ...page table already exists. ...have log_params field in logging table. logging table has correct log_title encoding. ...archive table does not exist, skipping new field patch ...have page_len field in page table. revision timestamp indexes already up to 2005-03-13 ...rev_text_id already in place. ...have rev_deleted field in revision table. ...have img_width field in image table. ...have img_metadata field in image table. ...have user_email_token field in user table. ...archive table does not exist, skipping new field patch ...page_namespace is already a full int (int(11)).
This script does not seem to have finished and there was no LocalSettings.php created. When I moved the LocalSettings.old.php to LocalSettings.php and browse to the wiki I get the following error:
from within function "Job::pop". MySQL returned error "1146: Table 'mywiki.job' doesn't exist (localhost)".
So thats it, I'm currently stuck at version 1.5.8 :(
Does anyone have any idea how I can get past this and upgrade to the latest version? Please do not hesitate to ask if you need more information to debug this.
Many thanks in advance, Dan T.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
El 5/1/09 12:41 PM, Leons Petrazickis escribió:
It's probably a good idea to go through intermediate version for the upgrade. For example, 1.5 -> 1.7 -> 1.9 -> 1.11 -> 1.13. You may be able to make bigger jumps, but going two versions up should always be safe.
You should never need to do this -- upgrading directly from any previous MediaWiki version to the latest is the recommended process and should always work unless something's broken.
I just did a quick test upgrading a fresh 1.5 branch installation to 1.14 branch, and the update went flawlessly.
[snip]
The last attempted database query was: "SHOW COLUMNS FROM `archive` LIKE 'ar_namespace'" from within function "". MySQL returned error "1146: Table 'mywiki.archive' doesn't exist (localhost)".
When I then browse to the wiki I get the following error:
from within function "Job::pop". MySQL returned error "1146: Table 'mywiki.job' doesn't exist (localhost)".
These seem to indicate something's wrong with your wiki database -- some of your tables are missing. The 'archive' table was already there in our 1.1 release, and should certainly be present in any working 1.5 installation.
The 'job' table was added in 1.6, but the updater hasn't reached the stage of adding it yet at the time it's checking the archive table's indexes and fails.
-- brion
On Fri, May 1, 2009 at 2:01 PM, Brion Vibber brion@wikimedia.org wrote:
El 5/1/09 12:41 PM, Leons Petrazickis escribió:
It's probably a good idea to go through intermediate version for the upgrade. For example, 1.5 -> 1.7 -> 1.9 -> 1.11 -> 1.13. You may be able to make bigger jumps, but going two versions up should always be safe.
You should never need to do this -- upgrading directly from any previous MediaWiki version to the latest is the recommended process and should always work unless something's broken.
I just did a quick test upgrading a fresh 1.5 branch installation to 1.14 branch, and the update went flawlessly.
That may be true by 1.5, but I had a set of 1.3.x installations that I tested some upgrades with to the then-current level 2 years ago and it barfed and died repeatedly and consistently. I asked here and was told to do incremental one-step upgrades.
El 5/1/09 2:37 PM, George Herbert escribió:
On Fri, May 1, 2009 at 2:01 PM, Brion Vibberbrion@wikimedia.org wrote:
You should never need to do this -- upgrading directly from any previous MediaWiki version to the latest is the recommended process and should always work unless something's broken.
That may be true by 1.5, but I had a set of 1.3.x installations that I tested some upgrades with to the then-current level 2 years ago and it barfed and died repeatedly and consistently. I asked here and was told to do incremental one-step upgrades.
If you encounter such issues again, please let us know so we can make sure the updater is fixed...
Right now the main potential problems are with old non-Unicode installations (some languages pre-1.5) or weirdly funkified MySQL charset issues (especially if the experimental charset options got picked on the older install). And I'd love to get those fixed to work reliably too -- the software should be able to detect and sort those conditions out more easily than the user can!
-- brion
Dan Tomlinson wrote:
...have user_email_token field in user table. ...archive table does not exist, skipping new field patch ...page_namespace is already a full int (int(11)). A database query syntax error has occurred. The last attempted database query was: "SHOW COLUMNS FROM `archive` LIKE 'ar_namespace'" from within function "". MySQL returned error "1146: Table 'mywiki.archive' doesn't exist (localhost)".
This does look broken: it's detecting that the archive table doesn't exist and skipping a check, only to blindly attempt to access it two lines later.
Presumably the updater should be fixed to create the archive table if it's missing, unless we have some valid reason to support setups without an archive table(?!?).
El 5/1/09 1:57 PM, Ilmari Karonen escribió:
This does look broken: it's detecting that the archive table doesn't exist and skipping a check, only to blindly attempt to access it two lines later.
Presumably the updater should be fixed to create the archive table if it's missing, unless we have some valid reason to support setups without an archive table(?!?).
The archive table already existed in our first release, so there's no update step to add it.
If it's the only thing missing, then cut-n-pasting the table definition out of tables.sql and manually adding it may resolve the issue.
-- brion
Brion Vibber wrote:
El 5/1/09 1:57 PM, Ilmari Karonen escribió:
This does look broken: it's detecting that the archive table doesn't exist and skipping a check, only to blindly attempt to access it two lines later.
Presumably the updater should be fixed to create the archive table if it's missing, unless we have some valid reason to support setups without an archive table(?!?).
The archive table already existed in our first release, so there's no update step to add it.
If it's the only thing missing, then cut-n-pasting the table definition out of tables.sql and manually adding it may resolve the issue.
-- brion
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi Brion,
thanks for that! I ran the archive section of tables.sql on the database and then ran update.php - it worked flawlessly :)
I'm not sure how I ended up without that table, but my predecessor did have a tendency to hack things to pieces (and not bother to document what he had done).
Thanks for the quick response!
Dan
Dan Tomlinson wrote:
Brion Vibber wrote:
El 5/1/09 1:57 PM, Ilmari Karonen escribió:
This does look broken: it's detecting that the archive table doesn't exist and skipping a check, only to blindly attempt to access it two lines later.
Presumably the updater should be fixed to create the archive table if it's missing, unless we have some valid reason to support setups without an archive table(?!?).
The archive table already existed in our first release, so there's no update step to add it.
If it's the only thing missing, then cut-n-pasting the table definition out of tables.sql and manually adding it may resolve the issue.
-- brion
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi Brion,
thanks for that! I ran the archive section of tables.sql on the database and then ran update.php - it worked flawlessly :)
I'm not sure how I ended up without that table, but my predecessor did have a tendency to hack things to pieces (and not bother to document what he had done).
Thanks for the quick response!
Dan
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi all,
I spoke to soon it seems. The wiki is now up and running with the new database structure under 1.14.0 but I have noticed a problem with user accounts and specifically capitalisation.
Our wiki uses HTML basic auth (hooked into the university web authentication system) so people's university usernames are automatically passed through into mediawiki.
The problem is, even though the code we used to override AuthPlugin is the same as the one we used in the previous version, something weird has happened which means that our usernames (previously all lowercase) are now no-longer valid. Mediawiki seems to always capitalise the first letter of each username which means that I can't access user pages.
For example, the link:
http://www.myserver.ac.uk/mediawiki/index.php/User:yjl24
... automatically becomes:
http://www.ccbi.cam.ac.uk/micklemlab/index.php/User:Yjl24
... when I try to access it and I am informed that "There is currently no text in this page.".
I realise that this is probably a feature of the newer version of mediawiki rather than a bug as such, but I would like to disable this feature to allow me to have all lower case usernames in line with our uni web auth system.
I would be very happy if someone could point me in the right direction so I have a solution and am able to make our user pages accessible again. I'm happy to include any and all relevant source code if necessary.
Thanks in advance, Dan T.
2009/5/6 Dan Tomlinson dan@flymine.org:
For example, the link:
http://www.myserver.ac.uk/mediawiki/index.php/User:yjl24
... automatically becomes:
Set $wgCapitalLinks = false; in LocalSettings.php
Roan Kattouw (Catrope)
Roan Kattouw wrote:
2009/5/6 Dan Tomlinson dan@flymine.org:
For example, the link:
http://www.myserver.ac.uk/mediawiki/index.php/User:yjl24
... automatically becomes:
Set $wgCapitalLinks = false; in LocalSettings.php
Roan Kattouw (Catrope)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Excellent - many thanks :)
Dan
El 5/6/09 11:06 PM, Roan Kattouw escribió:
2009/5/6 Dan Tomlinsondan@flymine.org:
For example, the link:
http://www.myserver.ac.uk/mediawiki/index.php/User:yjl24
... automatically becomes:
Set $wgCapitalLinks = false; in LocalSettings.php
Usernames are still required to be capitalized when $wgCapitalLinks is off. Currently there's no clean way to force acceptance of lowercase names; you'll need to hack User::getCanonicalName() to remove these lines:
# Force usernames to capital global $wgContLang; $name = $wgContLang->ucfirst( $name );
-- brion
wikitech-l@lists.wikimedia.org