* The serialized message cache, which would have been redundant, has been removed. Similar performance characteristics can be achieved with $wgLocalisationCacheConf['manualRecache'] = true;
* Added a maintenance script rebuildLocalisationCache.php for offline rebuilding of the localisation cache.
* Extension i18n files can now contain any of the variables which can be set in Messages*.php. It is possible, and recommended, to use this feature instead of the hooks for special page aliases and magic words.
* $wgExtensionAliasesFiles, LanguageGetMagic and LanguageGetSpecialPageAliases are retained for backwards compatibility. $wgMessageCache->addMessages() and related functions have been removed. wfLoadExtensionMessages() is a no-op and can continue to be called for b/c.
* Introduced $wgCacheDirectory as a default location for the various local caches that have accumulated. Suggested $IP/cache as a good place for it in the default LocalSettings.php and created this directory with a deny-all .htaccess.
* Patched Exception.php to avoid using the message cache when an exception is thrown from within LocalisationCache, since this tends to fail horribly.
* Removed Language::getLocalisationArray(), Language::loadLocalisation(), Language::load()
* Fixed FileDependency::__sleep()
* In Cdb.php, fixed newlines in debug messages
In MessageCache::get():
* Replaced calls to $wgContLang capitalisation functions with plain PHP functions, reducing the typical case from 99us to 93us. Message cache keys are already documented as being restricted to ASCII.
* Implemented a more efficient way to filter out bogus language codes, reducing the "foo/en" case from 430us to 101us
* Optimised wfRunHooks() in the typical do-nothing case, from ~30us to ~3us. This reduced MessageCache::get() typical case time from 93us to 38us.
* Removed hook MessageNotInMwNs to save an extra 3us per cache hit. Reimplemented the only user (LocalisationUpdate) using the new hook LocalisationCacheRecache.
As Tim notes, the weird callback setup in $wgHooks isn't really something we want to replicate or ever rely on ever again, as PHP's native callback syntax already handles things fine and is more consistent (and used extensively in the rest of MediaWiki).
May be other remaining issues with the refactor on top of bugs already discovered, but if it's going to be refactored to use callbacks it should be done using regular callbacks.
A database query syntax error has occurred.
The last attempted database query was:
"SELECT gu_id, lu_wiki, gu_salt, gu_password,gu_auth_token, gu_locked,gu_hidden,gu_registration,gu_email,gu_email_authenticated FROM `parsertest_globaluser` LEFT OUTER JOIN `parsertest_localuser` ON gu_name=lu_name AND lu_wiki='test2wiki-parsertest_' WHERE gu_name='127.0.0.1'"
from within function "Database::safeQuery".
MySQL returned error "1146: Table 'centralauth.parsertest_globaluser' doesn't exist (127.0.0.1)"
* Whitespaces fixes
Breaks existing hooks including core language converters:
Notice: Undefined variable: event in /Library/WebServer/Documents/trunk/includes/Hooks.php on line 61
Warning: call_user_func_array(): First argument is expected to be a valid callback, 'ZhConverter::on' was given in /Library/WebServer/Documents/trunk/includes/Hooks.php on line 119
Notice: Undefined variable: args in /Library/WebServer/Documents/trunk/includes/Hooks.php on line 80
Notice: Undefined variable: event in /Library/WebServer/Documents/trunk/includes/Hooks.php on line 61
Detected bug in an extension! Hook ZhConverter::on failed to return a value; should return true to continue hook processing or false to abort.
Backtrace:
#0 /Library/WebServer/Documents/trunk/includes/Article.php(1684): wfRunHooks('ArticleSaveComp...', Array)
#1 /Library/WebServer/Documents/trunk/includes/Article.php(1354): Article->doEdit('Article for spe...', '', 97)
#2 /Library/WebServer/Documents/trunk/maintenance/parserTests.inc(998): Article->insertNewArticle('Article for spe...', '', false, false)
#3 /Library/WebServer/Documents/trunk/maintenance/parserTests.inc(307): ParserTest->addArticle('Xyzzyx', 'Article for spe...', 5168)
#4 /Library/WebServer/Documents/trunk/maintenance/parserTests.inc(273): ParserTest->runFile('/Library/WebSer...')
#5 /Library/WebServer/Documents/trunk/maintenance/parserTests.php(73): ParserTest->runTestsFromFiles(Array)
#6 {main}
Doxygen documentation update:
* Changed alls @addtogroup to @ingroup. @addtogroup adds the comment to the group description, but doesn't add the file, class, function, ... to the group like @ingroup does. See for example http://svn.wikimedia.org/doc/group__SpecialPage.html where it's impossible to see related files, classes, ... that should belong to that group.
* Added @file to file description, it seems that it should be explicitely decalred for file descriptions, otherwise doxygen will think that the comment document the first class, variabled, function, ... that is in that file.
* Removed some empty comments
* Removed some ?>
Added following groups:
* ExternalStorage
* JobQueue
* MaintenanceLanguage
One more thing: there are still a lot of warnings when generating the doc.
* PHP 5.3 compatibility fix for wfRunHooks() called with no parameters
An autoloaded 'Namespace' class alias is retained for compatibility with
extensions which haven't updated to the new class name... however they too
will break on PHP 5.3. Yay!
Previously, this function used variable arguments to allow
different hooks to pass different parameters. However, var args
silently convert reference-calling to value-calling. So a call
that used to work like this:
# old
wfRunHooks('SomeEvent', $param1, &$param2, $param3);
...now works like this:
# new
wfRunHooks('SomeEvent', array($param1, &$param2, $param3));
Hook functions can now change pass-by-reference parameters correctly
(e.g. $param2 in the above example).
All calls to wfRunHooks() were changed and tested, and the change
was documented in docs/hooks.doc. This change was originally checked
in on REL1_4 branch as a bugfix, but per vibber reverted and checked
in to HEAD instead.
(syslog). Although intended to be useful, it's more of a testbed for
event hooks than anything else. For a first pass, started logging user
login and user logout events. Had to add hooks-running code to the
login and logout modules, but that's kind of the point. Documented the
three events added in hooks.doc.
instead of -- MediaWiki code for particular events (article rollback,
user ban, etc.). Framework is in place; hooks are not yet in place
in the mainline code.
