This is the fourth patch of a series of patches to remove
ParserOutput::getText() calls from core. This series of patches should
be functionally equivalent to I2b4bcddb234f10fd8592570cb0496adf3271328e.
Here we replace calls to getText where a ContentRenderer is available
close by by temporary ParserOutput::runOutputPipeline that will
eventually be replaced by a call to (probably) ContentRenderer
(T371004). Doing this work in stages allows us to separate the work of
"bring ParserOptions to the call site" from the work of "bringing
ContentRenderer(ish) to the call site", since both need to be done for
to make ParserOutput a value object (T293512).
Change-Id: Ib4f9357293dc230df6e0ca2379a1e2a4cc1b91b7
Bug: T293512
This is the third patch of a series of patches to remove
ParserOutput::getText() calls from core. This series of patches should
be functionally equivalent to I2b4bcddb234f10fd8592570cb0496adf3271328e.
Here we temporarily introduce runOutputPipeline in ParserOutput. It
creates and runs the pipeline with default options, and is called by
getText. (This is not entirely truthful because we go through a
runPipelineInternal transient method for null-argument-passing reasons,
but let's not over-complicate this commit message.)
getText is responsible for maintaining the current behaviour,
that is "disallow the cloning of the ParserOutput and putting text back
to as it was" to mitigate T353257. As we get rid of getText, this
behaviour should be moved, if necessary, to the caller site.
The new method is currently added to ParserOutput so that further
refactorings are, for the moment, simpler. It will eventually be moved
to another place within the Content framework.
We also rename 'suppressClone' to 'allowClone' (which is actually its
negation) to avoid multiple levels of negations that make the code
confusing. Note that the default value of 'allowClone' is true, and is
currently overriden in two places: getText and
OutputPage::getParserOutputText (which calls the pipeline directly and
not through ParserOutput).
Bug: T293512
Bug: T371022
Change-Id: Ibf04af1079aaa1934dc78685b00e636ff4d38a9a
Add doc-typehints to class properties found by the PropertyDocumentation
sniff to improve the documentation.
Once the sniff is enabled it avoids that new code is missing type
declarations. This is focused on documentation and does not change code.
Change-Id: Id75cb2e5fbee0fe7600f92473d876f23730d46b7
This allows to change the category link rendering by extension
CategoryTree without missing update of mCategoryData and mCategories
which leads to wgCategories = [] (T372155).
The new hook will be used in extension CategoryTree by
Ic86f210474cbc0e2dcebf664cf2309a4a4408f60.
Bug: T372155
Change-Id: Id82a77a57d1f12233d974ea4c1b093f50c5ab74f
Some wikis treat the category list from ParserOutput as a /set/, others
as an /ordered list/. For those who don't care about the order of
categories, provide the option for wikis to sort the categories
in OutputPage.
This can also be activated with a query parameter, `&sortcat=1`, which
is useful to the Parsoid team when doing visual diff testing to avoid
false positives caused by differences in category ordering.
Bug: T373480
Change-Id: Idd14650a1898c6a49c88441ef024ce3012903bbe
This method has a weird behavior where it resets the category *link* list
while not resetting the category *list*. It turns out that no one actually
needs that weird behavior; in fact no one needs this method at all, since
the only external user is the Translate extension, which could use the
OutputPage::addCategoryLinks() method instead, which has existed since
2014 (Id25041a7891f588ffa787fdd2c092342eecd30c8).
Deprecate this method with warnings.
Bug: T373480
Depends-On: Id25041a7891f588ffa787fdd2c092342eecd30c8
Change-Id: I7b07d761eb8cd5ad1e6da2dd836e969a0d492c2b
This is the second patch of a series of patches to remove
ParserOutput::getText() calls from core. This series of patches should
be functionally equivalent to I2b4bcddb234f10fd8592570cb0496adf3271328e.
This patch replaces the calls to getText where the legacy parser is
called directly by creating a pipeline and invoking it on the generated.
These should probably eventually use the Content framework to generate
output instead of using Parser directly (T371008), which will also allow
them to transparently support Parsoid.
Bug: T293512
Change-Id: I45951a49e57a8031887ee6e4546335141d231c18
These were soft deprecated in 1.38, it's time to emit deprecation warnings
so we can complete their removal from the public API.
Change-Id: I437ab7dc8af4eb5d336e8074a42a0a54b4c00a4b
Now that PermissionManager can produce a PermissionStatus (1fbe8b761),
we need a way to display it without going through legacy error arrays.
Test plan:
* While logged out, access a page that all logged in users can access,
that uses the PermissionsError class (e.g. Special:Upload)
* While not an administrator, access a page that only administrators
can access, that uses the PermissionsError class (e.g. Special:Block)
Verify that you see the same error messages before and after this
change.
Change-Id: If21200ea1dd66f6443b03625d6a5b8ea416b2922
In change I625a48a6ecd3fad5c2ed76b23343a0fef91e1b83 I am planning to
make Wikimedia\Message\MessageValue use it, and we try to pretend that
it is a library separate from MediaWiki, so it makes sense to move
MessageSpecifier to the same namespace under Wikimedia\.
Bug: T353458
Change-Id: I9ff4ff7beb098b60c92f564591937c7d789c6684
This useless function contains useful documentation, that is best
kept with the rest of the business logic. It is only used once and
is literally `a - b`.
Change-Id: I650c37c4655bcc6edcd12186b24b0b1bd3faafd2
This allows the deprecated formatPermissionsErrorMessage function to
start emitting deprecation warnings and be removed one day.
Change-Id: Iea190deacdadb3e6b242042cfacbb406b8d92f9a
This allows rendering of the data passed to the skin rendering
layer, to allow developers to debug the information used to render
a skin.
Bug: T364696
Change-Id: I32aaa6a85d24df4f4689269f6a455823bb08196b
Follows-up Idb5b0d21adc6. Avoid hardcoded references to REST internal
configuration variables, which create awkward "APIs" in the long run.
These are hard to deprecate or detect use of, and even harder to
normalize/support once variations exist. E.g. in T189966 and T233886,
I've been working to remove the concept of dynamic config in favour of
the uncomputed values being only valid as configuration for the
component that owns the variable, instead of using Config as public
API to read non-normalized information that belongs to a different
component.
By making the recipient responsible for any dynamic computation, it
also becomes clear that these are in fact not normalized or validated,
which can expose any number of unpredictable behaviours if used
directly. Consider special values like `false` or `null` and the
responsibility for interpreting that. Accessing these from a stable
function also gives a natural place for deprecation to happen. The
alternative, is for dynamic computation to happen in Setup.php for
all variabls, and only ever grow and become an append-only dumping
ground for every thing that we feel at some point needs validation,
normalization or expansion, which doesn't scale well, hence I reversed
this trend in T189966/T233886.
As it happens, RestPath actually is already computed, albeit very
trivially. This patch opens the way for someone to remove that in
favour of PathRouter accept `false` directly and expanding (and testing)
that code there instead.
As for REST API, the only stable and universally supported entrypoint
is /w/rest.php. Unlike some older entry points, we don't support
moving or removing the rest.php file. We do support routing/aliasing
additional paths to it.
Change-Id: I589a8aed8db3b8e7b72e4505749bb7ef25a755d9
Migrate this icon to codex for the purposes of having it appear in night
mode correctly. Additionally, clean up the svg as it is no longer used
A couple notes:
1. This is not entirely visually identical to the current method - in
practice it ends up being nearly imperceptible, but worth noting that
even with the padding there is a slight vertical shift if you compare
them side by side
2. Due to the approach taken, I'm making the intentional choice to not
make this backwards compatible with cached HTML. This means a cached
page will not have an icon for the duration it is cached, which feels
like an acceptable intermediary state, but feel free to disagree with me
in code review!
Slight visual change due to aforementioned color and position difference
Bug: T366358
Change-Id: I1c53e1c501242f9f9ab88ef8e0e4e85fb1971fbe
Hard deprecated since MW 1.41.
Unique method name that does not appear in CodeSearch for MediaWiki
& services at WMF. Couple of CodeSearch hits using the "Everything"
filter.
Bug: T362636
Change-Id: I2ea134d31a8b18375183a4ae413e77dc0a6f1acc
Add unique classnames of the form "mw-permissionerror-$error"
on permission error message elements for easier debugging
Bug: T279915
Change-Id: I7c1a422f77b32240ebd6c40824f5b0b51329d541
This patch introduces a namespace declaration for the
MediaWiki\Content to TextContent and establishes a class
alias marked as deprecated since version 1.43.
Bug: T353458
Change-Id: Ic251b1ddfcf6db9c85cb54cddf912aa827d2bc3a
Move open search description endpoint from /w/opensource_desc.php
to /w/rest.php/v1/search.
Bug: T363984
Change-Id: Idb5b0d21adc6152ef77e6d17846b6acc6a904e01
This patch introduces a namespace declaration for the
MediaWiki\Content to JavaScriptContent and establishes a class
alias marked as deprecated since version 1.43.
Bug: T353458
Change-Id: I87c17327911e28a461feaf2ff46242454cff257a
Add strict types to private parsing-related methods
OutputPage::parseInternal() and OutputPage::addWikiTextTitleInternal()
and in the process hoist the "null Titles are not allowed" assertion
up a level to the callers.
Adjust some phan suppressions after this change.
Change-Id: If828d9ffa1edc292a1aca3eb6fe36daffa100bd4
Not sure why they are different in the first place, probably a mistake.
The `user` and `site` modules would be embeded as a string, so can be
previewed with <script> etc escaped properly, leaving the bug only
reproducible with User/global.js via the GlobalCssJs extension.
Bug: T360258
Change-Id: I61a3d9926dbfd7630c37bebd9d46fa49b05a4fc6
These link elements are unnecessary because (in this case) the locations are the default location for the files concerned.
They will be checked anyway by user-agents that make use of such files, so pointing to them is a waste of space.
Bug: T21392
Change-Id: I5e063bd002111243f6b38da1989a7baf2e4e05d3
It's just a worse version of showErrorPage().
Only 1 use in MediaWiki core, no uses in WMF-deployed extensions,
very few uses elsewhere.
Change-Id: I091e789891f60ed97dd84a25c2b2e0456a1af01e
* showPendingTakeover(): While $params can technically be
a MessageSpecifier (because a message can take another message
as a parameter), we don't usually explicitly document that,
and it seems like a result of some misunderstanding here.
Allow variadic parameters instead, like most message functions.
* addWikiMsg(): Document the hidden message key parameter, making
it really required. Remove documentation that refers to functions
removed many versions ago. Document a weird limitation on the
format of parameters, which is unlike most message functions.
* addWikiMsgArray(): Document a similar, but almost exactly
opposite, weird limitation on the format of parameters.
Change-Id: Icb8822def9ce56f42ff52a8e469bb08d61d576c6
