Installing a custom error handler on every hook invocation has a high overhead,
and does not even correctly achieves what it sets out to achieve, which is to
flag hook function signature errors (and only hook function signature errors).
The "PHP way" is to simply increase the error reporting level for development
environments, which we do already.
Bug: T117553
Change-Id: Iba0138a6d0a0ddf839bc5a36e03cadb012e06f3c
Previously, it would send all manor of warnings to the error
and error-json channels. This adds a lot of overhead due to
AbuseFilter parse/eval errors. By passing immediately instead
of after calling handleError(), that overhead is avoided. Since
it still passes (e.g. returns false), any default PHP warning
logging still applies.
Change-Id: I18e60c09c2a48f2e26abab5d451bb52ea4ba7961
Split fatal error handling out of MWExceptionHandler::handleError() and
move to MWExceptionHandler::handleFatalError() which has been updated to
work as a dual purpose error handler and shutdown function. Under HHVM
it will be called as an error handler and receive a stacktrace via an
undocumented extension of the error handler callback data. Under PHP5 it
will be called as a shutdown handler and attempt to gather data via
error_get_last().
Also update the error handler installed by Hooks::run() to delegate to
MWExceptionHandler::handleError() for most errors. This will allow us to
properly handle errors raised from within hooks.
Bug: T89169
Change-Id: I0f1c66f203b91fff9069520169ecc4a3b55c43d0
Re-adds I6f807adc9cbf71c5d7b83c7eec43965dce1d2a16 and
Ic04daf475b936b942833362c7a979dde671b3ef4 (reverted in
35ccd9c2fe) with 1:1000 sampling
to avoid swamping the statsd hosts.
Also fixes query module logging.
Bug: T102079
Bug: T106450
Change-Id: I8b9366407c0d1713790d08e69aaa518130f01977
Reverts I6f807adc9cbf71c5d7b83c7eec43965dce1d2a16 and
Ic04daf475b936b942833362c7a979dde671b3ef4
When this hit group1 wikis statsite went nuts with errors like:
* "Failed value conversion! Input: :moduleManager:1"
* "Failed value conversion! Input: :getMessagesFileName:1"
* "Failed value conversion! Input: :get:1"
Change-Id: If0237cdd0d66634d75b2bab8bc4292c0f3ef75ef
We previously had counts for hooks and modules as a side-effect of having them
profiled. We removed the profiling for performance reasons, which left us
without counts also. But the performance of counters is not a concern, and
their signal value not insubstantial. So introduce them here.
Fix getModulePath() to not crash while we're at it.
Change-Id: Ic04daf475b936b942833362c7a979dde671b3ef4
* Also made scopedProfileOut handle the case where the callback
was null (e.g. when there are no frame methods for xhprof).
Change-Id: Ife242bda8e046990d0d8ac27d628975b7b4a14d7
When a hook function is not callable an exception is thrown.
This patch adds the name of the offensive hook function to
the exception message to improve its informative value.
Change-Id: I376d7f5590099620a4c11ff9a4967d6d8f6560cc
- Swap "$variable type" to "type $variable"
- Added missing types
- Fixed spacing inside docs
- Makes beginning of @param/@return/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: I783e4dbfe5f6f98b32b9a03ccf6439e13e132bcc
Most hook handlers are written with the intent of complementing or augmenting
core functionality rather than vetoing it, making it quite natural for a
developer to forget that the caller is waiting for permission to proceed. The
potential for confusion is magnified by the fact that DOM event handlers and
jQuery event handlers are not required to return an explicit value for the
handled event to continue propagating.
This change tolerates null return values (both implicit and explicit -- that
is, both 'return null' and no return statement at all) from hook handlers. To
abort processing, a hook function must return an explicit false or an error
string.
This change should not break any existing hook functions, as returning null is
currently an error.
Bug: 50134
Change-Id: I11deb2117ff9233c77868470f50e0d8f74053545
Essentially rewrote Hooks::run() to get rid of the ridiculous
four levels of indentation. Also made some slight adjustments
to fix rare edge cases (for example, moved set_error_handler
after wfProfileIn in case Profiler triggers an error).
Change-Id: Iafdd4ceedac067b49ac597359ac456f4617da9e8
* Removed spaces around array index
* Removed double spaces or added spaces to begin or end of function
calls, method signature, conditions or foreachs
* Added braces to one-line ifs
* Changed multi line conditions to one line conditions
* Realigned some arrays
Change-Id: Ia04d2a99d663b07101013c2d53b3b2e872fd9cc3
Doxygen expects parameter types to come before the
parameter name in @param tags. Used a quick regex
to switch everything around where possible. This
only fixes cases where a primitve variable (or a
primitive followed by other types) is the variable
type. Other cases will need to be fixed manually.
Change-Id: Ic59fd20856eb0489d70f3469a56ebce0efb3db13
Added/removed spaces around logical/arithmetic operator
Reduced multiple empty lines to one empty line
Removed wrong tabs before comments at end of line
Removed too many spaces in assigments
Change-Id: I2bba4e72f9b5f88c53324d7b70e6042f1aad8f6b
Until now, Hooks::run() would execute hooks registered via $wgHooks, but
Hooks:isRegistered() would not consider them and Hooks::getHandlers() would
not return them. That is inconsistent and misleading. This change aims to
make the methods of the Hooks class behave consistently, and allows them
to be used as a generic way of interacting with hooks.
Change-Id: I39bd5de2bc8ccbe8df729446363960af9d29b0be
* 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.
