This was done automatically by replacing every assertContains with
string *needle*. Then verifying the results.
Bug: T192167
Change-Id: Id8cbbf3b01e948f80046714183cc299f86be21fd
Inspired by wikiHow's RobotPolicy extension, which depends on the existence of OutputPage#getRobotPolicy, as the extension needs to know the current robot policy state.
Change-Id: I764f5584a9f04a6b66c53193e9118dd1a5248284
Before making improvements to OutputPage::sendCacheControl() the test coverage
should be increased.
Bug: T236862
Change-Id: I4a76b0894e2d574688e1cbd30f32ee7504801082
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
Languages with variants no longer can override the parent's constructor
(which is now used for injecting services). Instead, they need to
override Language::newConverter().
Bug: T201405
Change-Id: I923400d61763cf1db88cb0c3f684c9c10e58032d
Add public, protected or private to function missing a visibility
Enable the tests folder for the phpcs sniff
Change-Id: Ibefce76ea9984c47e08c94889ea2eafca7565e2c
… to make my PHPStorm IDE complain less about unknown types. The moment
the tests go green this should proof itself, because there is no other
code that depends on this test than the test itself. ;-)
Note the removed options array was broken. The comparison checked the
*values*, not the keys.
Change-Id: I1929cd694808d5b924933fc7033c05eaceda7e34
assertSame() is guaranteed to not do any type conversion. This can be
critical when acciden tially comparing, for example, 0 to 0.0.
Change-Id: Iffcc9bda69573623ba14af655dcd697d0fcce525
In a nut shell:
* We very often (52% of modules on enwiki) pad the hash with a zero,
which means the amount of bits we currently compute already fit in
6 characters already for most modules. For some modules (3%) we
even padded two zeroes.
* For the (now documented) use cases, the space of 78 Giga
(78 billion, or 78 milliard) seems more than we need. The space of
60 million should be enough.
This follows-up dfd046412f from 2016, which previously shortened the hash
down from 8 chars of base 64 (or 12 chars of hex) to 7 chars of base 32.
Before that change, the space was 281 Tera (64^8, or 16^12).
For more details see the added inline comment for ResourceLoader::makeHash,
and also the data at <https://phabricator.wikimedia.org/T229245>.
Bug: T229245
Change-Id: I9ad11772a33b3a44cb625275b1d7353e1393ee49
Skin shouldn't be responsible for providing requested revisionId
nor if that revision is the current revision.
The OutputPage object has all required information (both the
currentRevisionID and the current Title object).
Change-Id: I2dbae4c6968a2b3b3cea3e09977e9579609b4cc5
In mediawiki.js, this marker has always been optional, falling back to
appending to <head>. When no stylesheets need to be after the marker
(e.g. no site styles on the wiki, and user is not logged-in), then
there is no need for the marker to exist.
In a previous refactor, I was going to do this and created an
"$append" variable in the function to do what this commit does,
but I forgot to actually use it for anything.
Test Plan:
* Local wiki, with no MediaWiki:Common/{Skinname}.css pages existing.
* When logged-out, before this change, there is a marker, now there is not.
* When creating "MediaWiki:Group-user.css" and logging in, there is still
a marker, and it is still above the <link> for that user styles request
in the <head>.
Bug: T219342
Change-Id: I2e9657f318088860916823efeb96ae4f1532974c
Clean up a few more code paths and documentation bits left behind by
Ia53d07cd8ce8ab1497294ea244c13c7499f632c7.
Change-Id: I2bb1749c45bb79b27c5a3b2e1b8ed3395e8c11e0
These implemented a since-abandoned draft IETF spec, and the code was
broken due to (1) case-(in)sensitivity issues with the Accept-Language
header and (2) the BCP47 language code compatibility workaround we use.
Change-Id: Ia53d07cd8ce8ab1497294ea244c13c7499f632c7
This starts cleaning up the programmer-visible API for OutputPage
and removed some deprecated untidy parser modes.
Change-Id: Ib464b57248f114b68424ec1175d36ad86d1319ad
lang=qqx and skin=fallback are the default values.
This change removes the default values from the load request of the
html5shiv module.
Before this change
<script src="/w/load.php?lang=qqx&modules=html5shiv&only=scripts&skin=fallback&sync=1"></script>
With this change
<script src="/w/load.php?modules=html5shiv&only=scripts&sync=1"></script>
Change-Id: Ie384ce0f7ab1bd0b6c2d3f0ca4a990c3cf3a7f15
Use global variables directly as globals, except for the specific
case of accessing it when it may not exist. In those cases we
use the fact that undefined properties of an object yield the
`undefined` value which we can cast to false. Accessing an undefined
variable would yield a ReferenceError exception.
Change-Id: I1d9e9aa5845ba3c756ad6e31358d8594e003b04b
Wikis with $wgFeed=false should not present an Atom icon on the RecentChanges/Watchlist.
Bug: T116145
Change-Id: Ic64f7f5115a77c42ed2b336f6996fe711b3822ba
The addModuleScripts() methods were deprecated in 1.31 and 1.32,
these are now removed.
The getModuleScripts() are now deprecated as well, always returning
an empty array. To be removed in 1.34.
Depends on commits for bundled/wmf-deployed extensions that
remove the last few remaining callers to the deprecated functions
in: 3D, Collection, Flow, GlobalUserPage, and Wikibase.
Bug: T188689
Depends-On: If9f0bc6aef85117587fa1929f34f8861c8d80314
Depends-On: Ia8d41b97fbf6822f5f8f7ac889408acce1ac9a3a
Depends-On: I503b919739ea474ff33726815b0da55e2f7e2724
Depends-On: I236ef637fd03b810a46eb361e25067a037e9d183
Depends-On: I62e17779753b977a452cc0c9694947941e999cc3
Change-Id: I5a19b8f164ccf666485d2971202194b747f882df
The OutputPage::parse() and OutputPage::parseInline() methods behave
misleadingly different from the OutputPage::addWikitext*() methods:
they don't tidy their output, they have different defaults for
interface/content language selection, and they (sometimes) add
wrapper divs. Deprecate these and add new methods with tidy output,
clear language selection, and consistent defaults:
OutputPage::parseAsContent(), OutputPage::parseAsInterface(),
and OutputPage::parseInlineAsInterface().
Unify the implementation of the parse* methods with the addWikiText*
methods, to reduce the likelihood that the behavior will diverge again
in the future.
Bug: T198214
Change-Id: Ica79c2acbc542ef37f971c0be2582ae771a23bd0
We should probably strip the <div> wrapper in OutputPage::parse() as
well: this behavior was added in 1.30, but it only applies when
$interface is false. However, that requires a more careful audit
(a lot more places call parse() than parseInline()) and so I'll defer
that for now.
Change-Id: Iad5412f03af29c04deb653969dd71f6c86f0ae50
Tidy will always be enabled with our future parsers. Hard-deprecate
this method which doesn't tidy the output.
Users of `OutputPage::addWikiText()` will be converted one-by-one to
`OutputPage::addWikiTextAsInterface()` so that any unexpected issues
(deliberately untidy wikitext added, which should be rare) can be
addressed.
Bug: T198214
Depends-On: I778ba9e6efed576605f492c9a073c7203b6c0477
Depends-On: I16529879a3b3aed960c5dc006e2af513d7e91fcd
Change-Id: If8353c37245d9d233d589f82c198668ccb3fce05
This change ensures that the output is tidy, and is necessary to support
future parsers which will not be able to produce untidy output.
Bug: T198214
Change-Id: I743f4185a03403f8d9b9db010ff1ee4e9342e062
This patch introduces a new method,
OutputPage::wrapWikiTextAsInterface(), which wraps the result of
OutputPage::addWikiTextAsInterface() in a tidy and robust way that
won't break if the wrapped message contains double newlines, extra
</div>, or other nasties.
This replaces a common unsafe pattern:
$output->addWikiText( '<div class="..."' .... '</div>' );
Bug: T205624
Change-Id: I1040c7cf0ec1f5c4bef7c06d4486f50d85f2dc0f
We are incrementally removing places where the parser is used with
tidy disabled, since future parsers will not support such operation.
Bug: T198214
Change-Id: I0f417f75a49dfea873e9a2f44d81796a48b9f428
