* Do not store table of contents in parser output
* Instead inject table of contents via strpos where needed
inside Article based on Skin "toc" option
* Use <mw:tocplace> as a TOC placeholder; for Parsoid compatibility
this will be replaced with a <meta> tag in a followup patch.
Bug: T287767
Change-Id: I44045b3b9e78e7ab793da3f37e3c0dbc91cd7d39
This feature was removed in 2013 (Ia8d79b4a, T49504), with further
remnants removed in (1965df8df3, I7c24128f7b1).
* Simplify the code of transformCssMedia() as it now only needs to
support printable=yes.
* Remove query parameter abstraction from test cases, use query
array directly.
* Remove internal use of the $handheld parameter.
Function signature of makeLoaderQuery() left in-tact for
compatibility with $extraData. This will be deprecated and removed
in a follow-up commit.
Bug: T49504
Bug: T32956
Change-Id: Id16ef3f4630538de1887ac2327eb317c6c6b1f9d
In all cases where the client registry is used, the `noscript` module
is inapplicable. Additionally, make it illegal to have a module
include the 'noscript' module as a dependency.
Bug: T291735
Change-Id: I5846f2c19b003989b56b12628b385fd37049483b
The value in the attribute displaytitle must contain valid HTML. The
sanitizer of the {{DISPLAYTITLE}} parser ensures that only valid HTML
is accepted.
If there is no {{DISPLAYTITLE}} in the wikitext then displaytitle
falls back to $title->getPrefixedText(). Here an HTML encoding of
special characters is necessary. This affects only the replacement of
& by & because other special characters like < and > are not
allowed in the title.
This change affects the displaytitle fallback on the following places:
* ApiParse
* ApiQueryInfo
* InfoAction
* Parser
The displaytitle fallback in OutputPage is also updated to this
behavior although
Sanitizer::normalizeCharReferences( Sanitizer::removeHTMLtags( $html )
also replaces & by &.
Also add test cases with & in the displaytitle to:
* ApiParseTest
* ApiQueryInfoTest
* parserTests
Bug: T291985
Change-Id: I8ee1e2731d9bfa49725d663b34986e7e3073e4ca
This name is consist with the rest of the setter and getter methods
in ParserOutput. Renamed the methods in OutputPage, ImageHistoryList,
ImageHistoryPseudoPager, and ContribsPager as well for consistency;
it also makes chasing down lingering references in codesearch easier.
Soft-deprecated the old name for 1.38. Hard-deprecation will follow,
but there are a number of users in production that should be chased
down first.
Code search:
https://codesearch.https://codesearch.wmcloud.org/deployed/?q=(allow%7Cprevent)Clickjacking&i=nope&files=&excludeFiles=&repos=
Bug: T287216
Change-Id: I9822c60c180d204bd30cb4447a1120155d456da4
ContentHandler::getContentText() is deprecated and should be
replaced with Content::getText() for TextContent instances.
Change-Id: I556d3d3f64fafd1d54c4a0c5021efaff2d9c3ce8
Also prepare OutputPage::getBottomScripts to handle the work of
SkinAfterBottomScripts hook in the future.
Bug: T257704
Change-Id: Ib0a8b72faa88259c24b5fb7e9d5a908423494247
Per docs added in I18767cd809f67b, these don't need normalization
as they are only compared against predefined strings, and besides
are generally entered manually in a form, and even then would not
require the kinds of Unicode chars that have multiple/non-normalized
forms.
In nearby areas to also fix some trivial cases:
* getVal('title') obviously needs normalization.
Use getText() to make this more obvious.
* getVal() compared against simple string literals within the code
obviously don't need normalization (e.g. printable === 'no').
* Change hot code in MediaWiki checking for whether 'diff' or 'oldid'
are set to getCheck (which uses getRawVal) instead of getVal.
As a bonus this means it now handles values like "0" correctly,
which could theoretically have caused bad behaviour before.
Change-Id: Ied721cfdf59c7ba11d1afa6f4cc59ede1381238e
Functionality has been moved to MonoBook.
Bug: T97892
Change-Id: I3d4d74a2caa77f975b415af5977253ddeff6af21
Depends-On: I598c4469c46d284562ea3aec79330f9a1f40d2ce
These methods have been replaced by skin options.
Skins should now declare their style modules in skin.json using
the `styles` option.
Bug: T280610
Change-Id: I24abe7e2539499089e91151d9122e05bcb2d32ca
Number ranges are common and easily mistaken as telephone numbers by
the data detectors of popular browsers. To link a telephone number,
use the explicit [tel:phonenumber display value] syntax.
If you want to re-enable, set the BrowserFormatDetection configuration
variable to false.
Bug: T256758
Change-Id: I49dff3c084d8c9a66defcdae5a1ffb8f35ba8a93
These are now named $wgDatabaseReplicaLagWarning and
$wgDatabaseReplicaLagCritical, respectively.
Bug: T277987
Change-Id: I62d8c2028fdfee00904f1058f8387499f2b2e977
Skin is what takes a user or extract it from a title to set relevant
user and so this is the right place to handle permission check too
because if the user is hidden, it should be made known for all
callers, instead of hoping each caller will do similar check
which is duplication and not guranteed.
Skin:setRelevantUser always takes user and this is now typehinted to
avoid errors. Callers need to give what's required.
Bug: T120883
Change-Id: I177cd83a9c4f87c27a63d8f530c40895d0f3f5dd
The intended word in all these cases was the adjective "dependent".
Whilst the "dependant" does exist, it is a noun and generally
refers to a person. The word is rare used in general, but
especially so in a technology context.
Change-Id: Ic7e2d2ea6a566f4139ff1fdb77f38b0e962ccd9c
This was broken by I2dd2b71.
In that patch MediaWiki::outputResponsePayload() was introduced and it
added another output buffer layer on top of Outputpage::output( true )
which directly outputs and return empty string if $wgDebugRedirects is
true (and the location is redirect).
Because Outputpage::output( true ) returns empty string in that case,
the output buffer started by MediaWiki::outputResponsePayload() will
always end up with empty string, and the print() in Outputpage cannot
send the output because it's now nested inside another buffer layer
with call to ob_end_flush(), which discards contents of inner buffers.
Previously it worked because the return value of Outputpage::output()
was not wrapped in another output buffer then, so the direct print of
the html was enough to make it work.
This patch modified Outputpage::output() to return the html string if
$wgDebugRedirects is on, and return value is requested --instead of
outputting it-- that way the debug html will now be captured in the
topmost buffer layer inside MediaWiki::outputResponsePayload()
Bug: T236639
Change-Id: Ibe4e771b0530b7c6bb7132c88c8455b0ef4fde0e
This is micro-optimization of closure code to avoid binding the closure
to $this where it is not needed.
Created by I25a17fb22b6b669e817317a0f45051ae9c608208
Change-Id: I0ffc6200f6c6693d78a3151cb8cea7dce7c21653
This reverts commit 900c6663b0.
Reason for revert: breaks Parsoid CI. Instead of fixing the test in presence of the FlaggedRevs hook, I would rather convert DefaultPreferencesFactory to Authority and fix the tests once instead of doing it twice.
Change-Id: Iaa440a9804c9ed97339e737162ef64ccf29ceb51
When viewing Special:Contributions for a hidden user and
a missing user, or the user page of a hidden user and a
missing user, if the viewer cannot see hidden users
the output should be the same for hidden users and
missing users.
To that end
* In OutputPage.php, only set the `wgRelevantUserName` javascript
variable if the user is not hidden, or the viewer can see hidden
users
* In Article.php, show the `userpage-userdoesnotexist-view` on user
pages of hidden users if the viewer cannot see hidden users
* In Skin.php, do not add user-specific sidebar links (contributions,
logs, mute, etc.) if the user is hidden and the viewer cannot see
hidden users
* In SpecialContributions.php, stop calling Skin::setRelevantUser
for non-existing users, so that callers of Skin::getRelevantUser
can ignore users that are hidden from the viewer without creating
divergent behavior
* In SpecialContributions.php, for users that do exist but are
hidden from the viewer, don't show `sp-contributions-footer`,
but do show `contributions-userdoesnotexist`
Bug: T120883
Change-Id: I83b723402f315447bc4b50992e28620e3daace8f
Replace direct access to $wgDisableLangConversion with
LanguageConverterFactory::isConversionDisabled(), and replace direct
access to $wgDisableTitleConversion with
LanguageConverterFactory::isTitleConversionDisabled(). However, most
places that check ::isTitleConversionDisabled() actually want
::isLinkConversionDisabled(), so add that too (and deprecate
isTitleConversionDisabled()).
Code search:
https://codesearch.wmcloud.org/search/?q=Disable%28Lang|Title%29Conversion&i=nope&files=&repos=
This change removes a number of spurious dependencies on the global
configuration and reduces code duplication (for example, if the logic
for disabling language conversion were ever to change).
Depends-On: I6fa8230ae97b0e34c381003548e61f9b7387d363
Change-Id: Icc4687638ff1815003dd903854efdbd904854f1e
Check the internal array of styles to determine whether
the method was inappropriately used to alter the array of styles and
if it was, call wfDeprecatedMsg().
Change-Id: I591b03c2e19d4b8cadfe220b498ae244d332f9fb
The commit did not really hard-deprecate overriding of setupSkinUserCss() as stated in the commit message, rather it removed core calls to setupSkinUserCss(), instantly breaking the many skins that still override it. It did not actually create a deprecation period for graceful migration.
As discussed in T267080, there is presently no way to hard-deprecate the override of a method.
This reverts commit 334cfeffd6.
Bug: T257990
Change-Id: I8f669ba30affc437800890c3a875994a9f2eb3c8
There are three cases in CSSMin::remap where performs path
resolution.
1. Absolute local path URLs to full URL.
Example: url(/static/foo.png), url(/w/index.php?…), etc.
These previously used wfExpandUrl(), which got the server
name and protocol directly from $wgServer.
We will now use the $remote parameter to get this information
instead, which is generally set to something like
https://wiki/w/resources/foo, and thus naturally contains
the server name and protocol.
The resolution is powered by the Net_URL2 library, allowing
this to work outside Mediawiki as well.
Some tests needed to change because they were calling CSSMin::remap
with an incomplete $remote dummy values like "/" or "/w, because
the test author (past me) was trying to be clever by not supplying
it, knowing MW would ignore it. Now that it is consistently used,
like normal calls from ResourceLoader would, the expected values
will always be based on http://localhost/w, instead of sometimes
the competing $wgServer value of `https://expand.example`.
2. Relative local path to full URL
Example: url(foo.png), url(../foo.png), url(bar/foo.png)
These were already using $remote. The only change is that
they now use Net_URL2 library instead of blind string
concatenation. One of the benefits of this is that we will
no longer need to call wfRemoveDotSegments() to get rid
of things like double slashes or redundant "../" sequences.
Previously, thing like "foo//bar" or "foo/../bar" were cleaned
up only due to wfRemoveDotSegments(). This is now naturally
handled by Net_URL2.
3. Remote URLs
Example: url(http://example.org/bar.png), url(//example.org/bar.png)
This is generally not used in source code, but gadgets may use this,
e.g. for upload.wikimedia.org or cross-wiki imports.
Other changes:
* One test case used spaces within the URL string in CSS, which the
net_url2 library represents with percent-encoding instead.
Same thing either way.
Bug: T88914
Change-Id: Ibef70cc934c0ee8260a244c51bca9fb88c1c0d88
