Hoping someone can help me figure out why 1.19.1 update.php script is dying by what is coming next in the script
MediaWiki 1.19.1 Updater
Going to run database updates for mw_update Depending on the size of your database this may take a while! Abort with control-c in the next five seconds (skip this countdown with --quick) ... 0 ...ipblocks table does not exist, skipping new field patch. ...ipblocks table does not exist, skipping new field patch. Creating interwiki table...done. Adding default interwiki definitions...done. Set $wgShowExceptionDetails = true; in LocalSettings.php to show detailed debugging information.
Little stumped it dies without error, i think I should be looking for 99 total tables when the upgrade script finishes, but it is just creating 1 extra. Is the fact that ipblocks being hit twice the issue?
Apache/2.2.20 (Ubuntu) PHP Version 5.3.6-13ubuntu3.8 MySQL client version: 5.1.63 PHP extension: mysqli
The db is 30MB and the 16.5 version runs perfect on my localhost, not a hitch. Log in, edits, uploads. I tried running the rebuildall script before the update in 16.5 just to make sure the db was good. Since I have control of script time, I tried web based update, says it completes, but the db is showing only 1 page, main page default for a new installation even though the db now says it is 32MB, but a rebuildall only sees 1 page.
The dump from the 16.5 wiki was a MySql 4(don't even get me started) into my MySQL 5 db. Could that be the issue? MyISAM to InnoDB issue?
Thanks Tom
------------------------------------------------------------------------
On Fri, Jul 6, 2012 at 1:43 AM, Tom Hutchison tom@hutch4.us wrote:
Set $wgShowExceptionDetails = true; in LocalSettings.php to show detailed debugging information.
You should set $wgShowExceptionDetails to true.
...ipblocks table does not exist, skipping new field patch. ...ipblocks table does not exist, skipping new field patch. ...already have interwiki table Missing rc_timestamp field of recentchanges table. Should not happen. Backtrace: #0 [internal function]: MysqlUpdater->doIndexUpdate() #1 /home/mw-update/public_html/w/includes/installer/DatabaseUpdater.php(281): call_user_func_array(Array, Array) #2 /home/mw-update/public_html/w/includes/installer/DatabaseUpdater.php(244): DatabaseUpdater->runUpdates(Array, false) #3 /home/mw-update/public_html/w/maintenance/update.php(121): DatabaseUpdater->doUpdates(Array) #4 /home/mw-update/public_html/w/maintenance/doMaintenance.php(105): UpdateMediaWiki->execute() #5 /home/mw-update/public_html/w/maintenance/update.php(151): require_once('/home/mw-update/p...') #6 {main} $
Thanks Benjamin
The rc_timestamp field is missing, was that problem from the import of the database? How do I fix it?
Tom
------------------------------------------------------------------------ On 7/6/2012 3:24 AM, Benjamin Lees wrote:
On Fri, Jul 6, 2012 at 1:43 AM, Tom Hutchison <tom@hutch4.us mailto:tom@hutch4.us> wrote:
Set $wgShowExceptionDetails = true; in LocalSettings.php to show detailed debugging information.You should set $wgShowExceptionDetails to true.
I looked at the db and rc_timestamp is there and populated. Varbinary 14 char
Does that sound correct?
Tom
The updater isn't looking at the right database (or it's not looking at the right tables in it). Check $wgDBname and $wgDBprefix, Perhaps you have an AdminSettings.php file that's lying around with old values?
From: Benjamin Lees [mailto:emufarmers@gmail.com] Sent: Friday, July 06, 2012 2:14 PM To: MediaWiki announcements and site admin list; tom@hutch4.us Subject: Re: [MediaWiki-l] 16.5 to 19.1 install issue update.php adds only 1 table
The updater isn't looking at the right database (or it's not looking at the right tables in it). Check $wgDBname and $wgDBprefix, Perhaps you have an AdminSettings.php file that's lying around with old values?
_____
Thanks, I got it. IMO, the update.php should be checking for the drop table and if it doesn't exist, create it, which is what I thought it did. A MySQL export without the drop table, then an import fails because it is looking for the drop table, which isn't there. Devs? Is this correct? Once I exported with the drop table, imported, the update went off without a hitch. Almost.I should say, because a stumbled right into a known bug in table align="right" without a resolution yet in the sanitizer. Target fix is 1.20?
I opted for wikipedia's solution, $wgHtml5 = false to change the output back to XHTML 1.0 Transitional which fixed the table alignments on page's with tables. Yes, HTML5 is the newest and next, but with Mediawiki Devs on a, "Red Bull" induced release schedule what are all the wiki maintainers out there to do but cope as best we can. I certainly don't have the time to go and edit a couple hundred pages with align="right" set for the table.
Thanks
Tom
mediawiki-l@lists.wikimedia.org