aboutsummaryrefslogtreecommitdiffstats
path: root/includes/skins
Commit message (Collapse)AuthorAgeFilesLines
* Use type declaration on undocumented private functionsUmherirrender2025-04-021-3/+3
| | | | Change-Id: I0d8d2237500ed6f18439410c902d47c42e4119bc
* Don't drop fragments in Skin::makeInternalOrExternalUrl()Bartosz Dziewoński2025-03-261-1/+1
| | | | | | | | | | | Skin::makeInternalOrExternalUrl() allowed links to fragments when the input was an external URL, but not when it was an internal page name. This problem was discovered in case of edit tags (T389314), but all callers of this method should benefit from this change. Bug: T389314 Change-Id: I388be52d4274374e5a501fd222bed95f3521e2eb
* Namespace all remaining files in includes/skinJames D. Forrester2025-03-2523-24/+69
| | | | | Bug: T353458 Change-Id: I3e829e35c93bcaae75e401b1801bddf93c0b416c
* Namespace all remaining files in includes/exceptionJames D. Forrester2025-03-251-0/+1
| | | | | | | | | In MediaWiki/Exception, to follow PSR-4 per plural vs. singular (this can be changed later if people really care). Also, move the couple of exceptions in here that were already namespaced in the MW-top-level into the new space. Bug: T353458 Change-Id: I12ed850ae99effb699a6d7ada173f54e72f0570e
* Deprecate OutputPage::showNewSectionLink(), ::forceHideNewSectionLink()C. Scott Ananian2025-03-241-2/+7
| | | | | | | The OutputPage::getOutputFlag(...) method should be used instead. Bug: T301020 Change-Id: I3b5a76d30e88da1f29e50689cfab7d05ff83e43f
* Namespace all remaining files in includes/actionsJames D. Forrester2025-03-191-2/+2
| | | | | Bug: T353458 Change-Id: Id3ca24e22877e544b707a8a527a58e00cc1bc247
* Namespace all remaining files in includes/pageJames D. Forrester2025-03-182-2/+2
| | | | | Bug: T353458 Change-Id: I7a9c74f2106655d41ae029742090253f541bd4a6
* Merge "Update PHPDocs for OutputPage::getIndicators() and related"jenkins-bot2025-03-141-3/+3
|\
| * Update PHPDocs for OutputPage::getIndicators() and relatedthiemowmde2025-03-111-3/+3
| | | | | | | | | | | | | | We can be quite a bit more specific here. It's also pretty important to understand that the strings are actually HTML. Change-Id: I2a8a973a75510ab0fe16b5b5e1eb5fa02e18a114
* | Skins: Limit where Codex message box styles are auto loaded.Jon Robson2025-03-131-16/+5
|/ | | | | | | | | | | | | | | | | | | | | | | | This resolves code added in I7842600b9ee67a304ee8396842a0c2e2e2519e99 to detect pages with unstyled message boxes and to only load the styles for user generated content. The skin automatically adds styles on behalf of community members until better solutions exist for using Codex (and legacy alternatives) in article content. This was also applying unexpectedly for Wikimedia deployed code that was using the Html class without adding appropriate styles. Going forward: * We will no longer load Codex message box styles on behalf of special pages which have made use of the Html class but without adding the style pack. * We will no longer load Codex message box styles on page which do not contain user generated content. * We no longer log warning messages as they sometimes log false positives and the majority of issues have now been fixed. Bug: T375287 Change-Id: Idf242231316b0ef8a82d73eebd40e08198b02ecc
* Split MessageParser out of MessageCacheTim Starling2025-02-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | MessageCache has enough to do without also being a parser. Split a MessageParser class out of MessageCache and make it a service. * MessageCache::parseWithPostprocessing() becomes MessageParser::parse() because every caller wants postprocessing so it makes sense to use the shorter name for this. * MessageCache::parse() becomes MessageParser ::parseWithoutPostprocessing(). I changed the return type from ParserOutput|string to ParserOutput, which is a followup to I8a1fa84e650d920d07d74722d8059d5afeedec6b. Narrowing the return type does not break b/c so it is possible to make this change for both variants. * In the new methods, a null title is always a convenience alias for a placeholder title (Special:Badtitle). This reflects the convention in Parser::setPage(). The old MessageCache::parse() retains its b/c fallback to $wgTitle. MessageCache::transform() had the potential to fall back to the title used in the previous call, a fragile mechanism which I removed without deprecation. * For consistency, allow a string language in all new methods. * In EmailNotification, clean up an early attempt at global state avoidance. Change-Id: I05ab21508d5f8394189fd41ac6a2254ac0e0d785
* Merge "Add support for bottom dock menu"jenkins-bot2025-02-191-0/+2
|\
| * Add support for bottom dock menuJon Robson2025-02-181-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Various extensions are using a menu currently in Vector 2022 To support other skins: primarily Vector legacy and Minerva this should be in core to make it easier for skins to adopt The menu can be extended via mw.util.addPortletLink or hook ``` $wgHooks['SkinTemplateNavigation::Universal'][] = function ( $t, &$s ) { $s['dock-bottom']['test'] = [ 'icon' => 'foo', 'text' => 'foo', 'href' => '/wiki/Foo' ]; }; ``` Bug: T385298 Change-Id: Ibabb872e9f95a0c0d3bfd201b7181e9f3a20399d
* | Limit Codex logging to action and special pagesJon Robson2025-02-121-2/+8
|/ | | | | | | | | | | We've fixed enough issues that we can be begin limiting this logging to special pages and action items. In future once the remaining issues are addressed we can promote this to production warning logs. Bug: T375287 Change-Id: I9cca758d17f6dc0e32651d4b7a1583a8088b2bf3
* Merge "Pass WebRequest to AuthPreserveQueryParams hook handlers"jenkins-bot2025-02-101-1/+1
|\
| * Pass WebRequest to AuthPreserveQueryParams hook handlersGergő Tisza2025-02-071-1/+1
| | | | | | | | Change-Id: I697661fcfd8fd5225d56b9d4ebfb5cae2df6974e
* | Skin: Support responsive footer iconsJon Robson2025-02-081-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows footer icons to declare different images at different media queries via the picture element e.g. $wgFooterIcons['poweredby']['mediawiki']['sources'] = [ [ "media" => "(max-width: 720px)", "srcset" => "https://en.wikipedia.org/static/images/mobile/mediawiki.png", ]; Bug: T384619 Change-Id: Ib325690906bc7fd9c0668cf2f77f0690d826d98e
* | Skins: Scan entire navbar for n-specialpages, not just "navigation"aliu2025-02-061-2/+2
|/ | | | | | | | | | | | Follow up to: I03f818d414 We should scan all sections of sidebar instead of just the "navigation" (default) section. For example, enwiki would likely add the n-specialpages link to the "interaction" (rendered as "contribute") section, and this patch would recognize a link in that section. Previously, they would have to hack the link away by changing MediaWiki:Specialpages-url to "-". Bug: T333211 Change-Id: I5bb74aaa0febbb6329a4f771d05f8eeed4e8ca83
* Merge "Skins: Remove SpecialPages link from toolbox, add to navbar by default"jenkins-bot2025-02-061-50/+99
|\
| * Skins: Remove SpecialPages link from toolbox, add to navbar by defaultaliu2025-02-011-50/+99
| | | | | | | | | | | | | | | | | | | | | | Make the link be in the Navigation sidebar (as the last link) by default by changing the default "sidebar" interface message and adding a new "specialpages-url" interface message. If an existing navigation does not contain the "n-specialpages" item, we append it to the end of navigation. As mentioned in the task, this is done to line up with the other links in the main menu (navigation) vs the toolbox. As that sidebar is specified through the "sidebar" interface message, the only way to add the link to the main menu without setting great new precedent is to change the default interface message. In accordance with existing links in the default sidebar, the link to "Special pages" was specified through a URL interface message formatted the same way as the "Recent changes" entry. The "createSidebarItem" function executes code shared between the addition of n-specialpages and the addition of other sidebar items. Hopefully I got the naming part and the getting-config-and-services part right. This approach requires some user notice, as users should update their MediaWiki:Sidebar to include n-specialpages. I also wonder about the performance footprint, especially that of foreaching the sidebar to find n-specialpages and that of copying over config, services, etc. every time a sidebar item is generated. Bug: T333211 Change-Id: I03f818d414c605a3cc87dfd108a8860a09d41d5f
* | Merge "Make page tabs for redirects link to redirect pages"jenkins-bot2025-02-041-0/+15
|\ \
| * | Make page tabs for redirects link to redirect pagesSaint Johann2025-01-311-0/+15
| | | | | | | | | | | | | | | | | | | | | Page tabs for redirect pages should link with redirect=no when the user is viewing the redirect page itself. Current behaviour makes it impossible to go from history page for a redirect to the redirect without inconvenience. Bug: T5324 Change-Id: I183c50b6feba1bfbde12d4c1634605afdecec5b4
* | | build: Updating mediawiki/mediawiki-codesniffer to 46.0.0libraryupgrader2025-01-311-1/+1
| |/ |/| | | | | Change-Id: I0f8a8cac36015bba52aea3ee2affd92f83d3574a
* | Remove 2-line PHPDocs that just repeat the types from the codethiemowmde2025-01-179-33/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Same as Ia294bf4 did for 1-line comments. This patch removes slightly more complex 2-line PHPDoc comments that don't add any new information to the code, but literally repeat what the code already says. They say "don't document the code, code the documentation", and we are doing this more and more. We just tend to forget to remove the obsolete comments. Note I'm also removing a line of text in a few cases when it's very short and literally says the same as the method name. Again, such comments add zero new information. Change-Id: I01535404bab458c6c47e48e5456403b7a64198ed
* | Remove trivial 1-line PHPDocs that just repeat the codethiemowmde2025-01-1611-45/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | I assume these are all either auto-generated by an IDE or the language-level type declarations have been added later. In any case the comments don't add any new information to what the code already says. This is just extra clutter that makes the code harder to read, I would argue. There are many, many more comments like this. In this patch I intentionally focus on the most trivial 1-line comments. Change-Id: Ia294bf4ce0d8a77036842fe25884bc175c2b0e7d
* | Skin [Breaking change]: Remove ability of skins tolmora2025-01-063-39/+9
| | | | | | | | | | | | | | | | | | | | override makeFooterIcon and getFooterIcons Making Skin::getFooterIcons and ::makeFooterIcon methods final Bug: T318988 Change-Id: Ic50b51b9f707d039784a626da7734acf0bb087c7
* | Merge "skins: Avoid build of mw-editsection-divider when not needed"jenkins-bot2025-01-021-8/+12
|\ \
| * | skins: Avoid build of mw-editsection-divider when not neededUmherirrender2024-11-131-8/+12
| | | | | | | | | | | | | | | | | | | | | When there is only one link for the editsection there is no need to build the not-so-simple mw-editsection-divider span for the implode Change-Id: I9ccefff812ff51297816b3aa8d9cb366f5478bf1
* | | Use latest revision not viewed revision in delete linkPppery2024-12-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | This link is used to check if there's a delete-edit conflict, and intentionally viewing an old revision confuses it unnecessarily. Bug: T382184 Change-Id: I923860ba80920d7821e87e373b8850920ea1634a
* | | Streamline some code related to disabled messagesThiemo Kreuz2024-12-031-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In case a message does fancy stuff with {{#if: and such, we can not (only) use isDisabled(). Some messages are dynamically disabled via parser functions. isDisabled() can't pick this up as it works only on the raw message. However, in some cases we know isDisabled() is good enough. Change-Id: I1d267aed221c74b623c68ac5196ddf1b91a26a0f
* | | Preserve query params on logoutAmmarpad2024-12-011-3/+7
| | | | | | | | | | | | | | | | | | | | | Follow-up: 1092422 (26088e2dfb32a2a9) Bug: T381216 Change-Id: I4d6fa3dd7ba640f1f2fe74b17758e54671d4f63c
* | | Merge "Simplify redundant Message::exists and ::isDisabled"jenkins-bot2024-11-301-2/+1
|\ \ \
| * | | Simplify redundant Message::exists and ::isDisabledthiemowmde2024-11-051-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | isDisabled includes the exists check. Doing both is redundant. Change-Id: I969c65186f12eddd91fc40bd8a1273bfc7f516b9
* | | | Merge "skins: Improve 'returnto' params in login/signup links"jenkins-bot2024-11-222-22/+26
|\ \ \ \ | |_|_|/ |/| | |
| * | | skins: Improve 'returnto' params in login/signup linksBartosz Dziewoński2024-11-222-23/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When linking from Special:UserLogin to CreateAccount (or opposite): In addition to extensions' parameters (T379295), also preserve some core parameters: 'uselang', 'variant', 'display', 'returnto', 'returntoquery', 'returntoanchor' (this list is based on AuthManagerSpecialPage/LoginSignupSpecialPage::getPreservedParams()) Test plan: visit Special:UserLogin with some parameters, verify that the "Create account" link in the personal menu and the "Join {{SITENAME}}" link below the special page form goes to the same URL, preserving the parameters from the list above, but no others. When linking from another page to Special:UserLogin or CreateAccount: Always generate 'returnto' and 'returntoquery' based on all of the provided query parameters, and never copy their existing values. That behavior was added a long time ago to support links from Special:UserLogin to CreateAccount (or opposite) – I tracked this down to 775154ca21 / SVN r53777 – but now we handle this case separately, and copying values of potentially unrelated parameters passed to other special pages seems undesirable. Test plan: visit Special:Preferences and click "Change password" (goes to Special:ChangeCredentials/…?returnto=Special:Preferences). Verify that the "Log out" link on that page will return to Special:ChangeCredentials, and not Special:Preferences. [Repeat both tests with CentralAuth SUL3, and with plain MediaWiki.] Also, move this code inside SkinComponentUtils::getReturnToParam(), which is called in several places. This causes the fix for T379295, and the changes described above, to also apply to the "Log out" link and the login/signup links in the temp user banner on Vector 2022. Bug: T379295 Change-Id: I07ace528a117589645a8e47309c2a9c76cc17b1c
* | | | Article: Add message box styles where neededJon Robson2024-11-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Additional change: * Fix logging to check styles rather than JS modules - it is throwing up lots of false positives Bug: T380547 Bug: T375287 Change-Id: If69d7dc822b4863a9ff229a6ce5b4b94c71299f9
* | | | Merge "Use normal "Log out" link while on Special:Preferences"jenkins-bot2024-11-191-2/+1
|\ \ \ \
| * | | | Use normal "Log out" link while on Special:PreferencesBartosz Dziewoński2024-11-181-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While on Special:Preferences, if you clicked the "Log out" link, it would not suggest returning to Special:Preferences after logging out, unlike on any other page. This was added in SVN r11558 (ff3856aeb4). I don't really see why Special:Preferences should have this unique behavior when other pages that require login don't. Returning to the page seems generally useful to me (e.g. if you notice that you need to switch to another account while performing some office action), so I'd like to remove the special case. Change-Id: Ia43eee3e32726025a1ac5d0f4955f672044cfc10
* | | | | Merge "Clean up old Special:UserLogout GET request anti-preloading hacks"jenkins-bot2024-11-191-2/+0
|\| | | |
| * | | | Clean up old Special:UserLogout GET request anti-preloading hacksBartosz Dziewoński2024-11-191-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Back in the day, when Special:UserLogout would log you out on a GET request, a workaround was implemented so that users of a particular ISP that preloaded GET requests would not immediately become logged out: T19790 (SVN r62967 and r86182 / e3e5cf1bb9 and 12cb599cb7). This is no longer needed now that it requires a POST request, and most of the code was removed in 38bbfde448, but some bits remained. Remove the message 'suspicious-userlogout', now unused. Remove a comment about always generating Special:UserLogout links with an '&' character, now no longer true. Change-Id: Ib39ef71fdfa285e30c8376527cb6c7ea177d46a4
* | | | | Merge "Don't copy POST query params when generating link/redirect URLs"jenkins-bot2024-11-191-1/+1
|\ \ \ \ \ | |_|/ / / |/| | | |
| * | | | Don't copy POST query params when generating link/redirect URLsBartosz Dziewoński2024-11-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use WebRequest::getQueryValues() instead of WebRequest::getValues() whenever the result is used to generate links or redirect URLs, so that only GET query params are copied and not POST params. This is the same change as I53e58c16cd1292d78b5775358fc180901f4ce203 (for T309907), but repeated in several more places. Two of these had bugs filed for it (T152920, T291852), others were as yet undiscovered. Some of my changes have no effect in practice (e.g. when the code is guarded by wasPosted()), but I'm changing them anyway to avoid perpetuating the bad pattern. Bug: T152920 Bug: T291852 Change-Id: I67fbf82a7ec084623595e6aff62c26dbcce8fa4d
* | | | | Merge "[SUL3] skins: Special:(Userlogin|CreateAccount) pages in SUL3 mode"jenkins-bot2024-11-191-0/+8
|\ \ \ \ \ | |_|/ / / |/| | | |
| * | | | [SUL3] skins: Special:(Userlogin|CreateAccount) pages in SUL3 modeDerick Alangi2024-11-181-0/+8
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The patch fixes an issue with URL parameters being wrapped into the returntoquery URL param when a user switches links from "Login" to "Create account" or vice versa when on the shared domain during an authentication flow. This is usually expected behavior but this is a special case handling for URL generation on these specials pages when we're in SUL3 mode. This is because the token param will be wrapped into the returntoquery param in the request URL, so it won't be directly visible in the URL for the authentication providers to perform it's redirects during the authentication flows. So for this special edge cases, we'll invoke the `onAuthPreserveQueryParams` and generate the URL as if we're making a new request everytime. The URL parameters are not only preserved, but they're preserved in such a way that they're not wrapped by `returntoquery` param and hence they'll be visible to the WebRequest object as individual query params for every single request between the signup and login pages. Test plan ========= 0. SUL3 should be enabled 1. Visit any local wiki and click "Login" You'll be redirected to the shared domain's login page at this point 2. While you're on the shared domain, click "Create account" 3. Fill in the form for account creation and submit it. 4. The account should be created and you should be redirected to the local wiki, then logged in successfully. `@note`: You can also follow the steps above to test the reverse when we switch from the "Create account" page to the "Login" page. Without this patch, doing the above steps will not complete the process as you'll be stuck on the shared domain without a redirect for authentication completion because the token wasn't found to continue the authentication flow (account creation). Bug: T379295 Change-Id: Ic63f35640fbf4cbb4ad6196b0f3230e2d8c1ceb2
* / / / Log pages relying on Skin to add Codex stylesJon Robson2024-11-151-1/+11
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This code was added for templates, but it's also applying to MediaWiki code which is using Html::messageBox without the associated requirement around adding styling via ResourceLoader. Apparently various pages are assuming that Codex styles are loaded by default which is incorrect. The skin should not be responsible for adding these styles where needed and when it does it makes the user download duplicate CSS for message box styles so we should remove this as soon as we can. If we remove it, we would likely break rendering on various pages and it's hard to identify code that is using Html::messageBox and not adding Codex style modules without doing so manually, so this logging should help. It works on the assumption that all names will likely feature the string "codex". This should likely help us identify the majority of cases. Bug: T375287 Change-Id: I7842600b9ee67a304ee8396842a0c2e2e2519e99
* | | Merge "Add type hints to detect bool/null message params"jenkins-bot2024-11-142-2/+7
|\ \ \ | |_|/ |/| |
| * | Add type hints to detect bool/null message paramsBartosz Dziewoński2024-11-142-2/+7
| |/ | | | | | | | | | | | | | | | | | | | | | | Add more precise type hints to every method I could find that takes message params as arguments, so that Phan will warn if bool or null is passed, which is deprecated (T378876). Errors found in this repository thanks to these checks are fixed in I286a4a51e879bdf61f65c87dc078621c51045bee. Bug: T378876 Change-Id: I3e0df790ff9db2fa630f82408a7254a359fe61ca
* / Skins: Pass icon data to link data for skinsJon Robson2024-11-043-3/+7
|/ | | | | | | | | | Make sure icons are passed to user-menu When viewing any page with ?useskin=json the items inside data-portlets data-user-menu always have icon = null because of a bug in the method. Add some much needed tests for this component. Change-Id: I727f7635f03481039f228764c048863b791281de
* Revert^2 "Skin: [BREAKING CHANGE] Remove support for rendering outside body ↵Zabe2024-10-303-32/+25
| | | | | | | | | | element" This reverts commit efe9d29472481887883b59114a00d38c15ad38b8. Reason for revert: not the issue Change-Id: Ifef8358462ba29e2b20f24d6e63daa2243d7afee
* Revert "Skin: [BREAKING CHANGE] Remove support for rendering outside body ↵Jforrester2024-10-293-25/+32
| | | | | | | | | | | element" This reverts commit c7656257159a3d85422f4558f5add6df1564f3c3. Reason for revert: Train-breaking deprecation / breaking change, let's revert now and fix later. Bug: T378531 Change-Id: Id05b9f3aa9156473c194ebae2c8c672b0b47b6b5
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-23 05:48:45 +0000