Move ResourceLoader classes to their own namespace. Strip the
"ResourceLoader" prefix from all except ResourceLoader itself.
Move the tests by analogy.
I used a namespace alias "RL" in some callers since RL\Module is less
ambiguous at the call site than just "Module".
I did not address DependencyStore which continues to have a non-standard
location and namespace.
Revert of a241d83e0a.
Bug: T308718
Change-Id: Id08a220e1d6085e2b33f3f6c9d0e3935a4204659
This reverts commit e08ea8ccb9.
Reason for revert: Breaks Phan in extensions, and as far as I’m aware,
this change isn’t urgently needed for anything, so the simplest fix is
to revert it again for now. After PHP 7.4 it should be safer to try this
again (we hopefully won’t need the two “hack” classes by then).
Bug: T308443
Change-Id: Iff3318cbf97a67f821f78e60da62a583f63e389e
Move ResourceLoader classes to their own namespace. Strip the
"ResourceLoader" prefix from all except ResourceLoader and
ResourceLoaderContext.
Move the tests by analogy.
I used a namespace alias "RL" in some callers since RL\Module is less
ambiguous at the call site than just "Module".
I did not address DependencyStore which continues to have a non-standard
location and namespace.
Change-Id: I92998ae6a82e0b935c13e02a183e7c324fa410a3
The new class, UrlUtils, is usable standalone or as a service. Using it
as a service will just automatically load a few settings from site
configuration.
In addition to just making our code cleaner, this will enable making
some of Setup.php's dynamic configuration more sane.
Test coverage is all lines except invalid URLs -- I couldn't find any.
Bug: T305093
Change-Id: I706ef8a50aafb518e13222719575d274c3583b90
We need a way to actually just detect the deprecation override,
without instantly emitting the deprecation warning. Providing
'false' to the method as a $version parameter seems like a logical
thing to use for it.
Change-Id: I7733846613f37a4ba168e944bc671b43264aa498
This introduces a utility method in MWDebug, and uses it to clean up
the deprecation mechanism for Skin::setupSkinUserCss().
Bug: T257990
Bug: T267080
Change-Id: I5b07fa82dcc2b0fd112f122e45c9b2562cd09247
Add div wrapper to MWDebug::getHTMLDebugLog() to allow users to fully
style the whole block, in addition to the id to style the list items.
It's moved to MWDebug to ensure its present in all skins instead of
using duplication for both Mustache-based and SkinTemplate-based Skins.
The wrapper is only added when $wgShowDebug is true, that's when the
function returns non-empty string
Bug: T259075
Change-Id: I0c387573bdd8ab72e4b2338b802df8b7881036da
* Always use trigger_error for deprecation warnings, not just in development.
They are still silent from the run-time perspective (not thrown as
exceptions).
Previously this code path was only called when $wgDevelopmentWarnings
is set to true. For most dev environments and for CI, this means
nothing much changes given that DevelopmentSettings.php set this to true.
* In the code path that handles native PHP warnings, when setting the $file
and $line attribution that Logstash/Kibana report as "exception.file"
use the same offset as the one that wfDeprecated() has computed from
the back trace. This means it no longer (wrongly/uselessly) attributes
all deprecation warnings to MWDebug.php.
* Trim the message suffix from "Called from <method> in <file>" to
just "Called from <method>". This reduces noise and makes the message
more stable over multiple MW branches. The stack trace is still there
like before.
== Before (only with $wgDevelopmentWarnings) ==
> PHP Deprecated: Use of wfGetScriptUrl was deprecated in MediaWiki 1.35.
> [Called from MediaWiki::__construct in /var/mediawiki/includes/MediaWiki.php at line 67]
>
> Error from line 393 of /var/mediawiki/includes/debug/MWDebug.php
>
> #0 [internal function]: MWExceptionHandler::handleError()
> #1 /var/mediawiki/includes/debug/MWDebug.php(393): trigger_error()
> #2 /var/mediawiki/includes/debug/MWDebug.php(297): MWDebug::sendMessage()
> #3 /var/mediawiki/includes/debug/MWDebug.php(270): MWDebug::sendRawDeprecated()
> #4 /var/mediawiki/includes/GlobalFunctions.php(1032): MWDebug::deprecated()
> #5 /var/mediawiki/includes/GlobalFunctions.php(2548): wfDeprecated()
> #6 /var/mediawiki/includes/MediaWiki.php(67): wfGetScriptUrl(string)
> #7 /var/mediawiki/load.php(50): MediaWiki->__construct()
== After (always) ==
> Use of wfGetScriptUrl was deprecated in MediaWiki 1.35. [Called from MediaWiki::__construct]
>
> Error from line 67 of /var/mediawiki/includes/MediaWiki.php
>
> #0 [internal function]: MWExceptionHandler::handleError()
> #1 /var/mediawiki/includes/debug/MWDebug.php(293): trigger_error()
> #2 /var/mediawiki/includes/debug/MWDebug.php(270): MWDebug::sendRawDeprecated()
> #3 /var/mediawiki/includes/GlobalFunctions.php(1038): MWDebug::deprecated()
> #4 /var/mediawiki/includes/GlobalFunctions.php(2548): wfDeprecated()
> #5 /var/mediawiki/includes/MediaWiki.php(67): wfGetScriptUrl(string)
> #6 /var/mediawiki/load.php(50): MediaWiki->__construct()
Bug: T252923
Change-Id: I1d4a166b6dff8b0e19fce3fab409f4a89e734ee6
Follows-up d459add63d (Ib3dd2fe37677).
'MediaWiki' component is now specified earlier,
check for that also instead of false.
Bug: T256353
Change-Id: I54645dc16da92d3b5f3ccaad988ad5c0b0573ddd
Deprecating something means to say something nasty about it, or to draw
its character into question. For example, "this function is lazy and good
for nothing". Deprecatory remarks by a developer are generally taken as a
warning that violence will soon be done against the function in question.
Other developers are thus warned to avoid associating with the deprecated
function.
However, since wfDeprecated() was introduced, it has become obvious that
the targets of deprecation are not limited to functions. Developers can
deprecate literally anything: a parameter, a return value, a file
format, Mondays, the concept of being, etc. wfDeprecated() requires
every deprecatory statement to begin with "use of", leading to some
awkward sentences. For example, one might say: "Use of your mouth to
cough without it being covered by your arm is deprecated since 2020."
So, introduce wfDeprecatedMsg(), which allows deprecation messages to be
specified in plain text, with the caller description being optionally
appended. Migrate incorrect or gramatically awkward uses of wfDeprecated()
to wfDeprecatedMsg().
Change-Id: Ib3dd2fe37677d98425d0f3692db5c9e988943ae8
Follow up to I0d0df86db2e61cdd1769426bfa7bad4c2ae5e977 to fix the
command-line parserTests runner.
Change-Id: If4a979f0f1377302c89d921c24e7ee0673fa3a26
* Split MWDebug::sendRawDeprecated() from MWDebug::deprecated(). The new
function can be used to send arbitrary messages to the deprecation
log, rather than being constrained by the fixed format of
MWDebug::deprecated().
* Split formatCallerDescription() from sendMessage() to allow the caller
of sendRawDeprecated() to do its own caller formatting.
* Use the new function in MWLBFactory::logDeprecation()
* In tests, replace the ugly implementation of hideDeprecated() with one
that works by setting a list of regexes to filter. hideDeprecated()
now filters deprecation warnings that are a string match to the
supplied function. filterDeprecated() can be used to filter a regex,
and is intended to be used to filter warnings sent via
sendRawDeprecated(). The filter list is reset at the start of each
test, instead of leaking across tests as before.
Change-Id: I0d0df86db2e61cdd1769426bfa7bad4c2ae5e977
Send deprecation messages to $wgDebugLogFile if it is configured.
Previously deprecation messages were marked as "private" and so were
shown only if someone specifically configured the channel in
$wgDebugLogGroups.
Complete suppression of deprecation messages was an accident stemming
from an attempt to avoid duplication of those messages when
$wgDebugToolbar is enabled. However, that duplication is harmless and
perhaps even useful -- we see an HTML deprecation message in the
console, and also a plain text deprecation message in its context in the
toolbar's debug log, which seems fine to me.
Change-Id: I8edb41aa1d8236047b80830dcdda546e326b09ec
This is to make it behave in a more object orientied way. The
goal is to make it be easier to allow extensions to mark certain
pages as requiring a different policy (For example, CodeEditor
extension uses a blob: url with a WebWorker. We don't want to
include that on the policy of every page, but allow the extension
to mark it as required whenever needed).
This commit does not change code behaviour in any way.
Change-Id: I4bf53dabb6e6c5446cea99a64db68b300cef2fd4
This broke after e0cc49ce39, due to the field 'master'
being removed from the log context. The LegacyLogger logic
forwarding these messages to MWDebug (for the debug toolbar)
however, was dependant on.
Users of debug toolbar experienced a silent failure because the
logic in question is very tolerant of missing fields. This is
because it uses those fields to distinguish the 'sql' messages
from channel=DBQuery from other messages in the same channel.
Making that less fragile is outside the scope of this commit.
This commit:
* Restore the basic functionality by making sure MWDebug::query()
gets called again for DBQuery messages.
* Remove the code relating to the 'master' field as this no longer
exists in RDBMS. It also wasn't used anywhere (to be used,
it would need to be read by mediawiki.debug/debug.js).
* Remove unexpanded "{method}" and "{runtime}" noise in the debug
toolbar text. This was introduced by he conversion to PSR-3
logging.. These fields are already rendered separately by
the toolbar and should not be part of the "SQL" column.
To do this, we need to log the $sql bit as its own key, so
I've made this a context field as well.
* Reduce the condition logic in LegacyLogger to only looking for
'DBQuery' and 'sql'. This way, if it breaks again it will
still call the logic within and emit E_NOTICE instead, which
would help detect the issue (and still fallback to at least
showing the queries). Unlike before this commit where it took
quite some time to figure out why it wasn't working.
* The above fixes still weren't enough to get queries to show
up in the Debug toolbar for me. Turns out, this was because
my local setup (mediawiki-docker-dev) uses a master-replica
set up. The setup doesn't use any custom LBFactory config,
just plain $wgDBservers. The logic for turning these plain
settings into LBFactory (in MWLBFactory.php) does kick in,
and does run (unlike if I had custom wgLBFactoryConf).
But, the DBO_DEBUG flag didn't make it through because of
the += operator preferring any pre-existing value my setup
has, which is just `DBO_DEFAULT`.
Merging 'flags' keys seems unsafe in general, but adding
DBO_DEBUG based on $wgDebugDumpSql seems innocent and doesn't
affect other behaviour (it's a case of DWIM).
Bug: T231742
Change-Id: I122bb1a65620a7ae4e1943136c975b63524a5111
This will allow us to remove the phan stubs. The MWDebug part was copied
from Ia92b881a7eeab4b8b53531136fb0dbafb6ec30ba.
Change-Id: Id8a5e267b2eb2d8beda3b1b2c1041000a0a1b17c
* Remove checks in HTMLFileCache.php and Article.php.
These haven't been needed since the same check was added to Setup.php,
many years ago. When FileCache is enabled, The Setup.php code disables
MWDebug. There is no reason for FileCache to then also disable itself
based on unused config. That means both of them lose.
We now handle this logic in one place: MWDebug::setup().
* In rebuildFileCache.php, turn it off explicitly, just in case.
The previous code there didn't work because finalSetup()
is called after doMaintenance.php includes Setup.php, which
is what checked this config var to decide on MWDebug::init.
On the other hand, it's also always off in CLI mode.
But, let's not depend on that, maybe we decide to enable it on
CLI one day! Just keep it off explicitly here.
Bug: T189966
Change-Id: I45a8f77092249751dc6f276aa5bb67ebf5b4f64c
Follows-up 81e8d7af41 and e861191b2c.
When using $wgShowDebug, $wgDebugComments, or $wgDebugLogFile
locally, or when using the 'log' attribute with X-Wikimedia-Debug,
all channels should be enabled and logged. But, the DBQuery logs
are currently going nowhere.
The code for MWDebug::query() is intercepting it, even if
$wgDebugToolbar is not enabled.
And after that, the code for wfLogDBError was intercepting it,
again, even if $wgDBerrorLog is not enabled.
Bug: T202764
Change-Id: I710c26a9e9c30fea20975d1bc24e1f0af077c2ad
The primary goal here is a defense in depth measure to
stop an attacker who found a bug in the parser allowing
them to insert malicious attributes.
This wouldn't stop someone who could insert a full
script tag (since at current it can't distinguish between
malicious and legit user js). It also would not prevent
DOM-based or reflected XSS for anons, as the nonce value
is guessable for anons when receiving a response cached
by varnish. However, the limited protection of just stopping
stored XSS where the attacker only has control of attributes,
is still a big win in my opinion. (But it wouldn't prevent
someone who has that type of xss from abusing things like
data-ooui attribute).
This will likely break many gadgets. Its expected that any
sort of rollout on Wikimedia will be done very slowly, with
lots of testing and the report-only option to begin with.
This is behind feature flags that are off by default, so
merging this patch should not cause any change in default
behaviour.
This may break some extensions (The most obvious one
is charinsert (See fe648d41005), but will probably need
some testing in report-only mode to see if anything else breaks)
This uses the unsafe-eval option of CSP, in order to
support RL's local storage thingy. For better security,
we may want to remove some of the sillier uses of eval
(e.g. jquery.ui.datepicker.js).
For more info, see spec: https://www.w3.org/TR/CSP2/
Additionally see:
https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy
Bug: T135963
Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
* Use $_SERVER['REQUEST_TIME_FLOAT'] unconditionally in WebRequest.php
and libs/Timing.php. WebStart.php was doing this already without issue.
The key existst since PHP 5.4, for both Web and CLI (we require 5.5).
* In wfDebug() and wfReportTime(), use $_SERVER['REQUEST_TIME_FLOAT'] instead.
* In ApiFormatBase and MWDebug, use WebRequest::getElapsedTime() instead.
* In Maintenance.php, remove setting of $wgRequestTime.
* In rebuildFileCache.php, update mocking to $_SERVER['REQUEST_TIME_FLOAT']
so that we avoid re-introducing bug T24852.
Change-Id: I1b647da2862f815029caa533b592ec8a05b33806
And auto-fix all errors.
The `<exclude-pattern>` stanzas are now included in the default ruleset
and don't need to be repeated.
Change-Id: I928af549dc88ac2c6cb82058f64c7c7f3111598a
I was bored. What? Don't look at me that way.
I mostly targetted mixed tabs and spaces, but others were not spared.
Note that some of the whitespace changes are inside HTML output,
extended regexps or SQL snippets.
Change-Id: Ie206cc946459f6befcfc2d520e35ad3ea3c0f1e0
The short SHA1 is already shown with the MediaWiki version, and
displaying the full SHA1 again adds 40+ more characters. Mostly this
annoys me as it causes the toolbar to wrap earlier when making my
browser window smaller.
Change-Id: If7474a090466de708d65cef6dcc30a36df56621f
MWDebug::init() is currently irreversible -- once MWDebug is enabled, it cannot
be disabled in that execution context. This means that the MWDebug test suite
(which enables MWDebug) has a nasty side-effect -- all the tests that run after
it run with MWDebug enabled. So add an MWDebug::deinit(), and call it on test
teardown.
Ostensibly this is a great use-case for services and dependency injection. The
reason I am not going that route is that it's not entirely clear to me what the
MWDebug class is supposed to represent. If I were going to spend any
substantial amount of time on this, I would be trying to move it out of core
and into an extension, not converting it into a service.
Change-Id: I52c511be049bc276d203d07283e3aa0944f22d34
The functionality for marking a debug log message for delivery to a log
file but not to MWDebug was removed in 1.25 with the introduction of
the PSR-3 logging system. Convert the messages that were marked for this
special handling in a7a0883 to use 'private' instead.
Bug: T122644
Change-Id: Iefaac07a5922c16c2899904c7b678199c5b1efe9
ApiResult was a mess: some methods could only be used with an array
reference instead of manipulating the stored data, methods that had both
array-ref and internal-data versions had names that didn't at all
correspond, some methods that worked on an array reference were
annoyingly non-static, and then the whole mess with setIndexedTagName.
ApiFormatXml is also entirely annoying to deal with, as it liked to
throw exceptions if certain metadata wasn't provided that no other
formatter required. Its legacy also means we have this silly convention
of using empty-string rather than boolean true, annoying restrictions on
keys (leading to things that should be hashes being arrays of key-value
object instead), '*' used as a key all over the place, and so on.
So, changes here:
* ApiResult is no longer an ApiBase or a ContextSource.
* Wherever sensible, ApiResult provides a static method working on an
arrayref and a non-static method working on internal data.
* Metadata is now always added to ApiResult's internal data structure.
Formatters are responsible for stripping it if necessary. "raw mode"
is deprecated.
* New metadata to replace the '*' key, solve the array() => '[]' vs '{}'
question, and so on.
* New class for formatting warnings and errors using i18n messages, and
support for multiple errors and a more machine-readable format for
warnings. For the moment, though, the actual output will not be changing
yet (see T47843 for future plans).
* New formatversion parameter for format=json and format=php, to select
between BC mode and the modern output.
* In BC mode, booleans will be converted to empty-string presence style;
modules currently returning booleans will need to use
ApiResult::META_BC_BOOLS to preserve their current output.
Actual changes to the API modules' output (e.g. actually returning
booleans for the new formatversion) beyond the use of
ApiResult::setContentValue() are left for a future change.
Bug: T76728
Bug: T57371
Bug: T33629
Change-Id: I7b37295e8862b188d1f3b0cd07f66ac34629678f
The patch did not improve performance. I'd like to think that the increased
control over when inline scripts are executed makes the patch worthwhile
regardless, but that is post hoc justification and possibly a bit of personal
ego. Krinkle agrees that we may use some of the ideas in this patch in the
future but he thinks we're better off not heading down this path before we
have a better sense of where we're going, and I trust his judgment.
This reverts commit e86e5f8460.
Change-Id: I151f74a41dd664b5a0aa5cfd99fcc95e2686a1e6
This drops support for the custom utf8 normal PHP extension in favor
of the intl extension.
Bug: T90825
Change-Id: Ifbaeb2ef684217cf6187ccc4fb4d303f89608300
The current ordering of scripts and stylesheets in <head> causes all major
browsers to serialize and defer requests that could be performed in parallel.
The problem is that external stylesheets are loaded before inline scripts. As
Steven Souders explains, "all major browsers preserve the order of CSS and
JavaScript. The stylesheet has to be fully downloaded, parsed, and applied
before the inline script is executed. And the inline script must be executed
before the remaining resources can be downloaded. Therefore, resources that
follow a stylesheet and inline script are blocked from downloading."[1]
In other words: the browser could start loading body images, but it refuses to
do that until it has executed inline scripts in head. And it refuses to execute
those scripts until the external CSS is downloaded, parsed and applied. You can
see the effect of this in this image, showing the request waterfall for
[[en:Gothic Alphabet]]: [2]. Notice how no images were requested before the
browser had finished processing the three load.php requests at the top.
To fix this, we want to move the inline scripts above the external CSS. This is
a little bit tricky, because the inline scripts depend on mw.loader, which is
loaded via an external script. If we move the external script so that it too is
above the external stylesheet, we force the browser to serialize requests,
because the browser will not retrieve the external CSS until it has retrieved
and executed the external JS code. So what we want is to move the inline
scripts above the external stylesheet, but keep the external script (which the
inline scripts depend on) below the external stylesheet.
We can do this by wrapping the inline script code in a closure (which binds
'mw') and enqueuing the closure in a global array which will be processed by
the startup module at just the right time.
Net result: external CSS and JS is retrieved in parallel, retrieval of images
(and other external assets) is unblocked, but the order in which code is
evaluated remains the same.
[1]: <http://www.stevesouders.com/blog/2009/05/06/positioning-inline-scripts/>
[2]: <http://people.wikimedia.org/~ori/enwiki-waterfall.png> (excerpted from
<http://www.webpagetest.org/result/150316_0C_7MB/1/details/>.
Change-Id: I98d383a6299ffbd10210431544a505338ca8643f
