With the removal of HHVM support, we can now use explicit varargs
in function arguments. This patch updates the BaseTemplateclass to
do so, and also removes PhanCommentParamWithoutRealParam check suppressions,
which are now redundant.
Bug: T231710
Change-Id: If78bd1556c862a472afe3646fd362b3c6baefbe0
This allows us to remove many suppressions for phan false positives.
Bug: T231636
Depends-On: I82a279e1f7b0fdefd3bb712e46c7d0665429d065
Change-Id: I5c251e9584a1ae9fb1577afcafb5001e0dcd41c7
in case this is not done in SkinTemplate::buildContentActionUrls()
Not all skins are going to use buildContentActionUrls() in the first
place, as they may not be laying out the usual action tabs as, well,
the usual action tabs. Given that this is being added in core, it
should likewise be cleaned up in core.
Bug: T214202
Change-Id: I630410aea2852f7a72fea67bbf256b3561ea0f3f
A link to Special:Mute is added to the tools menu on the sidebar
if the user is logged in and a registered relevant-user* is found
Mute preferences link will not be shown if $wgEnableSpecialMute is false
* From Skin::getRelevantUser: Special pages like Special:Contributions mark
the user which they are relevant to so that things like the toolbox can
display the information they usually are only able to display on a
user's userpage and talkpage.
Bug: T218270
Change-Id: I89eb8373963d28d52a026b60aa42d1c64b31b7c6
This method just should not exist. It does have a bad name that does not
say much about what it does and how it is supposed to be used. And it
does horrible things: it accesses the global $wgOut, which currently
results in test failures, see
https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php70-docker/15200/console
Note how it was marked as @private, which is honorable, but doesn't
work for multiple reasons. First, an overload exists in the BaseTemplate
subclass. Second, calls from external code exist. Third, if it would be
really private, it could as well be deleted, because there is no private
caller.
Luckily the number of callers is extremely close to zero, see
https://codesearch.wmflabs.org/search/?q=>msgWiki%5C(
A patch for the Collection extension already exists.
Change-Id: I8d2c14f10fbf314735d1aa82bdc8edfb4fa9a0dd
QuickTemplate::msgHtml() (And the weird override that does the
same thing a different way - BaseTemplate::msgHtml()) are inherently
unsafe as they echo out a raw html message. This is strongly
discouraged in modern code. According to codeSearch tool, nothing
uses these methods, and there is a "@private" annotation on the
QuickTemplate::msgHtml() docblock. Thus hard deprecating it.
Change-Id: I4e9e157e922a36787adef4d0bf7608605c27f0c4
Uses new PHP 5.6 syntax like ...parameter unpacking and
calling anything looking like a callback to make the code more readable.
There are much more occurrences but this commit is intentionally limited
to an easily reviewable size.
In one occurrence, a simple conditional instead of trickery was much more readable.
This patch finishes all the easy stuf in the core, the remainder is either unobvious
or would result in smaller readability gains. It will be carefully dealt with in
further commits.
Change-Id: I79a16c48bfb98b75e5b99f2f6f4fa07b3ae02c5b
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
* Fix ResourceLoaderClientHtml to return what it was documented to
return, a WrappedStringList. It accidentally used the wrong join()
method, causing it to create a plain string too early.
* Update method documentations from ClientHtml::getBodyHtml to
BaseTemplate::getTrail for 'bottomscripts', and from
ResourceLoader::makeInlineScript for 'reporttime'.
* Update BaseTemplate::getTrail to join by new line instead of native string
concatenation.
This by itself would suffice for the most common case, but in order
to also account for the possibility of extensions using hooks for
'SkinAfterBottomScripts' that concatenate, update bottomScripts()
to pass a plain string to the hook and merge it later.
Change-Id: If0d227cb9db67229a27d489c082db790ea8e3840
This code path is never used.
When introduced in 2005 (bf0d92d5 / rSVN10709), the "Permanent link"
item in the MonoBook sidebar was a link to an oldid only when viewing
the latest version of an article (using the ID 't-permalink'), and
otherwise it was a greyed out link to nowhere to indicate you're
already viewing a permanent link (using the ID 't-ispermalink').
Later, in 2007, when the behavior of "Cite this page" item (now part
of the CiteThisPage extension) was corrected for old revisions
(1a60bd4c / rSVN21819), the "greying out" of the permalink was removed
to be consistent with the new item. Only half of the feature was
removed though: permalink was no longer a link to nowhere, but the
code in MonoBook to make permalinks that are links to nowhere greyed
out (by using different ID) stayed.
This code was then dutifully preserved when BaseTemplate, MonoBook was
rewritten, and then through several refactorings.
I think we can safely remove it. Leftover styles in MonoBook are being
removed in I58aca1f4255df14d6289e167e180dad31b546a8c.
Change-Id: I2fb3d7e0ecb3bbbd0c09774e2d86f86502a48bf1
Remove all usage of $tpl->translator->translate() with wfMessage()->text(),
which does the same thing, given the deprecated $tpl->translator->set()
and $tpl->setTranslator() methods have no callers.
These new wfMessage() callers should probably be changed to context calls
via BaseTemplate::msg() or Skin::msg() at some point, but I'm reserving that
for a separate commit given wfMessage() is what MediaWikiI18N::translate()
currently does - to reduce risk of unrelated behaviour changes.
While `$tpl->setTranslator` and `MediaWikiI18N::set` ($tpl->translator->set)
have no known callers in Wikimedia Git, the `$tpl->translator->translate`
method does have a handful of calls (although less than three, and not in
bundled or WMF-deployed repos). As such, proceeding with hard-deprecation.
Bug: T186090
Change-Id: I93d503de5515298288852ec4c150959fd688786b
And changed a little bit signature of Linker::titleAttrib
and Linker::tooltipAndAcceskeyAttribs. Added $options
parameter to the second one and made $options parameter
satisfied by passing an array with options, because there
is one more now: 'nonexisting' which tells to add text
about the thing that the page does not exist to its tooltip.
Bug: T19099
Change-Id: Ia76dd6db363f6add5efb8955be9e23a1f8e8476f
For some varargs a variable name is added with suffix ,... as seen for
many other varargs
Some @param are swapped, because there are in the wrong order
Enable Sniff MediaWiki.Commenting.FunctionComment.ParamNameNoMatch
Change-Id: I60fec6025bce824d5c67563ab7b65ad6cd628ad8
It adds the ability to replace the current section ID escaping
schema (.C0.DE) with a HTML5-compliant escaping schema that is
displayed as Unicode in many modern browsers.
See the linked bug for discussion of various options that were
considered before the implementation. A few remarks:
* Because Sanitizer::escapeId() is used in a bunch of places without
escaping, I'm deprecating it without altering its behavior.
* The bug described in comments for Parser::guessLegacySectionNameFromWikiText()
is still there in some Edge versions that display mojibake.
Bug: T152540
Change-Id: Id304010a0342efbb7ef2d56c5b8b244f2e4fb2c5
When viewing Special:Search, you usually see two search forms: the
small one provided by the skin (present on all pages), and the large
advanced search form generated by Special:Search.
Previously, both of these forms would be prefilled with the text that
was searched, which could lead to the user submitting the wrong form
after changing advanced search options.
After this change, the skin's search form will always start out empty.
There's no way for this to affect pages other than Special:Search,
since if the 'search' URL parameter is given, all requests are
redirected to Special:Search anyway (see MediaWiki::parseTitle()).
Bug: T106055
Change-Id: Ic6bb8af5383e7acfe4f823f563165cd60182753e
Per 53ab861a2f, extensions can set this
to an empty array to have the sidebar section displayed even if it has
no items. Wikidata and UniversalLanguageSelector rely on this.
Change-Id: I79cef25d79ed25fa6d96698a121c3105870e890b
Breaks any skins with same-name functions with different
visibility/functionality. Should mostly only be anything
based on Example, because that had everything set to private
for some reason. Normal skin practice for most others is to
use totally different names anyway. (eg 'render...' instead
of 'get...', and visualClear output done directly)
* clear: returns a visualClear
* getFooter: calls getFooterIcons and getFooterLinks and
handles all the output; format is common to nearly every
skin since MonoBook
* getAfterPortlet: same as renderAfterPortlet, but doesn't
directly print content
* getTrail: same as printTrail, but doesn't directly print
content
Also made the existing print versions for the last two use
the new getters.
Change-Id: I5621f585b501e47b40ae80e9cb12e6a32da72275
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
Use of &$this doesn't work in PHP 7.1. For callbacks to methods like
array_map() it's completely unnecessary, while for hooks we still need
to pass a reference and so we need to copy $this into a local variable.
Bug: T153505
Change-Id: I8bbb26e248cd6f213fd0e7460d6d6935a3f9e468
It looks like there is something missing after the last statement
Also remove some other empty lines at begin of functions, ifs or loops
while at these files
Change-Id: Ib00b5cfd31ca4dcd0c32ce33754d3c80bae70641
wfMessage() and IContextSource::msg() allow you to pass parameters to
the message in the initial function call, which is often more convenient
for developers. Support that in BaseTemplate::getMsg() too for
standardization.
Change-Id: I2488234f431be5bab00ca4366d864c84d7ff9e03
We are limiting the attributes that are read and rendered for the
personal toolbar, but there are cases -- especially as tools get
more and more complex -- for needing to supply and read more information.
The use case that led to this change is the need to style Notification
badges with values in ::before and ::after pseudo-elements; these
elements need to display some prefixed content, and the best (only)
way to do that in no-js mode, is to set it up in CSS to be read
out of an attribute (using attr( xxx ); ).
This means that we need to read a specific attribute from the element,
but the only attributes allowed were insufficient. Allowing for data-*
attributes seemed not only a good solution for this specific case,
but a good idea in general for future tools that are added and
manipulate the personal toolbar links - allowing for storing information
without polluting the DOM.
Bug: T115845
Change-Id: Ic666540d70de52f337f839da0518cb83a990f5fd
Due to T127238, files in various */skins/* directories are not checked
by PHPCS. Temporarily removed the exclude rule from phpcs.xml and ran:
composer fix includes/skins/* tests/phpunit/includes/skins/* tests/phpunit/skins/*
Change-Id: I9240c1cee825920b6634903282be6252cce55686
You can now pass parameters to toolbox links' tooltips,
by setting 'tooltip-params' key in a $nav_urls item of
SkinTemplate::buildNavUrls.
This functionality is used to add GENDER support to two
tooltip messages.
Bug: T123365
Change-Id: I45577d54bd78ba1e2ba10fb8f04367244495bfea
Xhprof generates this data now. Custom profiling of various
sub-function units are kept.
Calls to profiler represented about 3% of page execution
time on Special:BlankPage (1.5% in/out); after this change
it's down to about 0.98% of page execution time.
Change-Id: Id9a1dc9d8f80bbd52e42226b724a1e1213d07af7
Page status indicators are icons (or short text snippets) usually
displayed in the top-right corner of the page, outside of the main
content. Basically, <indicator name="foo">[[File:Foo.svg|20px]]</indicator>
may be used on a page to place the icon in the indicator area. They
are also known as top icons, page icons, heading icons or title icons.
I found the discussion on bug 23796 highly illuminating. I suggest
that everyone read it before suggesting different design choices.
I spent some time with a thesaurus pondering the name. "Emblems" and
"badges" were also considered, but the former has a much more limited
meaning and the latter is already taken by Wikidata, with a similar
but subtly different feature set. I am not aware of any naming
conflicts ;) besides new talk page message "indicator" (used by core
and Echo in some documents) and OOjs UI indicators (tiny icons like
the arrow on a dropdown form element), which shouldn't be confusing.
Potential use cases include:
* "Lock" indicators for page protection levels
* Featured/good article indicators
* Redirect shortcuts display ("WP:VPT")
* Links to help/manual for special pages
* Coordinates?… or globe icon for inline pop-up maps
Design features:
* Skin-customizable. Skins can fully control where and how indicators
are shown, or may just do <?php echo $this->getIndicators(); ?> to
output the default structure. By default they are not shown at all.
* Extension-customizable. Extensions can call ParserOutput::addIndicator()
to insert an indicator from one of the numerous parser hooks.
* Wiki-customizable. In addition to just using the parser functions,
on-wiki styles and scripts can use the provided classes and ids
(.mw-indicator, #mw-indicator-<name>) to customize their display.
Design limitations:
* Every indicator must have a unique identifier (name). It's not
possible to create arrays, or to have several indicators with the
same name. In case of duplicates, the latest occurrence of the
parser function wins.
* Indicators are displayed ordered by their names (and not occurrence
order). This ensures consistency across pages and provides a simple
means of ordering or grouping them.
* Indicators are not stored, tracked or accessible outside of
ParserOutput (in particular they're not in the page_props table).
They are intended to merely reflect the content or metadata that is
already present on the page, and not be data themselves. If you ever
think you need to list pages with a given status indicator, instead
figure out what it means and use the appropriate tracking category,
special page report, already existing page_prop, or other means.
Corresponding patch in Vector: I90a8ae15ac8275d084ea5f47b6b2684d5e6c7412.
I'll implement support in the other three skins included in the tarball
and document it on mediawiki.org after this is merged.
Bug: 23796
Change-Id: I2389ff9a5332a2b1d033eb75f0946e5241cfaaf4
