Wikimedia Bugzilla is closed!

Did you get any more error information, such as a backtrace? If not, please follow the instructions at bug 19447 comment #26 to generate one. I think this error is caused by an extension loading messages while the l10ncache table hasn't been created yet.

Of course, rather than fixing every extension in existence, the proper fix is to disable l10ncache at the start of update.php .

Sorry, we did not get any further error messages. We cannot do the requested reprogramming of mediawiki in comment 26 to backtrace errors.

(In reply to comment #2)
> Sorry, we did not get any further error messages. We cannot do the requested
> reprogramming of mediawiki in comment 26 to backtrace errors.
> 

Why not?

Can you check whether r55761 (the fix for bug 20464, which looks related) fixes this?

Verified the bug to be still existing with r55766, the fix for bug 20464 does not fix this error.

Updated to revision 55766.

#php ./maintenance/update.php  --quick --conf ./LocalSettings.php

A database error has occurred
Query: SELECT  lc_value  FROM `l10n_cache`  WHERE lc_lang = 'en' AND lc_key = 'deps'  LIMIT 1
Function: LCStore_DB::get
Error: 1146 Table 'testwiki.l10n_cache' doesn't exist

Adding $wgDebugLogFile = "$IP/debug_log"; to localsettings does not produce any information in the log file.

Here is the additional info after modifying the code:

Backtrace:
#0 /usr/share/mediawikistaging/phase3/includes/db/Database.php(533): DatabaseBase->reportQueryError('Table 'testwiki...', 1146, 'SELECT  lc_valu...', 'LCStore_DB::get', false)
#1 /usr/share/mediawikistaging/phase3/includes/db/Database.php(869): DatabaseBase->query('SELECT  lc_valu...', 'LCStore_DB::get')
#2 /usr/share/mediawikistaging/phase3/includes/db/Database.php(949): DatabaseBase->select('l10n_cache', Array, Array, 'LCStore_DB::get', Array, Array)
#3 /usr/share/mediawikistaging/phase3/includes/LocalisationCache.php(737): DatabaseBase->selectRow('l10n_cache', Array, Array, 'LCStore_DB::get')
#4 /usr/share/mediawikistaging/phase3/includes/LocalisationCache.php(299): LCStore_DB->get('en', 'deps')
#5 /usr/share/mediawikistaging/phase3/includes/LocalisationCache.php(324): LocalisationCache->isExpired('en')
#6 /usr/share/mediawikistaging/phase3/includes/LocalisationCache.php(242): LocalisationCache->initLanguage('en')
#7 /usr/share/mediawikistaging/phase3/includes/LocalisationCache.php(205): LocalisationCache->loadItem('en', 'namespaceNames')
#8 /usr/share/mediawikistaging/phase3/languages/Language.php(241): LocalisationCache->getItem('en', 'namespaceNames')
#9 /usr/share/mediawikistaging/phase3/languages/Language.php(289): Language->getNamespaces()
#10 /usr/share/mediawikistaging/phase3/includes/Title.php(562): Language->getNsText(10)
#11 /usr/share/mediawikistaging/phase3/includes/Title.php(2198): Title->getNsText()
#12 /usr/share/mediawikistaging/phase3/includes/Title.php(636): Title->prefix('Extension_DPL')
#13 /usr/share/mediawikistaging/phase3/includes/LinkCache.php(137): Title->getPrefixedDBkey()
#14 /usr/share/mediawikistaging/phase3/includes/Title.php(2088): LinkCache->addLinkObj(Object(Title))
#15 /usr/share/mediawikistaging/phase3/includes/Title.php(3424): Title->getArticleID()
#16 /usr/share/mediawikistaging/extensions/DynamicPageList/DPLSetup.php(1100): Title->exists()
#17 /usr/share/mediawikistaging/extensions/DynamicPageList/DPLSetup.php(1077): ExtDynamicPageList::commonSetup()
#18 [internal function]: ExtDynamicPageList::setupDPL()
#19 /usr/share/mediawikistaging/phase3/includes/Setup.php(339): call_user_func(Array)
#20 /usr/share/mediawikistaging/phase3/maintenance/commandLine.inc(259): require_once('/usr/share/medi...')
#21 /usr/share/mediawikistaging/phase3/maintenance/update.php(14): require_once('/usr/share/medi...')
#22 {main}

Disabling DynamicPageList leads to:
...
#17 /usr/share/mediawikistaging/extensions/MathStatFunctions/MathStatFunctions.php(431): Parser->setFunctionHook('const', Array)
#18 [internal function]: wfSetupMathStatFunctions()
...

Disabling MathStatFunctions:

Seems to work! Updated to newest version. 

Suggestions: instead of having to modify the original code to get a backtrace, perhaps could reportQueryError or related write a backtrace to the log file as well? This would make it easier for people like us to help finding such errors.

Rather strangely, while it seemed to work above, after reverting the "backtrace changes" in includes/db/Database.php and enabling extensions again, it again does not work, the error was the same. So there may be yet more extensions that prevent updating mediawiki. We have reverted to rev. 52502 again.

I'll see if I can do something about the failure mode.

Should be fixed in r55798. Please test by running update.php with all extensions enabled.

Tested with rev 55803: Well done, all fixed! Thank you!

I just upgraded from 1.9.2 to 1.16.4 and still have the bug. php update.php seems OK  but running the home page displays :

A database error has occurred
Query: SELECT lc_value FROM `mw1_l10n_cache` WHERE lc_lang = 'en' AND lc_key = 'deps' LIMIT 1
Function: LCStore_DB::get
Error: 1146 Table 'thierryb.mw1_l10n_cache' doesn't exist (localhost)

deactivating all extensions  does not make any difference.
---------------------------------------------------------------
MediaWiki 1.9.2 Updater

Going to run database updates for thierryb-mw1_
Depending on the size of your database this may take a while!
Abort with control-c in the next five seconds...0
...hitcounter table already exists.
...querycache table already exists.
...objectcache table already exists.
...categorylinks table already exists.
...logging table already exists.
...user_newtalk table already exists.
...transcache table already exists.
...trackbacks table already exists.
...externallinks table already exists.
...job table already exists.
...langlinks table already exists.
...querycache_info table already exists.
...filearchive table already exists.
...querycachetwo table already exists.
...have ipb_id field in ipblocks table.
...have ipb_expiry field in ipblocks table.
...have rc_type field in recentchanges table.
...have rc_ip field in recentchanges table.
...have rc_id field in recentchanges table.
...have rc_patrolled field in recentchanges table.
...have rc_old_len field in recentchanges table.
...have user_real_name field in user table.
...have user_token field in user table.
...have user_email_token field in user table.
...have user_registration field in user table.
...have log_params field in logging table.
...have ar_rev_id field in archive table.
...have ar_text_id field in archive table.
...have page_len field in page table.
...have rev_deleted field in revision table.
...have img_width field in image table.
...have img_metadata field in image table.
...have img_media_type field in image table.
...have ss_total_pages field in site_stats table.
...have iw_trans field in interwiki table.
...have ipb_range_start field in ipblocks table.
...have ss_images field in site_stats table.
...have ipb_anon_only field in ipblocks table.
...have ipb_enable_autoblock field in ipblocks table.
...have user_newpass_time field in user table.
...have user_editcount field in user table.
...already have interwiki table
...indexes seem up to 20031107 standards
Already have pagelinks; skipping old links table updates.
...image primary key already set.
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.
Logging table has correct title encoding.
...page table already exists.
revision timestamp indexes already up to 2005-03-13
...rev_text_id already in place.
...page_namespace is already a full int (int(11)).
...ar_namespace is already a full int (int(11)).
...rc_namespace is already a full int (int(11)).
...wl_namespace is already a full int (int(11)).
...qc_namespace is already a full int (int(11)).
...log_namespace is already a full int (int(11)).
...already have pagelinks table.
...templatelinks table already exists
No img_type field in image table; Good.
Already have unique user_name index.
...user_groups table already exists.
...user_groups is in current format.
...wl_notificationtimestamp is already nullable.
...timestamp key on logging already exists.
Setting page_random to a random value on rows where it equals 0...changed 0 rows
Checking for additional recent changes indices...
...index on ( rc_namespace, rc_user_text ) seems to be ok
...index on ( rc_user_text, rc_timestamp ) seems to be ok
...redirect table already exists.
Checking for backlinking indices...
Checking if pagelinks index pl_namespace includes field pl_from...
...index pl_namespace on table pagelinks seems to be ok
Checking if templatelinks index tl_namespace includes field tl_from...
...index tl_namespace on table templatelinks seems to be ok
Checking if imagelinks index il_to includes field il_from...
...index il_to on table imagelinks seems to be ok
Deleting old default messages...Done
Purging caches...done.
Done.

You need to run update.php on the *new* version (1.16.4), not the old one.

This is what I did! I deleted all files in ~/www/pdtwiki except /images /extensions localSettings.php AdminSettings.php then extracted new files, then ran:
$ sudo /opt/lampp/bin/php maintenance/update.php

By the way if I compare tables list from a fresh install and those after upgrading, it misses some tables:

- category, change_tag, external_user, l10n_cache, log_search, page_props, page_restrictions, protected_titles, tag_summary, updatelog, user_properties, valid_tag.

(In reply to comment #12)
> This is what I did! I deleted all files in ~/www/pdtwiki except /images
> /extensions localSettings.php AdminSettings.php then extracted new files, then
> ran:
> $ sudo /opt/lampp/bin/php maintenance/update.php
> 

You must've done *something* wrong, because it says:
(In reply to comment #10)
> MediaWiki 1.9.2 Updater
>

Can you tell me where is defined {$wgVersion} to track what is going wrong?

Well found. I must be dumb! :

MediaWiki 1.16.4 Updater

Going to run database updates for thierryb-mw1_
....
Done.