System messages along the lines of "you can't view this page,
please log in" get the login link (with returnto parameters) as a
HTML string, but sometimes one might want to customize the link
on one page without affecting all the other pages so it's nice
to have the raw link available as well.
Change-Id: Ib71791ea28718455d2925e4424147e87ef901f33
Originally landed in 1.33 in a3f63785ee.
Backported to 1.32 in cff9ab4b5c26dc87137aa2c04efd5d1f31226fe8.
Change-Id: I402c31b57904f6a6fd0b3a2c32a1c0a73c553254
Non-breaking change. Remaining uses are public interfaces (a constant, two
globals, a config sub-parameter, SQL queries, storage function names), one i18n
message key, and a whole lot of maintenance scripts with calls to the deprecated
function wfWaitForSlaves().
Change-Id: I6ee5ca92ccf6a80c08f53d9efe38ebb4b05064d7
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
Should be "string" not "String" and "array" not "Array" in
@param, @return and @var use cases. Also, minor typo fixes.
Change-Id: I9d5ebc5b741c6560907b95f7c0c4039da2861f4a
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
The `Key` header was a draft IETF specification which expired without
becoming a standard. It does not appear to be in active use anywhere.
Change-Id: I3924a1b5ff428b107573d2827c40e4af8adaaeb1
Also stop returning a value from OutputPage::adaptCdnTTL(). There are
no users and the value doesn't seem very helpful: one would probably
expect it to return the new value of mCdnMaxage, but instead it
returns the new value of mCdnMaxageLimit. Better to have no return
value than one that's easily misunderstood (*and* which nobody uses).
Change-Id: Ia9dab86923b839334eab9f6fde17c4aed52130ec
These have been replaced with OutputPage::addWikiTextAsContent().
There is only one apparent use outside core, in the ProofreadPage
extension.
Bug: T198214
Depends-On: I826e463c1623481c11156a55a5b7e1da0aa27b8b
Change-Id: I4b1a9429029bfbbf70b2d5da1b290319ecbbdf3a
Codesearch shows no users of `OutputPage::addWikiTextWithTitle()`,
and no users of `OutputPage::addWikiTextTitle()` (other than the
implicit uses by the other `OutputPage::addWikiText*()` methods).
These methods produce untidy output, which future parsers won't
support.
Bug: T198214
Change-Id: Id5ee3bdfa6c464e3a92af82af7bc7317ca9d07a9
Tidy will always be enabled with our future parsers, and it is fast
and pure PHP now with the Remex implementation, so deprecate all the
untidy variants of 'OutputPage::addWikiText*()' and add new methods
which tidy by default. Clarify the content language/interface
language distinction while we're at it by adding 'AsInterface' to the
name of methods which use the "interface language" by default,
and renaming the 'addWikiText*Tidy' methods to
'addWikiTextAsContent'.
The 'OutputPage::addWikiTextTitle' method has been deprecated, but it
is still used internally as the implementation for the newly-added
methods. It is expected that the shared implementation will move in
the future to a new private method. Setting the `$tidy` parameter of
`OutputPage::addWikiTextTitle` to false is independently deprecated;
for backwards-compatibility with old MW releases you may wish to
continue to invoke OutputPage::addWikiTextTitle() but set $tidy=true;
this will result in the same tidied output that the newly added
methods would produce.
Bug: T198214
Change-Id: Ia58910164baaca608cea3b24333b7d13ed773339
Introducing setCopyright/hasCopyright in OutputPage to
make the showing of the copyright message controllable
by pages other than articles.
hasCopyright defaults to isArticle() to preserve the rule
that all article should show the copyright.
This is used by Flow to show the copyright
on various pages that contain user-generated
content.
Bug: T184960
Change-Id: I3a50dbcedc6b119b9262c50cb3a84b0dd230fb3d
There are three methods affected: `OutputPage::addWikiTextTidy()`,
`OutputPage::addWikiTextTitleTidy()`, and
`OutputPage::addWikiTextWithTitle()`.
There's a special case in Parser.php which adds the wrapper class from
ParserOptions to the ParserOutput only if "interface mode" is off; the
affected methods default to adding output in "content language" mode
(not "interface language" mode), but they seem to be used for
"interface messages in the content language" (rare) and so should also
be unwrapped. This would make all the `OutputPage::addWikiText*()`
methods consistent.
The `OutputPage::addWikiTextTidy()` method is only used once in the WMF
repositories, where it is used to insert an interface message in the
content language:
91cd2a928f/SpecialProofreadPages.php (40)
The `OutputPage::addWikiTextWithTitle()` method is used by no one:
https://codesearch.wmflabs.org/search/?q=addWikiTextWithTitle%5C(
The `OutputPage::addWikiTextTitleTidy()` method is used only in core:
3888c001a1/includes/EditPage.php (2669)
It seems clear that the output in this case is intended to be
unwrapped as well (the codepath adds its own explicit wrapper).
Ia58910164baaca608cea3b24333b7d13ed773339 will add additional
documentation to clarify the distinction between the different
OutputPage::addWikiText*() methods, but I felt it safer to make
this particular change first as a standalone patch, just in case
it had unexpected side effects or merited further discussion.
Change-Id: I3e5b598d358819191562b56d40ebf1cb6f3cda41
One use case of display title is to localise page names with Translate
extension or without. While the page title changes, the subheadings still
say something like "Pages in category Foo/de".
Also converted one raw HTML message to be a parsed message.
First version of this patch caused an issue when previewing
because page title in h1 is not the same as page display title.
This issue is fixed by promoting page display title as it's own member
in OutputPage. Also added getUnprefixedDisplayTitle that attempts to
strip away the namespace prefix to mimic Title::getText() but which
works with display title instead.
Bug: T43720
Bug: T46197
Change-Id: I6097a873297eb57759252fc56ad6d02c44e4c366
This was introduced in OutputPage before support for getPreloadLinks()
was added to ResourceLoader. The introduction in ResourceLoader was
actually inspired by this original implementation.
Now that we have it, we should make use of it for this module
as well. Doing so has several benefits:
* Makes the code cleaner by not requiring every skin to implement
the extra boolean method. Instead, it naturally works. If
the skin loads the SkinModule, it gets the preload as well.
If not (such as Minerva, which has a different logo config),
then it also doesn't get the preload link.
Naturally, automatic.
* Makes code cleaner by not having static methods, and by not
having OutputPage call into a Module class.
* Fixes the problem where, if a site's logo is changed, all cached
HTML is preloading the old logo whilst the stylesheet fetches
the newer one. Causing both to be downloaded.
* Still preloads the logo well before it can render.
Change-Id: I11b390f2e4f5e7db8b4506ab547839152888005c
In some functions MediaWikiServices::getInstance() was called twices or
in loops. Extract the variable to reduce calls.
Change-Id: I2705db11d7a9ea73efb9b5a5c40747ab0b3ea36f
Previously domEval didn't have CSP nonces, causing it to violate
the policy.
Also removes the meta tag scheme, as I could not make it compatible
with how RL storage works using domEval instead of real eval() and
it didn't provide much protection anyways.
Bug: T196923
Change-Id: I3cd2d7cc295c39b498d0bf37915d4ba167fdd48c
They were accidentally made non-functional in April 2009 by commit
e4d21170. Subsequent commits 2d045fa1, 9e230f30, e275ea28, ae45908c
removed all callers by October 2011. Needless to say, I found no
callers in core or extensions.
It seems we have the functionality in some other way, probably just by
directly calling setHTMLTitle(), so there's no need to revive this
feature.
Bug: T200643
Change-Id: Ifa2537b97cf19e7e91ee33d4ea4c131f7a38ee89
EditPage::getPreviewLimitReport is called by EditPage::showEditForm
with $output = null. Specify this in the @param tag and allow this by a
default value.
Change-Id: Iec8905aab736a1f254a57853c7cab935d008653e
Based on documentation together with inspection of some callers, the
intent seems to be that this is an indexed array, not associative. +
will therefore do totally the wrong thing, ignoring any new values that
have the same key as an existing item (e.g., '0' or '1'). Even if it
was an associative array, + keeps the values on the left-hand side,
which means you normally want to do $foo = $bar + $foo instead of $foo
+= $bar if you want to overwrite old values with the new ones.
Before this change, calling addLanguageLinks() or
addParserOutputMetadata() would generally not add all of the links it
was supposed to if there were already links defined. (It could still
work if the arrays' keys didn't conflict for some reason, e.g.,
something passed an associative array or an indexed array with a hole.)
I don't know if anything actually hits this bug, because it's likely
that callers usually add all their links at once. I find no uses of
addLanguageLinks() at all.
I found this bug while working on adding more tests for OutputPage, and
the tests for this change will be submitted later in
Icdc0288c04b8c4ba841f9fbb3e05a0cdc8a20fa5.
Change-Id: I53f6e7ea94417b0034371e56e733e8c86af21658
addMetadataLink and getMetadataAttribute were added in 2004 (22f8c4ce)
for functionality that was moved to extensions in 2011 (27c3b22b).
Those extensions, CreateCommonsRdf and DublinCoreRdf, now use
addHeadItem() directly. There are no other callers in core or
extensions.
Change-Id: I4bc21fdaefc8f56969a2950eb53b340bf4aac399
Code search revealed only one outside access, which I've submitted a patch for.
Depends-On: I001deecad241b091070483d882088d2d6361ed5a
Change-Id: I0f7e565f4eacc1074c619772b2d11a47a05e3584
Code from wikiHow codebase, where this hook is used by the following extensions:
* AlternateDomain -- used to remove certain links altogether and change the contents of other elements (e.g. <meta description="..." />)
* hooks (PageHooks) -- used to hide certain links for anons on noindexed pages to avoid leaking article info to Googlebot
* QADomain -- used to remove certain elements and correct <meta keywords="..." /> tags not to mention "wikiHow" if that string is present
* search (LSearch) -- used to remove canonical URL on Special:LSearch for SEO
Change-Id: I4a9ceb343bb5c0b4eb79e4589d36c3790938f8a9
OutputPage has a number of specialized error reporting methods
related to file handling. With exception of showFileDeleteError,
they are all unused. In my opinion such specialized error handling
does not belong in OutputPage, but in whatever class is generating
the error.
Futhermore, these functions do not appropriately escape their
arguments or their i18n messages. I replaced the one usage
in SpecialUpload with an equivalent that does escape properly.
This is not exploitable as the attacker is not in control of
the temporary file name, but it is very bad practice.
This deprecates the following methods:
* OutputPage::showFileDeleteError()
* OutputPage::showFileNotFoundError()
* OutputPage::showFileRenameError()
* OutputPage::showFileCopyError()
* OutputPage::showUnexpectedValueError()
[Discovered with the help of an experimental phan plugin]
Change-Id: I9e7aaa59ded66f32c78cfdfed1e59e073ffd5051
The current rollout plan calls for initial rollout to only
disallow external JS, and leave removing unsafe inline stuff
to a later date. Thus this adds a useNonces option to the CSP
config to allow that.
Renamed ContentSecurityPolicy::isEnabled() to isNonceRequired
for clarity. The old name has never been in a released version
of MediaWiki, so is removed immediately.
Change-Id: I756d8e97b77c6f97dbbf040a20c8750fecb157c5
