When working on multiple skins its been confusing to know how the lists
are created from the HTML. In Vector we've also resorted to some overly
complex styling rules to style `li` elements. It's proposed a mw-list-item
class is added to simplify Vector styling and make it easier to understand
how the HTML is generated.
Change-Id: I67731fe59743620d339ffcca3ffc3b1f127ce3e7
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
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
Pass a valid key to makeLink rather than an integer (index)
which may result in an exception.
Bug: T286040
Change-Id: Ic69ec102caec982e65e264f5812ac15df5168008
This is going to be needed for skins that support icons as
in the new mw-ui-icon implementation, labels must be wrapped
in spans.
This is made a skin option so skins can control.
It will be used in Vector (Ia2d2c86e61341b9900f9ac337ddd763252e0515f)
Bug: T191021
Change-Id: I2bfaebf5d766240b57d7baed445001a007634839
The `class` property on menu items applies to the <li> tag however
in the case of the personal tools menu for historic reasons it applies
to the anchor tag. To bring these in line, a new optional parameter
is added that is utilized inside SkinMustache. Given the method is
final we do not need to worry about skins extending this behaviour.
This is needed for the mw-ui-icon change as we want to separate
the <a> tag with the mw-ui-icon class from the padding of its container
on the <li> item.
This also makes use the "new" class is added to the userpage link rather
than the list item by using the link-class property. This does not impact
existing skins as the impact is the same before and after this change.
This will temporarily break skins making use of user-menu, but this was
introduced in 1.37 which has not been released yet, so it's okay to
introduce breaking changes. It is currently only used by Vector
Bug: T285960
Change-Id: If399dfff9bbdd3b03b2ca702face3ec5164bef11
This is a breaking change, but I've reviewed all usages
and there's nothing that requires full User object to be
returned. Maybe it's too bold, following the deprecation
process is not too hard either.
Change-Id: Id22580945f594d7e0de533226f6c374a7a97fe1e
… including PHPDoc tags like `@return <type> $variableName`.
A return value doesn't have a variable name. I can see that
some people do this intentionally, repeating the variable
name that was used in the final `return $var;` at the end
of a method. This can indeed be helpful. I leave a lot of
these untouched and removed them only when it's obviously
wrong, or does not provide any additional information in
addition to what the code already says.
Change-Id: Ia18cd9f25ef658b08ad25b97a744897e2a8deffc
Sysadmins could unset the entire copyright array in FooterIcons.
Might as well make sure it exists at all before checking if it has
something usable. Also simplifies related testing.
Change-Id: I56e06d564a9d60851d10e69065fd70dd51025bd2
This check is now in Skin::getRelevantUser() method itself and
so is pointless to repeat.
It was supposed to be removed in I177cd83 but was restored
unintentionally in one of the rebases
Follow-up: I177cd83a9c4f87c27a63d8f530c40895d0f3f5dd
Change-Id: Ic1758775ecd6992e162f1e7461a9ae7afdc9bcd0
This was done originally in Ie530051, but it seems was partially
reverted when I177cd83 was merged.
Change-Id: Ib699f3519a12b442adcd31938a1394918f3a74f7
Before this patch, if 'search' is in the request params then we always
go to Special:Search. Also, the 'title' param on the top-right search
form is always set to Special:Search, which means that form always goes
to Special:Search too.
In order to allow the search form to go to a different page, this
patch:
1. moves the hardcoded redirect to Special:Search based on 'search' in
the request params, so that it only happens if we cannot determine
the page title in the usual way
2. adds a setter for the default search page title in \Skin, so that
it can be set in a hook
Bug: T273879
Change-Id: If62573d19ca76ed1db53a5117182172233e514ab
Per docs, getHTMLTitle
Return the "HTML title", i.e. the content of the "<title>" tag.
getDisplayTitle can return HTML
Bug: T157145
Change-Id: Ib9aa89d10a1263308b5426306f2c8b046084553b
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
We started to call Authority argument $performer everywhere,
and $performer->getPerformer() doesn't look that good.
Change-Id: Id2cf3f27b18340314e4ed1ea9931ad9404b4df6f
The following fields are needed for the display of Twitter cards
In conjunction with Ie5889b4a4a5685298fe00ecced0dbebb91d7f87c this
should provide the minimum to let cards render on Twitter.
By default this change will have no effect on page rendering,
to avoid any conflict with existing solutions, for example in
Wikidata.org.
Bug: T157145
Change-Id: I7f6cf7b415ad122b24c428cee2df2d3fed362395
This allows separating notifications from personal tools.
The notifications are still inserted into the personal tools,
after the userpage, for skins using BaseTemplate, skins that
call buildPersonalUrls without the argument, skins that call
either getStructuredPersonalTools, makePersonalToolsList without
providing it personal tools or getPersonalToolsList.
Mustache skins that use data-personal are unaffected, and can
retrieve personal tools without notifications from data-user-menu
and notifications from data-notifications, both of which are in
the data-portlets array.
Notifications are manually inserted in both SkinTemplate and
SkinMustache to prevent calling buildPersonalUrls multiple times.
For backwards compatibility with user code and gadgets, the new
user-menu portlet uses the same id and classes as the personal
tools, allowing it to serve as a drop-in replacement.
Skins shouldn't output both.
Bug: T266613
Depends-On: Ib4112364c173952eb363e52756f03693a2e03512
Change-Id: Ia1451e3e802441162eecfc5b7f6a7ba2ae72f377
This introduces a utility method in MWDebug, and uses it to clean up
the deprecation mechanism for Skin::setupSkinUserCss().
Bug: T257990
Bug: T267080
Change-Id: I5b07fa82dcc2b0fd112f122e45c9b2562cd09247
Taint check checks for possible security issues by tracking html
escaping and more by using phan.
This slows done the phan-job a bit and requires more ram
Keep the DoubleEscaped issues out to make reviewer easier
Adds suppression for false positives
Adds taint-annotation to help taint-check
Removes suppression for code phan now understand better by the tracking
of keys in taint-check
Fix some small issues by adding int cast or htmlspecialchars calls
Bug: T216348
Bug: T268920
Change-Id: I849ac4f120fd15b483e8939d4db45c98dc351259
It's more easier for every skin to construct this link as
there is no need for error handling if they do that. It will
also eleminates the need for $stylename property which is the
only reason some skins are extending abstract Skin class now.
Bug: T270754
Change-Id: I64be6cbe1742f2f5fbdb5c3c920c9910cfbd8b72
This patch adds a private method and other mechanisms to handle
generation of dismiss button for site notices (which are already
generated by core).
It also adds the $wgDismissableSiteNoticeForAnons global with its
default as set in the DismissableSiteNotice extension. The plan is,
however, to deprecate it later.
Native support will streamline the sitenotice processing and helps
towards more optimum default MediaWiki experience. It will also
eventually obsoletes the need for an extension to provide this crucial
button as well as remove the overhead of managing such extensions.
Bug: T262118
Bug: T259903
Depends-On: Ib80fc24c84eb333daa016c9816fdf91cc60d3983
Change-Id: I276325dc55fd475655e0212fc256b95ebb41b276
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
