I just caught this slow query on commons - it is using wikiadmin and coming from mwmaint host, so it is from a maintenance script
```
| 294402967 | wikiadmin2023 | 10.64.16.77:52520 | commonswiki | Query | 11314 | Sending data | SELECT /* MediaWiki\Specials\SpecialUncategorizedPages::reallyDoQuery */ page_namespace AS `namespace`,page_title AS `title` FROM `page` LEFT JOIN `categorylinks` ON ((cl_from = page_id)) WHERE cl_from IS NULL AND page_namespace IN (6,0) AND page_is_redirect = 0 ORDER BY page_namespace,page_title LIMIT 5000
cumin2024@db1248.eqiad.wmnet[(none)]> show explain for 294402967;
+------+-------------+---------------+-------+---------------------------------------------+-----------------+---------+--------------------------+----------+--------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+---------------+-------+---------------------------------------------+-----------------+---------+--------------------------+----------+--------------------------------------+
| 1 | SIMPLE | page | range | page_name_title,page_redirect_namespace_len | page_name_title | 4 | NULL | 74007461 | Using where |
| 1 | SIMPLE | categorylinks | ref | PRIMARY | PRIMARY | 4 | commonswiki.page.page_id | 3 | Using where; Using index; Not exists |
+------+-------------+---------------+-------+---------------------------------------------+-----------------+---------+--------------------------+----------+--------------------------------------+
2 rows in set, 1 warning (0.071 sec)
```
This seem to be it:
```
www-data 10323 0.0 0.0 19944 11620 ? Ss Jul01 0:00 /usr/bin/python3 /usr/local/bin/mw-cli-wrapper /usr/local/bin/mwscriptwikiset updateSpecialPages.php s4.dblist
www-data 10412 0.0 0.0 2384 760 ? S Jul01 0:00 /bin/sh -c /usr/local/bin/mwscriptwikiset updateSpecialPages.php s4.dblist
www-data 10414 0.0 0.0 6724 3308 ? S Jul01 0:00 /bin/bash /usr/local/bin/mwscriptwikiset updateSpecialPages.php s4.dblist
www-data 10440 0.0 0.0 6724 3172 ? S Jul01 0:00 /bin/bash /usr/local/bin/mwscript updateSpecialPages.php commonswiki
www-data 10467 0.0 0.1 240056 87572 ? S Jul01 0:00 php /srv/mediawiki-staging/multiversion/MWScript.php updateSpecialPages.php commonswiki
```
Any chances this can be done in a different way?
I argue in https://en.wikipedia.org/wiki/Special:WhatLinksHere/Main_Page and https://en.wikipedia.org/wiki/Special:RecentChangesLinked/Main_Page
{F56165502}
{F56165574}
what is called relevant links, marked as red, is extra as the Talk page link isn't a link of the 'Special:WhatLinksHere' special page itself and those aren't action on the page to show other possible actions on the page while on Special:MovePage https://en.wikipedia.org/wiki/Special:MovePage/User:Sandbox
{F56165683}
It can make more sense (or maybe even not there also) so I say let's remove it from WhatLinksHere and RecentChangesLinked
Back in 2017 in T117794, Special:RevisionDelete was converted to OOUI. It introduced an inconsistency in UI between handling single and multiple revisions:
|Single revision|Multiple revisions|
|--|--|
|{F55895690}|{F55895687}|
When setting visibility for multiple revisions, the user is presented with a triple value radio button option for each flag, of which the first is "do not change". This is because the controls have a one-to-many relationship with the revisions being affected and can't represent a mixture of different states, in contrast to the one-to-one relationship of the flag checkboxes in the UI for affecting single revisions.
As a result, the user needs to visually inspect the state of all the revisions, hold that information in their head, and then set the radio buttons accordingly. This is poor UX - I've certainly made mistakes using it myself on a number of occasions over the years. It also creates the potential for a state setting action to fail entirely, because the user's choice of //Unset// or //Set// on one or more revisions represents the current value of that flag. (This is arguably a bug which should be addressed separately in the meantime.)
The list of revisions and their associated visibility controls should be integrated into a one-to-one relationship, something like this:
|Timestamp|User|Edit summary|Hide text|Hide summary|Hide user/IP|
|----|----|----|----|----|----|
|12:01, 1 April 2024 (diff)|Regular user|Revert vandalism|🟩|🟩|🟩|
|12:00, 1 April 2024 (diff)|Vandal|This wiki has shut down, goodbye!!!|✅|✅|🟩|
|11:55, 1 April 2024 (diff)|Regular user|Update|🟩|🟩|🟩|
I'm using regular checkboxes in this mockup, but a modern UI would make them larger to be easier click targets. The user should be able to click single states to toggle them, or drag across the table to change multiple states in a single motion.
This UI should be used consistently whether modifying multiple or single revisions.
**Steps to replicate the issue** (include links if applicable):
* Visit https://en.wikipedia.org/wiki/Special:AllMessages?vectornightmode=1 with dark mode enabled
**What happens?**:
Color contrast issues due to hardcoded non-standard design tokens in https://gerrit.wikimedia.org/g/mediawiki/core/+/adf0beeaabc7ded0c450abc1000a92eaeb355d16/resources/src/mediawiki.special/special.less#14
{F55350596}
**What should have happened instead?**:
No color contrast issues
**Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
**Steps to replicate the issue** (include links if applicable):
* Visit https://test.wikipedia.org/wiki/Special:ProtectedPages
* Check color contrast on page
**What happens?**:
The element .mw-protectedpages-unknown has a custom style that is not using a design token and is thus not accessible.
{F55350618}
**What should have happened instead?**:
The color here is equvialent to `@color-placeholder` or `@color-disabled` but the text is neither a placeholder or disabled text. Depending on what information it is trying to convey it should use a different token / color.
**Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
The word "Purge" without any context whatsoever looks puzzling and sounds [scary](https://en.wikipedia.org/wiki/Purge), both
1. on [Special:Specialpages](https://en.wikipedia.org/wiki/Special:Specialpages) {F55268633}
2. and on [Special:Purge](https://en.wikipedia.org/wiki/Special:Purge) {F55268499}
I suggest to rename it to something like "Clear page's server cache" or at least "Purge a page" (like other pages: "Edit a page", "Delete a page").
While working on {T362713}, it was noticed that `LoginSignupSpecialPage::getReturnToQueryStringFragment()` is used in some places where `::getPreservedParams()` should be used instead.
Code in the LoginSignupSpecialPage class and possibly other places should be refactored to use `getReturnToQueryStringFragment()` and/or `getPreservedParams()` in the correct places so that extensions such as CentralAuth can hook into that code or code calling those methods to preserve the query params when authentication process is happening.
The goal of this is for extensions to be able to make use of query params (GET params) during the authentication workflow between wikis.
**Steps to replicate the issue** (include links if applicable):
* Visit https://en.wikipedia.org/wiki/Special:WhatLinksHere/Talk_page with night mode enabled
**What happens?**:
{F54691921}
**What should have happened instead?**:
Icon should make use of the Codex mixin instead of OOUI so that it's color is flipped in night theme.
**Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
This should likely be switched to use a Codex icon.
https://gerrit.wikimedia.org/g/mediawiki/core/+/6e4337de93f312dc8ec8da805cf66a7199588308/resources/src/mediawiki.helplink/helplink.less
== QA Results - Beta
| **AC** | **Status** | **Details** |
| ----- | ----- | ----- |
| 1 | ✅ | T366358#9936425 |
== QA Results - Test.wiki
| **AC** | **Status** | **Details** |
| ----- | ----- | ----- |
| 1 | ❌ | T366358#9936425 |
**Steps to replicate the issue** (include links if applicable):
* Look at what links to the technology OKR's in the WMF's annual plan at https://meta.wikimedia.org/wiki/Special:WhatLinksHere/Wikimedia_Foundation_Annual_Plan/2024-2025/Product_%26_Technology_OKRs
* Links from the annual plan pages aren't showing, e.g., those at https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/Goals/Equity#Increasing_growth_in_encyclopedic_content
* These links are going through https://meta.wikimedia.org/wiki/Special:MyLanguage/Wikimedia_Foundation_Annual_Plan/2024-2025/Product_%26_Technology_OKRs#WE2 - so they aren't direct links, but are going through the translations, which may be the cause of this odd behaviour?
**Steps to replicate the issue** (include links if applicable):
* on Wikipedia in the Serbian language, the Statistics page shows a list of members as **Active** users (Users who have performed at least **one action** in the last 30 days) in the number of 1,392 аctive users.
* on Wikimedia Statistics **Active** editors is 380 users (The count of editors with **five or more edits**, including on redirect pages)
* https://sr.wikipedia.org/wiki/Посебно:Статистика
* https://stats.wikimedia.org/#/sr.wikipedia.org/contributing/editors/normal|line|2-year|~total|monthly
**What happens?**:
**What should have happened instead?**:
* on the Serbian language Wikipedia page Statistics are necessary to display **Editors** (Users who have performed at least one action in the last 30 days) in the number of 1,392 editors
* or the Serbian language Wikipedia page Statistics are necessary to display **Active editors** (The count of editors with **five or more edits**, including on redirect pages) in the number of 380 editors
**Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
Currently, you need to click "next" multiple times to view the total number.
{F53989004}
In #cirrussearch interface, there's a "Results number - number of totalNumber" showing the total results found. It'd be beneficial to include this in LinkSearch for consistency and better usability.
{F53989132}
**Feature summary** (what you would like to be able to do and where):
Almost all SpecialPages in MediaWiki display lists as unordered lists. Moste of the times, additional data (next to the pagename) ist displayed. This makes it hard to copy these lists somewhere else.
Therefore I would suggest to use tables as much as possible. Examples are:
* ResentChanges
* List of Redirects
* UserList
but there are many more.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
Copy/Pasting information from MediaWiki without the need to use the API.
**Benefits** (why should this be implemented?):
In case you want to copy/past information from lists in special pages to a spreadsheet or so something else with it, it is hard to do. If it were tables, it would be much easier.
==== Error ====
* mwversion: 1.43.0-wmf.4
* reqId: 6a226ddb-fbbe-4e36-8d11-3fc2762e55a9
* [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2024-05-12T13:19:56.298Z',to:'2024-05-13T13:21:25.616Z'))&_a=(query:(query_string:(query:'reqId:%226a226ddb-fbbe-4e36-8d11-3fc2762e55a9%22'))) | Find reqId in Logstash ]]
```name=normalized_message,lines=10
[{reqId}] {exception_url} PHP Notice: Undefined index: path
```
```name=exception.trace,lines=10
from /srv/mediawiki/php-1.43.0-wmf.4/includes/ExternalLinks/LinkFilter.php(451)
#0 /srv/mediawiki/php-1.43.0-wmf.4/includes/ExternalLinks/LinkFilter.php(451): MWExceptionHandler::handleError(integer, string, string, integer, array)
#1 /srv/mediawiki/php-1.43.0-wmf.4/includes/ExternalLinks/LinkFilter.php(352): MediaWiki\ExternalLinks\LinkFilter::makeLikeArray(string, string)
#2 /srv/mediawiki/php-1.43.0-wmf.4/includes/specials/SpecialLinkSearch.php(199): MediaWiki\ExternalLinks\LinkFilter::getQueryConditions(string, array)
#3 /srv/mediawiki/php-1.43.0-wmf.4/includes/specialpage/QueryPage.php(564): MediaWiki\Specials\SpecialLinkSearch->getQueryInfo()
#4 /srv/mediawiki/php-1.43.0-wmf.4/includes/specialpage/QueryPage.php(779): MediaWiki\SpecialPage\QueryPage->reallyDoQuery(integer, integer)
#5 /srv/mediawiki/php-1.43.0-wmf.4/includes/specials/SpecialLinkSearch.php(158): MediaWiki\SpecialPage\QueryPage->execute(string)
#6 /srv/mediawiki/php-1.43.0-wmf.4/includes/specialpage/SpecialPage.php(719): MediaWiki\Specials\SpecialLinkSearch->execute(string)
#7 /srv/mediawiki/php-1.43.0-wmf.4/includes/specialpage/SpecialPageFactory.php(1672): MediaWiki\SpecialPage\SpecialPage->run(string)
#8 /srv/mediawiki/php-1.43.0-wmf.4/includes/actions/ActionEntryPoint.php(502): MediaWiki\SpecialPage\SpecialPageFactory->executePath(string, MediaWiki\Context\RequestContext)
#9 /srv/mediawiki/php-1.43.0-wmf.4/includes/actions/ActionEntryPoint.php(145): MediaWiki\Actions\ActionEntryPoint->performRequest()
#10 /srv/mediawiki/php-1.43.0-wmf.4/includes/MediaWikiEntryPoint.php(199): MediaWiki\Actions\ActionEntryPoint->execute()
#11 /srv/mediawiki/php-1.43.0-wmf.4/index.php(58): MediaWiki\MediaWikiEntryPoint->run()
#12 /srv/mediawiki/w/index.php(3): require(string)
#13 {main}
```
==== Impact ====
==== Notes ====
Note that the link being searched for, `news://comp.os.vms`, is indeed lacking a path component. (As far as I can tell, [searching for https://example.com](https://en.wikipedia.org/wiki/Special:LinkSearch/https://example.com) is not affected, so this might be limited to non-HTTP(s) URL schemes.)
**Feature summary** (what you would like to be able to do and where):
A special page to create a batch job which does the similar thing to [[ https://www.mediawiki.org/wiki/Manual:RollbackEdits.php | RollbackEdits.php ]] .
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
A spam user can make massive edits. If other technics (rate limit, AbuseFilter, etc.) failed to prevent it, there is no direct way to revert all the edits, so that admin should use a 3rd party script or write a new one.
**Benefits** (why should this be implemented?):
The maintenance script is useful, but it is hard to run it for a non-technical administrator.
3rd party scripts are also hard to set up for non-technicals.
This is closely related to, but distinct from (at present) {T324134}.
As discussed there, despite thanks from Special:Thanks being tied to revisions, the only way a user can see the ones they've received in full detail is as entries in Special:Notifications, which also can't be filtered by type (see T162930, but originally raised as far back as 2013 in T49093). Special:Log/thanks doesn't show the details of what a user has been thanked for, even in the case of thanks given to the current user (see T51087, also from 2013). As a result, thanks are very obscure once time has passed.
I propose that in addition to the communication improvements proposed at the above task, when logged in and viewing a revision for which they have been thanked, a user is informed of it.
Potential wording for old revision notice at `?title=...&oldid=...` (note: "you" added for improved distinction from logged out view):
> ⚠️ This is an [[https://en.wikipedia.org/wiki/Help:Page_history | old revision]] of this page, as edited by you, **Username** (talk | contribs) at 12:00, 01 January 2024 (//Edit summary//). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
> (diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)
> 🌟 **Username** thanked you for this edit at 12:30, 01 January 2024.
And at `?title=...&oldid=prev&diff=...`:
> **Revision as of 12:00, 01 January 2024** (edit) (undo)
> You, **Username** (talk | contribs)
> //Edit summary//
> [← Previous edit / Next edit →]
> 🌟 **Username** thanked you for this edit at 12:30, 01 January 2024.
In the case of multiple users sending thanks for the same revision, something like:
> You were thanked for this edit by:
> 🌟 **Username 1** at 12:30, 01 January 2024
> 🌟 **Username 2** at 13:30, 01 January 2024.
I don't know how common multiple thanks are, but perhaps past a certain number the list should collapse.
> You were thanked for this edit by 5 people. [Show]
Not everyone may wish to see this information while looking at page history, so I would also suggest that a feature opt-out for it be added to Special:Preferences.
==== Error ====
* service.version: 1.43.0-wmf.4
* trace.id: 9fc4aa51-1523-4205-9802-f043fecf7751
* [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2024-05-08T15:28:17.267Z',to:'2024-05-09T15:34:12.737Z'))&_a=(query:(query_string:(query:'reqId:%229fc4aa51-1523-4205-9802-f043fecf7751%22'))) | Find trace.id in Logstash ]]
```name=labels.normalized_message,lines=10
[{reqId}] {exception_url} Wikimedia\Rdbms\DBQueryError: Error 1066: Not unique table/alias: 'templatelinks'
Function: MediaWiki\Specials\SpecialExport::getLinks
Query: SELECT tl_target_id,lt_namespace,lt_title,lt_namespace AS `namespace`,lt_title AS `t
```
```name=error.stack_trace,lines=10
from /srv/mediawiki/php-1.43.0-wmf.4/includes/libs/rdbms/database/Database.php(1203)
#0 /srv/mediawiki/php-1.43.0-wmf.4/includes/libs/rdbms/database/Database.php(1187): Wikimedia\Rdbms\Database->getQueryException(string, integer, string, string)
#1 /srv/mediawiki/php-1.43.0-wmf.4/includes/libs/rdbms/database/Database.php(1161): Wikimedia\Rdbms\Database->getQueryExceptionAndLog(string, integer, string, string)
#2 /srv/mediawiki/php-1.43.0-wmf.4/includes/libs/rdbms/database/Database.php(652): Wikimedia\Rdbms\Database->reportQueryError(string, integer, string, string, boolean)
#3 /srv/mediawiki/php-1.43.0-wmf.4/includes/libs/rdbms/database/Database.php(1350): Wikimedia\Rdbms\Database->query(Wikimedia\Rdbms\Query, string)
#4 /srv/mediawiki/php-1.43.0-wmf.4/includes/libs/rdbms/database/DBConnRef.php(126): Wikimedia\Rdbms\Database->select(array, array, array, string, array, array)
#5 /srv/mediawiki/php-1.43.0-wmf.4/includes/libs/rdbms/database/DBConnRef.php(358): Wikimedia\Rdbms\DBConnRef->__call(string, array)
#6 /srv/mediawiki/php-1.43.0-wmf.4/includes/libs/rdbms/querybuilder/SelectQueryBuilder.php(730): Wikimedia\Rdbms\DBConnRef->select(array, array, array, string, array, array)
#7 /srv/mediawiki/php-1.43.0-wmf.4/includes/specials/SpecialExport.php(606): Wikimedia\Rdbms\SelectQueryBuilder->fetchResultSet()
#8 /srv/mediawiki/php-1.43.0-wmf.4/includes/specials/SpecialExport.php(517): MediaWiki\Specials\SpecialExport->getLinks(array, array, Wikimedia\Rdbms\SelectQueryBuilder)
#9 /srv/mediawiki/php-1.43.0-wmf.4/includes/specials/SpecialExport.php(403): MediaWiki\Specials\SpecialExport->getTemplates(array, array)
#10 /srv/mediawiki/php-1.43.0-wmf.4/includes/specials/SpecialExport.php(230): MediaWiki\Specials\SpecialExport->doExport(string, integer, boolean, boolean)
#11 /srv/mediawiki/php-1.43.0-wmf.4/includes/specialpage/SpecialPage.php(719): MediaWiki\Specials\SpecialExport->execute(NULL)
#12 /srv/mediawiki/php-1.43.0-wmf.4/includes/specialpage/SpecialPageFactory.php(1672): MediaWiki\SpecialPage\SpecialPage->run(NULL)
#13 /srv/mediawiki/php-1.43.0-wmf.4/includes/actions/ActionEntryPoint.php(502): MediaWiki\SpecialPage\SpecialPageFactory->executePath(string, MediaWiki\Context\RequestContext)
#14 /srv/mediawiki/php-1.43.0-wmf.4/includes/actions/ActionEntryPoint.php(145): MediaWiki\Actions\ActionEntryPoint->performRequest()
#15 /srv/mediawiki/php-1.43.0-wmf.4/includes/MediaWikiEntryPoint.php(199): MediaWiki\Actions\ActionEntryPoint->execute()
#16 /srv/mediawiki/php-1.43.0-wmf.4/index.php(58): MediaWiki\MediaWikiEntryPoint->run()
#17 /srv/mediawiki/w/index.php(3): require(string)
#18 {main}
```
==== Notes ====
* Started to pick up when 1.43.0-wmf.4 rolled out to group1 wikis
* New error in 1.43.0-wmf.4
* Happening across group1 wikis
**Steps to replicate the issue** (include links if applicable):
Go to https://www.mediawiki.org/wiki/Special:Version
**What should have happened instead?**:
Tables with multiple captions should be separated and every table should be given its own `<caption>`:
```lang=diff
- <tr><th colspan="5" id="sv-credits-specialpage">Special pages</th></tr>
+ <caption id="sv-credits-specialpage">Special pages</caption>
```
(`id` might also be moved to the `<table>` tag for simplicity)
```lang=diff
- <tr class="sv-space"><td colspan="5"></td></tr>
+ </table>
+ <table class="…">
```
This might introduce a small misalignment between the nearby tables but, frankly, that is less of an issue than a WCAG violation.
Another good thing would be to add `scope="col"` on all table headers remaining:
```lang=diff
- <th class="mw-version-ext-col-label">Extension</th>
+ <th scope="col" class="mw-version-ext-col-label">Extension</th>
```
Maybe upon a closer review from other accessibility-minded people there might be other issues.
**Other information** (browser name/version, screenshots, etc.):
Prompted by reading a comment in {T363726} and looking into the code.
==== Error ====
* service.version: 1.43.0-wmf.2
* trace.id: 30c1ecff-b659-4f5a-9c9b-21f72f61ded2
* [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2024-04-24T11:52:12.614Z',to:'2024-04-25T15:14:34.782Z'))&_a=(query:(query_string:(query:'reqId:%2230c1ecff-b659-4f5a-9c9b-21f72f61ded2%22'))) | Find trace.id in Logstash ]]
```name=labels.normalized_message,lines=10
[{reqId}] {exception_url} InvalidArgumentException: $text must be a string
```
```name=error.stack_trace,lines=10
from /srv/mediawiki/php-1.43.0-wmf.2/includes/language/RawMessage.php(56)
#0 /srv/mediawiki/php-1.43.0-wmf.2/includes/specials/SpecialVersion.php(430): MediaWiki\Language\RawMessage->__construct(NULL)
#1 /srv/mediawiki/php-1.43.0-wmf.2/includes/specials/SpecialVersion.php(236): MediaWiki\Specials\SpecialVersion->softwareInformation()
#2 /srv/mediawiki/php-1.43.0-wmf.2/includes/specialpage/SpecialPage.php(718): MediaWiki\Specials\SpecialVersion->execute(NULL)
#3 /srv/mediawiki/php-1.43.0-wmf.2/includes/specialpage/SpecialPageFactory.php(1672): MediaWiki\SpecialPage\SpecialPage->run(NULL)
#4 /srv/mediawiki/php-1.43.0-wmf.2/includes/actions/ActionEntryPoint.php(504): MediaWiki\SpecialPage\SpecialPageFactory->executePath(string, MediaWiki\Context\RequestContext)
#5 /srv/mediawiki/php-1.43.0-wmf.2/includes/actions/ActionEntryPoint.php(145): MediaWiki\Actions\ActionEntryPoint->performRequest()
#6 /srv/mediawiki/php-1.43.0-wmf.2/includes/MediaWikiEntryPoint.php(199): MediaWiki\Actions\ActionEntryPoint->execute()
#7 /srv/mediawiki/php-1.43.0-wmf.2/index.php(58): MediaWiki\MediaWikiEntryPoint->run()
#8 /srv/mediawiki/w/index.php(3): require(string)
#9 {main}
```
==== Notes ====
* Happening since 1.42.0-wmf.26
* GET requests to Special:Version on different languages
* Happening at a low rate
* Couldn't figure out the magic to reproduce this error, logged in, logged out, different languages
**Feature summary**:
Special:AllPages (Special:Index in French) has a pure alphabetical order in which "n11" would be sorted after "n1" and before "n2".
Adding natural sort order to Special:AllPages in order to get in the order "n1", "n2", "n11".
See [[https://www.php.net/manual/en/function.natsort.php | natsort.php]].
**Use case(s)**:
For instance [[https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:AbuseFilter/Messages_d%27avertissement | Wikipédia:AbuseFilter/Messages d'avertissement]] includes {{Spécial:Index/MediaWiki:Abusefilter-warning}}.
Would it be possible to get `{{Spécial:Index/MediaWiki:Abusefilter-warning|sort=natsort}}` ?
**Benefits**:
# More human-friendly.
**Feature summary** (what you would like to be able to do and where):
When I open the //Search for contribution//s box ([[ https://hu.wikipedia.org/w/index.php?title=Speci%C3%A1lis%3ASzerkeszt%C5%91+k%C3%B6zrem%C5%B1k%C3%B6d%C3%A9sei&target=Bin%C3%A1ris&uselang=en&limit=500 | e.g. here]]), there is an //Only show edits that are latest revisions// checkbox. I would like to revert it, and also have an //Only show edits that are NOT latest revisions.//
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
I regularly check my own contributions as well as the contributions of my bot. I want to know when someone corrects my edit.
**Benefits** (why should this be implemented?):
One can learn from modifications after his/her edits. When we want to conform users, it is also useful to see their edits that had to be corrected by a more experienced user.
https://vote.wikimedia.org/wiki/MediaWiki:Login
{F42974554 size=full}
{F42974555 size=full}
{F42974556 size=full}
```lang=html
<li><a href="/wiki/Special:UserLogin" title="Special:UserLogin"> </a></li>
```
`Special:EmailUser` errors out when viewing the page if the current user has email confirmed but does not have the necessary user right to use the page.
This seems to be because the code in `SpecialEmailUser::execute` uses a switch to find the permission error message and then display the appropriate message. However, the message key used to indicate a permission error changed from `badaccess` to `badaccess-group0` and `badaccess-groups`.
====Steps to replicate the issue
# Add `$wgRevokePermissions['user']['sendemail'] = true;` to LocalSettings.php
# Log into an account with a confirmed email address
# Load `Special:EmailUser`
**What happens?**:
The page errors out with the following exception:
```
[181e166129cbb5173a2c2054] /wiki/Special:EmailUser InvalidArgumentException: MediaWiki\Message\Message::newFromSpecifier: invalid argument type NULL
Backtrace:
from /var/www/html/w/includes/Message/Message.php(467)
#0 /var/www/html/w/includes/GlobalFunctions.php(906): MediaWiki\Message\Message::newFromSpecifier()
#1 /var/www/html/w/includes/exception/ErrorPageError.php(67): wfMessage()
#2 /var/www/html/w/includes/exception/ErrorPageError.php(53): ErrorPageError->getMessageObject()
#3 /var/www/html/w/includes/specials/SpecialEmailUser.php(186): ErrorPageError->__construct()
#4 /var/www/html/w/includes/specialpage/SpecialPage.php(720): MediaWiki\Specials\SpecialEmailUser->execute()
#5 /var/www/html/w/includes/specialpage/SpecialPageFactory.php(1651): MediaWiki\SpecialPage\SpecialPage->run()
#6 /var/www/html/w/includes/actions/ActionEntryPoint.php(504): MediaWiki\SpecialPage\SpecialPageFactory->executePath()
#7 /var/www/html/w/includes/actions/ActionEntryPoint.php(145): MediaWiki\Actions\ActionEntryPoint->performRequest()
#8 /var/www/html/w/includes/MediaWikiEntryPoint.php(199): MediaWiki\Actions\ActionEntryPoint->execute()
#9 /var/www/html/w/index.php(58): MediaWiki\MediaWikiEntryPoint->run()
#10 {main}
```
**What should have happened instead?**:
The code should have displayed the `PermissionsError` error page.
====Software version
MediaWiki 1.42.0-alpha (1db03e0) 15:03, 20 March 2024
====Screenshot
{F42942663}
Focusing on metrics:
* `"timing.login.ui.{$this->authAction}"`
Follow the migration process as outlined below.
Secure/Conduct a code review.
Deploy the changes to production via the train (https://wikitech.wikimedia.org/wiki/Deployments/Train).
Verify that the changes have been successfully implemented.
Update the dashboard by replacing the old Graphite metric with the new Prometheus metric.
Please follow the guidelines and standards outlined in the provided documentation:
https://www.mediawiki.org/wiki/Manual:Stats for detailed guidance on the conversion process.
https://drive.google.com/file/d/12yQEuOapkML1vb9MgCaX1QzbLBdXE6X2/view for a video tutorial on the conversion process.
https://docs.google.com/presentation/d/1SZWf_D3mWNX-XHN8PHYI84LDZr6GUQC2AMhZ9mQXCI0/edit#slide=id.g2795460c956_0_23 for slides on the best practices for converting metrics to statslib.
The special page at [[Special:Redirect]] allows users to look up pages by various ID numbers or names. So, if you know a page ID number is (for example) 5043734, you can go to that page by entering the number and smashing the button.
This has nothing to do with redirects, which involve, er, //redirecting// a user from one page they selected to another page which is usually synonymous. You know how those work -- they're a key feature.
To avoid confusion, I suggest it'd be best to rename [[special:redirect]] to something more appropriate, like [[special:LookUp]] and alias [[special:redirect]] to that.
The system messages at [[MediaWiki:Redirect]] and [[MediaWiki:Redirect-summary]] need changing as well, and renaming to avoid confusion might be a good idea. Suggest [[MediaWiki:Lookup]] and [[MediaWiki:Lookup-summary]].
I suggest the content of [[MediaWiki:Lookup]] should be `Look up page by ID` rather than mentioning the word //redirect//. The [[MediaWiki:Lookup-summary]] needs replacing with something that doesn't mention //redirect// as well.
[[ https://www.mediawiki.org/wiki/Special:login | Special:login ]] is offering a [[ https://www.mediawiki.org/wiki/MediaWiki:Userlogin-helplink2 | linktext ]] for help page.
Link target (currently [[ https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Logging_in | mw:Special:MyLanguage/Help:Logging_in ]]) should be configurable as well, maintaining current default, permitting local help page.
**Feature summary** (what you would like to be able to do and where):
Have numbers next to images on Special:ListFiles
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
Visit some long page like
https://commons.wikimedia.org/wiki/Special:ListFiles?limit=500&user=Jidanni&ilshowall=1
Scroll down.
Picture after picture.
**Benefits** (why should this be implemented?):
Wouldn't it be great to have numbers along the side,
so we can tell if we are at the 247th image or the 479th image?
Yes, tomorrow the user might add another picture, and the numbers will
all change.
But at least it would allow one to not just guess where we were relying
on sidebars states.
They could even be an optional column, that appears only if you click
some checkbox.
Currently, you can open [[ https://meta.wikimedia.org/wiki/Special:Redirect | Special:Redirect ]] and use the submit (“go”) button, and it’ll effectively reload the page and otherwise do nothing. It would be nicer to indicate to users that the value field is required.
**Feature summary** (what you would like to be able to do and where):
When transcluding a page in the Special namespace, I want to be able to have access to the actual code transcluded. I know it's not in wikitext, but as for an enduser, it doesn't matter to me – I want to be able to get the output as wikitext and then process it. Maybe some additional parameters could be introduced, like `wikitext=1` or `plain=1`. E.g.:
```
{{#tag: pre | {{Special:ListUsers/sysop|wikitext=1}} }}
```
⬇️
```
<pre>
* [[User:Example1|Example1]]
* [[User:Example2|Example2]]
...
</pre>
```
**Use cases** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
* Each time a major flag is granted or revoked on every project, people manually update the user list on all relevant Project namespace pages and templates. All this should be updated automatically from a [[https://en.wikipedia.org/wiki/Single_source_of_truth|single source of truth]]. Just think of the amount of effort that will be saved!
* Currently there is a page https://en.wikipedia.org/wiki/Project:GUS2Wiki that is updated by a bot that just copypastes the contents of [[https://en.wikipedia.org/wiki/Special:GadgetUsage]]. Its content are then used to display the number of the gadget's users in gadget headers like [[https://en.wikipedia.org/wiki/MediaWiki:Gadget-HotCat.js|this]]:{F42012165}
Updating a page by bot gives an added benefit of keeping a history of gadget usage. But you can solve the task of showing the number of gadget users without running such a bot.
**See also**
* {T354890}
* {T85419}
**Feature summary** (what you would like to be able to do and where):
I can already use Special:Contributions to check all edits made by some IP range (e.g. 8.8.0.0/16). But if I want to check the list of deleted edits, I can do it only for single IP adresses. This is infeasible when fighting some LTAs that come from ranges. Special:DeletedContributions/8.8.0.0/16 would return nothing, regardless of whether there were any deleted edits from that range.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
Admin who wants to make a range-block may want to ensure how many false-positives may be affected. Thus, he or she could want to check the amount of deleted edits from the range to be blocked. They are at the moment unable to do so.
**Benefits** (why should this be implemented?):
When fighting a vandal that comes from a variable IP (i.e. their edits come from IP range and not single address), it's possible to list the contributions made from a given IP range (eg. 8.8.0.0/16). However, if a vandal tries to evade our control, they may do good-faith edits and create ill pages. This gives admins an impression that the range cannot be blocked straightforward because of significant number of good edits while being unable to check how many deleted edits were done from that range.
**Steps to replicate the issue** (include links if applicable):
* Go to https://he.wikipedia.org/wiki/Special:Version
**What happens?**:
The date part of the MediaWiki version appears in the wrong order, from left to right.
**What should have happened instead?**:
In Hebrew, the date must appear from right to left.
**Other information** (browser name/version, screenshots, etc.):
This happens because the <td>s are forced to LTR, which generally makes sense because they are mostly numbers and other technical info. Even the numbers are not localized to local numerals in languages that use them, such as Burmese (my), and that, too, is fine. The MediaWiki version //date//, however, is written in the user language ($wgLang), but lang and dir are not explicitly set.
I can think of two solutions:
# Put the date in a <span> with correct dir and lang attributes.
# Use a universal generic date format in all the languages, for example YYYY-MM-DD, under the rationale that Special:Version provides rather technical information and full localization is perhaps not so necessary. This was actually suggested in the discussion of T40783#468770, which is the bug because of which the date was added, but eventually a localized date was used. Even though I usually support localizing everything that can be localized, in this case it's perhaps better to use YYYY-MM-DD.
==== Error ====
* mwversion: 1.42.0-wmf.16
* reqId: f1e01ab1-e951-4515-91a4-9106dfbe671d
* [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2024-02-05T06:46:57.508Z',to:'2024-02-07T06:46:57.508Z'))&_a=(query:(query_string:(query:'reqId:%22f1e01ab1-e951-4515-91a4-9106dfbe671d%22'))) | Find reqId in Logstash ]]
```name=normalized_message,lines=10
[{reqId}] {exception_url} PHP Deprecated: Caller from MediaWiki\User\TalkPageNotificationManager::dbCheckNewUserMessages ignored an error originally raised from MediaWiki\Pager\IndexPager::buildQueryInfo (MediaWiki\Pager\LogPager): [1969] Query executio
```
```name=exception.trace,lines=10
from /srv/mediawiki/php-1.42.0-wmf.16/includes/debug/MWDebug.php(378)
#0 [internal function]: MWExceptionHandler::handleError(integer, string, string, integer, array)
#1 /srv/mediawiki/php-1.42.0-wmf.16/includes/debug/MWDebug.php(378): trigger_error(string, integer)
#2 /srv/mediawiki/php-1.42.0-wmf.16/includes/db/MWLBFactory.php(470): MWDebug::sendRawDeprecated(string, boolean, string)
#3 [internal function]: MWLBFactory::logDeprecation(string)
#4 /srv/mediawiki/php-1.42.0-wmf.16/includes/libs/rdbms/database/TransactionManager.php(217): call_user_func(array, string)
#5 /srv/mediawiki/php-1.42.0-wmf.16/includes/libs/rdbms/database/Database.php(992): Wikimedia\Rdbms\TransactionManager->assertTransactionStatus(Wikimedia\Rdbms\DatabaseMySQL, array, string)
#6 /srv/mediawiki/php-1.42.0-wmf.16/includes/libs/rdbms/database/Database.php(640): Wikimedia\Rdbms\Database->assertQueryIsCurrentlyAllowed(string, string)
#7 /srv/mediawiki/php-1.42.0-wmf.16/includes/libs/rdbms/database/Database.php(1350): Wikimedia\Rdbms\Database->query(Wikimedia\Rdbms\Query, string)
#8 /srv/mediawiki/php-1.42.0-wmf.16/includes/libs/rdbms/database/Database.php(1301): Wikimedia\Rdbms\Database->select(array, string, array, string, array, array)
#9 /srv/mediawiki/php-1.42.0-wmf.16/includes/libs/rdbms/database/DBConnRef.php(119): Wikimedia\Rdbms\Database->selectField(array, string, array, string, array, array)
#10 /srv/mediawiki/php-1.42.0-wmf.16/includes/libs/rdbms/database/DBConnRef.php(338): Wikimedia\Rdbms\DBConnRef->__call(string, array)
#11 /srv/mediawiki/php-1.42.0-wmf.16/includes/libs/rdbms/querybuilder/SelectQueryBuilder.php(741): Wikimedia\Rdbms\DBConnRef->selectField(array, string, array, string, array, array)
#12 /srv/mediawiki/php-1.42.0-wmf.16/includes/user/TalkPageNotificationManager.php(259): Wikimedia\Rdbms\SelectQueryBuilder->fetchField()
#13 /srv/mediawiki/php-1.42.0-wmf.16/includes/user/TalkPageNotificationManager.php(95): MediaWiki\User\TalkPageNotificationManager->dbCheckNewUserMessages(MediaWiki\User\User)
#14 /srv/mediawiki/php-1.42.0-wmf.16/extensions/Echo/includes/Hooks.php(969): MediaWiki\User\TalkPageNotificationManager->userHasNewMessages(MediaWiki\User\User)
#15 /srv/mediawiki/php-1.42.0-wmf.16/extensions/Echo/includes/Hooks.php(867): MediaWiki\Extension\Notifications\Hooks->shouldDisplayTalkAlert(MediaWiki\User\User, MediaWiki\Title\Title)
#16 /srv/mediawiki/php-1.42.0-wmf.16/includes/HookContainer/HookContainer.php(159): MediaWiki\Extension\Notifications\Hooks->onBeforePageDisplay(MediaWiki\Output\OutputPage, MediaWiki\Skins\Vector\SkinVectorLegacy)
#17 /srv/mediawiki/php-1.42.0-wmf.16/includes/HookContainer/HookRunner.php(942): MediaWiki\HookContainer\HookContainer->run(string, array, array)
#18 /srv/mediawiki/php-1.42.0-wmf.16/includes/Output/OutputPage.php(3010): MediaWiki\HookContainer\HookRunner->onBeforePageDisplay(MediaWiki\Output\OutputPage, MediaWiki\Skins\Vector\SkinVectorLegacy)
#19 /srv/mediawiki/php-1.42.0-wmf.16/includes/exception/MWExceptionRenderer.php(188): MediaWiki\Output\OutputPage->output()
#20 /srv/mediawiki/php-1.42.0-wmf.16/includes/exception/MWExceptionRenderer.php(105): MWExceptionRenderer::reportHTML(Wikimedia\Rdbms\DBQueryTimeoutError)
#21 /srv/mediawiki/php-1.42.0-wmf.16/includes/exception/MWExceptionHandler.php(133): MWExceptionRenderer::output(Wikimedia\Rdbms\DBQueryTimeoutError, integer)
#22 /srv/mediawiki/php-1.42.0-wmf.16/includes/exception/MWExceptionHandler.php(237): MWExceptionHandler::report(Wikimedia\Rdbms\DBQueryTimeoutError)
#23 /srv/mediawiki/php-1.42.0-wmf.16/includes/MediaWikiEntryPoint.php(206): MWExceptionHandler::handleException(Wikimedia\Rdbms\DBQueryTimeoutError, string)
#24 /srv/mediawiki/php-1.42.0-wmf.16/includes/actions/ActionEntryPoint.php(90): MediaWiki\MediaWikiEntryPoint->handleTopLevelError(Wikimedia\Rdbms\DBQueryTimeoutError)
#25 /srv/mediawiki/php-1.42.0-wmf.16/includes/MediaWikiEntryPoint.php(190): MediaWiki\Actions\ActionEntryPoint->handleTopLevelError(Wikimedia\Rdbms\DBQueryTimeoutError)
#26 /srv/mediawiki/php-1.42.0-wmf.16/index.php(55): MediaWiki\MediaWikiEntryPoint->run()
#27 /srv/mediawiki/w/index.php(3): require(string)
#28 {main}
```
==== Impact ====
==== Notes ====
`SpecialMute::getFormFields` checks for whether a user has an email address attached to their account. However, this check calls `User::getEmailAuthenticationTimestamp` which is only applicable if the wiki has email authentication enabled.
====Steps to replicate the issue
# Set-up a wiki with `$wgEmailAuthentication = false;`
# Add an email to your account
# Load `Special:Mute`
**What happens?**:
The following error is displayed:
{F41781591}
**What should have happened instead?**:
The check should ignore the lack of email confirmation timestamp as `$wgEmailAuthentication` is set to `false`, and the `Special:Mute` page should be displayed
====Software version
MediaWiki 1.42.0-alpha (852bb4f) 05:58, 5 February 2024
**Steps to replicate the issue** (include links if applicable):
* Go to [[en:Special:Version]]
* Look at section "Other" https://en.wikipedia.org/wiki/Special:Version#sv-credits-other
**What happens?**:
You will see that the table is mostly alphabetically sorted by extension names. But extension "Machine Learning Platform" is sorted between "OAuth" and "PageViewInfo".
Changing user language you will see more examples of extensions not in alphabetical order, since some extensions have translated names but are sorted by the English names. (in German: https://en.wikipedia.org/wiki/Special:Version?uselang=de#sv-credits-other)
**What should have happened instead?**:
Either the table should be sorted alphabetically by the displayed/translated names.
Or the original names used for sorting should be displayed in some way.
==== Error ====
* mwversion: 1.42.0-wmf.16
* reqId: 55c259cf-7d11-4774-b591-61d4c558cadb
* [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2024-01-30T21:44:49.322Z',to:'2024-01-31T21:50:19.208Z'))&_a=(query:(query_string:(query:'reqId:%2255c259cf-7d11-4774-b591-61d4c558cadb%22'))) | Find reqId in Logstash ]]
```name=normalized_message,lines=10
[{reqId}] {exception_url} PHP Warning: Comment text should not be null! [Called from MediaWiki\CommentStore\CommentStoreComment::__construct in /srv/mediawiki/php-1.42.0-wmf.16/includes/CommentStore/CommentStoreComment.php at line 61]
```
```name=exception.trace,lines=10
from /srv/mediawiki/php-1.42.0-wmf.16/includes/debug/MWDebug.php(491)
#0 [internal function]: MWExceptionHandler::handleError(integer, string, string, integer, array)
#1 /srv/mediawiki/php-1.42.0-wmf.16/includes/debug/MWDebug.php(491): trigger_error(string, integer)
#2 /srv/mediawiki/php-1.42.0-wmf.16/includes/debug/MWDebug.php(202): MWDebug::sendMessage(string, string, integer)
#3 /srv/mediawiki/php-1.42.0-wmf.16/includes/GlobalFunctions.php(826): MWDebug::warning(string, integer, integer, string)
#4 /srv/mediawiki/php-1.42.0-wmf.16/includes/CommentStore/CommentStoreComment.php(61): wfLogWarning(string)
#5 /srv/mediawiki/php-1.42.0-wmf.16/includes/CommentStore/CommentStore.php(204): MediaWiki\CommentStore\CommentStoreComment->__construct(NULL, NULL, NULL, NULL)
#6 /srv/mediawiki/php-1.42.0-wmf.16/includes/CommentStore/CommentStore.php(229): MediaWiki\CommentStore\CommentStore->getCommentInternal(NULL, string, array, boolean)
#7 /srv/mediawiki/php-1.42.0-wmf.16/includes/CommentFormatter/RowCommentIterator.php(114): MediaWiki\CommentStore\CommentStore->getComment(string, stdClass)
#8 /srv/mediawiki/php-1.42.0-wmf.16/includes/CommentFormatter/CommentFormatter.php(318): MediaWiki\CommentFormatter\RowCommentIterator->current()
#9 /srv/mediawiki/php-1.42.0-wmf.16/includes/CommentFormatter/CommentBatch.php(190): MediaWiki\CommentFormatter\CommentFormatter->formatItemsInternal(MediaWiki\CommentFormatter\RowCommentIterator, NULL, NULL, NULL, NULL, boolean, boolean)
#10 /srv/mediawiki/php-1.42.0-wmf.16/includes/CommentFormatter/RowCommentFormatter.php(86): MediaWiki\CommentFormatter\CommentBatch->execute()
#11 /srv/mediawiki/php-1.42.0-wmf.16/includes/specials/pagers/ProtectedPagesPager.php(141): MediaWiki\CommentFormatter\RowCommentFormatter->formatRows(Wikimedia\Rdbms\MysqliResultWrapper, string)
#12 /srv/mediawiki/php-1.42.0-wmf.16/includes/pager/IndexPager.php(297): MediaWiki\Pager\ProtectedPagesPager->preprocessResults(Wikimedia\Rdbms\MysqliResultWrapper)
#13 /srv/mediawiki/php-1.42.0-wmf.16/includes/pager/IndexPager.php(739): MediaWiki\Pager\IndexPager->doQuery()
#14 /srv/mediawiki/php-1.42.0-wmf.16/includes/specials/SpecialProtectedPages.php(124): MediaWiki\Pager\IndexPager->getNumRows()
#15 /srv/mediawiki/php-1.42.0-wmf.16/includes/specialpage/SpecialPage.php(727): MediaWiki\Specials\SpecialProtectedPages->execute(NULL)
#16 /srv/mediawiki/php-1.42.0-wmf.16/includes/specialpage/SpecialPageFactory.php(1653): MediaWiki\SpecialPage\SpecialPage->run(NULL)
#17 /srv/mediawiki/php-1.42.0-wmf.16/includes/actions/ActionEntryPoint.php(512): MediaWiki\SpecialPage\SpecialPageFactory->executePath(string, RequestContext)
#18 /srv/mediawiki/php-1.42.0-wmf.16/includes/actions/ActionEntryPoint.php(153): MediaWiki\Actions\ActionEntryPoint->performRequest()
#19 /srv/mediawiki/php-1.42.0-wmf.16/includes/MediaWikiEntryPoint.php(185): MediaWiki\Actions\ActionEntryPoint->execute()
#20 /srv/mediawiki/php-1.42.0-wmf.16/index.php(55): MediaWiki\MediaWikiEntryPoint->run()
#21 /srv/mediawiki/w/index.php(3): require(string)
#22 {main}
```
==== Notes ====
A low and steady flow of these warnings started Jan 30, 2024 @ 20:39:43 UTC. 1.42.0-wmf.16 rollout to group0 completed at 19:10:35 UTC.
Low volume.
**Steps to replicate the issue** (include links if applicable):
* Open https://sr.wikipedia.org/wiki/Special:ActiveUsers
**What happens?**:
There are a bunch of users with 0 edits in the latest edits. Edits were made but deleted, and I'm guessing that is the reason why the numbers are 0.
**What should have happened instead?**:
0 actions shouldn't be shown, or deleted edits should also be counted.
**Software version** (skip for WMF-hosted wikis like Wikipedia):
* MediaWiki in Serbian Wikipedia (group 2)
**Other information** (browser name/version, screenshots, etc.):
/
**Steps to replicate the issue** (include links if applicable):
* Preview e.g. `{{Special:WhatLinksHere/Foo}}{{Special:WhatLinksHere/Bar}}`
**What happens?**:
The preview contains two elements with the ID `mw-whatlinkshere-list`.
**What should have happened instead?**:
The preview contains no duplicate IDs.
```lang=php
foreach ( SpecialVersion::parseComposerInstalled( $credits ) as $name => $info ) {
if ( str_starts_with( $info['type'], 'mediawiki-' ) ) {
// Skip any extensions or skins since they'll be listed
// in their proper section
continue;
}
$data[] = [
'name' => $name,
'version' => $info['version'],
];
}
```
==== Error ====
* service.version: 1.42.0-wmf.15
* trace.id: c640a99a-64c2-4cd4-986d-3ee81d782747
* [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2024-01-22T14:03:47.016Z',to:'2024-01-23T14:42:48.143Z'))&_a=(query:(query_string:(query:'reqId:%22c640a99a-64c2-4cd4-986d-3ee81d782747%22'))) | Find trace.id in Logstash ]]
```name=labels.normalized_message,lines=10
[{reqId}] {exception_url} InvalidArgumentException: Passing a raw callable is not allowed here. Use [ 'factory' => $callable ] instead.
```
```name=error.stack_trace,lines=10
from /srv/mediawiki/php-1.42.0-wmf.15/vendor/wikimedia/object-factory/src/ObjectFactory.php(279)
#0 /srv/mediawiki/php-1.42.0-wmf.15/vendor/wikimedia/object-factory/src/ObjectFactory.php(174): Wikimedia\ObjectFactory\ObjectFactory::validateSpec(string, array)
#1 /srv/mediawiki/php-1.42.0-wmf.15/vendor/wikimedia/object-factory/src/ObjectFactory.php(149): Wikimedia\ObjectFactory\ObjectFactory::getObjectFromSpec(string, array)
#2 /srv/mediawiki/php-1.42.0-wmf.15/includes/logging/LogFormatter.php(72): Wikimedia\ObjectFactory\ObjectFactory->createObject(string, array)
#3 /srv/mediawiki/php-1.42.0-wmf.15/includes/logging/LogFormatter.php(89): LogFormatter::newFromEntry(DatabaseLogEntry)
#4 /srv/mediawiki/php-1.42.0-wmf.15/includes/logging/LogPager.php(443): LogFormatter::newFromRow(stdClass)
#5 /srv/mediawiki/php-1.42.0-wmf.15/includes/pager/IndexPager.php(576): MediaWiki\Pager\LogPager->doBatchLookups()
#6 /srv/mediawiki/php-1.42.0-wmf.15/includes/specials/SpecialLog.php(313): MediaWiki\Pager\IndexPager->getBody()
#7 /srv/mediawiki/php-1.42.0-wmf.15/includes/specials/SpecialLog.php(192): MediaWiki\Specials\SpecialLog->show(MediaWiki\Html\FormOptions, array)
#8 /srv/mediawiki/php-1.42.0-wmf.15/includes/specialpage/SpecialPage.php(727): MediaWiki\Specials\SpecialLog->execute(string)
#9 /srv/mediawiki/php-1.42.0-wmf.15/includes/specialpage/SpecialPageFactory.php(1652): MediaWiki\SpecialPage\SpecialPage->run(string)
#10 /srv/mediawiki/php-1.42.0-wmf.15/includes/actions/ActionEntryPoint.php(504): MediaWiki\SpecialPage\SpecialPageFactory->executePath(string, RequestContext)
#11 /srv/mediawiki/php-1.42.0-wmf.15/includes/actions/ActionEntryPoint.php(151): MediaWiki\Actions\ActionEntryPoint->performRequest()
#12 /srv/mediawiki/php-1.42.0-wmf.15/includes/MediaWikiEntryPoint.php(169): MediaWiki\Actions\ActionEntryPoint->execute()
#13 /srv/mediawiki/php-1.42.0-wmf.15/index.php(50): MediaWiki\MediaWikiEntryPoint->run()
#14 /srv/mediawiki/w/index.php(3): require(string)
#15 {main}
```
==== Impact ====
==== Notes ====
**Steps to replicate the issue** (include links if applicable):
* Visit https://en.m.wikipedia.org/w/index.php?title=Special:MobileOptions and disable AMC mode,
* Visit https://en.m.wikipedia.org/w/index.php?title=Wikipedia:Bug_reports_and_feature_requests&action=history
* Turn on emulator and switch to iPhone SE
**What happens?**:
There is a horizontal scroll due to long IP addresses {F41698345}
**What should have happened instead?**:
No horizontal scroll.
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
The cached output of the various MediaWiki query pages like Special:UnusedTemplates, Special:GadgetUsage, etc should be exposed to lua. The Action API already exposes these through action=query&list=querypage so the data is already available in a machine-readable format.
Quoting from https://blog.bawolff.net/2024/01/imagining-future-mediawiki.html:
> Results [of querying] should be usable for futher processing
> e.g. You should be able to use the result inside a lua module and format it in arbitrary ways
**Use case(s)**
* Combined with the editnotice or [[https://mediawiki.org/wiki/Extension:PageNotice|PageNotice]] systems, this could be used on JS/CSS pages to notify viewers/editors of the number of users loading the page (via data from GadgetUsage).
* ...
**Steps to replicate the issue**
* Create a Lua module that links to another module that doesn't exist, such as the non-existent [[module:klfklsdfmklsdmklf]]
* Go to Special:WantedPages
**What happens?**
* You will not find [[Module:klfklsdfmklsdmklf]] listed on [[Special:WantedPages]].
* If you go to [[Special:WhatLinksHere/Module:klfklsdfmklsdmklf]] only links from Wikitext pages are listed, not any from any modules.
**What should have happened instead?**:
The links from the Lua modules should be listed there so it can be seen if any modules are missing.
**Feature summary**
Create a special page at `[[Special:WantedModules]]` (similar to `[[Special:WantedFiles]]` and `[[Special:WantedTemplates]]`), that lists red links to the Module: namespace, including red links from Templates (in Template namespace) and red links from other Modules (in Module namespace).
Currently, red links from Template: namespace can be found by filtering `[[Special:WantedPages]]`, but this ignores links from other modules. Maybe that is another bug.
**Benefits**
This enables third party wikis, who may copy Wikipedia templates and modules, to see what modules are missing from their installation, which will cause some modules not to work properly.
If a user belongs to two user groups, its number of edits will double in [[ https://en.wikipedia.org/wiki/Special:ActiveUsers | Special:ActiveUsers ]] when both of its user groups are searched.
**Steps to replicate the issue & What happens**:
* Go to [[ https://en.wikipedia.org/wiki/Special:ActiveUsers | Special:ActiveUsers ]].
* [[ https://en.wikipedia.org/wiki/Special:ActiveUsers?username=&groups%5B%5D=bureaucrat&wpFormIdentifier=specialactiveusers | Tick "Bureaucrats" ]] in "Display users belonging to groups:"
** You will find that a user "28bytes" has 83 actions.
* However, when you [[ https://en.wikipedia.org/wiki/Special:ActiveUsers?username=&groups%5B%5D=sysop&groups%5B%5D=bureaucrat&wpFormIdentifier=specialactiveusers | tick both "Bureaucrats" and "Administrators" ]]:
** You will find that he has 166 actions instead, which doubles.
**What should have happened instead?**:
* The action count should not be duplicated.
**Software version**:
* MediaWiki: 1.42.0-wmf.10 ( 3e07889 )
**Other information**:
**Steps to replicate the issue** (include links if applicable):
POC url: https://en.wikipedia.org/w/index.php?title=User:Bawolff/sandbox&oldid=1189338700&action=edit&preview=yes
* Set your skin preference to something other than the default.
* Transclude `{{Special:Contributions|target=foo/../}}` on to a page
* preview the page or save and immediately view (It has to be rendered within the request for bug to appear. Bug does not appear when serving page from parser cache)
**What happens?**:
* User's skin preference is overriden to default skin
**What should have happened instead?**:
* Skin should not be overriden
**Software version** (skip for WMF-hosted wikis like Wikipedia):
Wikipedia
**Other information** (browser name/version, screenshots, etc.):
I suspect HTMLForm sets something to a global somewhere which then escapes the global isolation that Parser::braceSubstitution tries to set up.
**Steps to replicate the issue** (include links if applicable):
Similar to T346760, but this time it is Special:WhatLinksHere.
The revision available for reference is [[https://zh.wikipedia.org/wiki/Special:PermaLink/79944486]].
**What happens?**:
same as T346760
https://performance.wikimedia.org/excimer/profile/3b206d51ea605243
https://performance.wikimedia.org/xhgui/?url=942196e7-4ea3-4c47-a07e-ac07a156e2e4
{F41570414}
**Feature summary** (what you would like to be able to do and where):
Currently, Special:ChangeContentModel uses two <forms>. The first form is for picking the page, and the second form is for changing the content model.
Both forms currently use POST.
It would be better if the first form used GET, since it is not changing anything in the database.
Form 1:
{F41523790}
Form 2:
{F41523792}
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
**Benefits** (why should this be implemented?):
* This would be better for back button behavior, refresh behavior, browsing history, etc.
* This would also be more orthodox. Stuff that changes the database should use POST, and stuff that only reads the database should use GET.
**Feature summary** (what you would like to be able to do and where):
In special:prefixindex need to toggle the namespace prefix on and off in the displayed page list
In this example from English Wikisource the generated list would allow a presentation form that prepends the namespace to the generated list, eg. Page: ns
https://en.wikisource.org/wiki/Special:PrefixIndex/Page:Houghton_Mifflin
```
Houghton Mifflin Co. v. Stackpole Sons (104 F.2d 306).pdf/1
Houghton Mifflin Co. v. Stackpole Sons (104 F.2d 306).pdf/2
Houghton Mifflin Co. v. Stackpole Sons (104 F.2d 306).pdf/3
etc.
```
desired output
```
Page:Houghton Mifflin Co. v. Stackpole Sons (104 F.2d 306).pdf/1
Page:Houghton Mifflin Co. v. Stackpole Sons (104 F.2d 306).pdf/2
Page:Houghton Mifflin Co. v. Stackpole Sons (104 F.2d 306).pdf/3`
etc.
```
From my dim dark memory this sort of display used to be available though has disappeared with other iterations
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
I want to be able to easily generate a list of pages for maintenance purposes including the namespace name, and to have that ability to toggle on and off that display component
PrefixIndex only displays as
* {{{PAGENAME}}
desire the ability for additional option
* {{NS}}:{{PAGENAME}}
The addition of another toggle option would be my wish
**Benefits** (why should this be implemented?):
The Wikisources have Page: ns pages that align with the File: and Index: ns version file of the same name, and moves of these files/pages generates large amounts of redirects and other type of maintenance, and this the best source to generate a clean list.
At the moment for a book with 500 pages, that means that I have to add the prefix to 500 lines from a system generated list ¯\_(ツ)_/¯
**Steps to replicate the issue** (include links if applicable):
* Visit https://en.wikipedia.org/wiki/Special:Search
* Type "test" in the textbox, and select Google, and press Search.
**What happens?**:
You will see
> The information you’re about to submit is not secure
> Because this form is being submitted using a connection that’s not secure, your information will be visible to others.
That is because the form is trying to connect to
http://www.google.com/search?q=test&sitesearch=en.wikipedia.org&profile=advanced&fulltext=1&ns0=1&wprov=acrw1_-1
It should use https, not http.
**Steps to replicate the issue** (include links if applicable):
* Go to https://en.wikipedia.org/w/index.php?title=Special:Contributions&end=&namespace=3&start=&tagfilter=&target=Rootsmusic&offset=&limit=500
*
*
**What happens?**:
Per [[ https://meta.wikimedia.org/wiki/Special:CentralAuth/Rootsmusic | CentralAuth ]], this user has 307 edits. I can only see 59 edits. @AmandaNP could originally only see a subset of edits, but then later became able to see all the edits.
All 307 edits appear in https://quarry.wmcloud.org/query/77818.
**What should have happened instead?**:
Edits should not magically disappear.
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
{F41434841}
**Steps to replicate the issue** (include links if applicable):
* Visit a Special:Log or Special:Contributions page or a page history.
* Append "&limit=0" (if the URL already contains a query string) or "?limit=0" (if the URL does not already contain a query string) to the end of the URL.
**What happens?**: The default limit of 50 log entries or edits is shown.
**What should have happened instead?**: An empty list of log entries or edits is shown.
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
The behavior is inconsistent with the one for Special:RecentChanges (which currently does not use paging, although paging Special:RecentChanges has often been proposed, as at T20228 and T163429). Namely, when I visit https://en.wikipedia.org/wiki/Special:RecentChanges?limit=0, an empty list is correctly shown with the message "No changes during the given period match these criteria.".
In contrast, https://en.wikipedia.org/wiki/Special:Log?limit=0, https://en.wikipedia.org/wiki/Special:Contributions/0?limit=0, and https://en.wikipedia.org/w/index.php?title=Main_Page&action=history&limit=0 do not work as expected.
== Steps to reproduce
1. Open https://hu.wikipedia.org/wiki/Szerkeszt%C5%91:UTF48/Jap%C3%A1n/Spec?action=purge using Vector 2022 (I tried it logged out) and purge the page.
2. Switch to Vector 2010 in your preferences.
3. Open the same page as above in read view (https://hu.wikipedia.org/wiki/Szerkeszt%C5%91:UTF48/Jap%C3%A1n/Spec).
== Actual result
4. The page appears with Vector 2022.
== Expected result
4. The page appears with Vector 2010.
== Other information
* The page transcludes Special:WhatLinksHere. Is it a regression of {T336504}?
==== Error ====
* service.version: 1.41.0-wmf.30
* trace.id: 8c1bff3e-e7db-45a0-aa5d-6edb94832781
* [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2023-10-18T14:59:49.021Z',to:'2023-10-19T15:39:50.939Z'))&_a=(query:(query_string:(query:'reqId:%228c1bff3e-e7db-45a0-aa5d-6edb94832781%22'))) | Find trace.id in Logstash ]]
```name=labels.normalized_message,lines=10
[{reqId}] {exception_url} Error: Call to a member function getDBkey() on null
```
```name=error.stack_trace,lines=10
from /srv/mediawiki/php-1.41.0-wmf.30/extensions/PageAssessments/src/SpecialPage.php(104)
#0 /srv/mediawiki/php-1.41.0-wmf.30/includes/specialpage/QueryPage.php(564): MediaWiki\Extension\PageAssessments\SpecialPage->getQueryInfo()
#1 /srv/mediawiki/php-1.41.0-wmf.30/includes/specialpage/QueryPage.php(774): MediaWiki\SpecialPage\QueryPage->reallyDoQuery(integer, integer)
#2 /srv/mediawiki/php-1.41.0-wmf.30/extensions/PageAssessments/src/SpecialPage.php(262): MediaWiki\SpecialPage\QueryPage->execute(NULL)
#3 /srv/mediawiki/php-1.41.0-wmf.30/includes/specialpage/SpecialPage.php(727): MediaWiki\Extension\PageAssessments\SpecialPage->execute(NULL)
#4 /srv/mediawiki/php-1.41.0-wmf.30/includes/specialpage/SpecialPageFactory.php(1621): MediaWiki\SpecialPage\SpecialPage->run(NULL)
#5 /srv/mediawiki/php-1.41.0-wmf.30/includes/MediaWiki.php(357): MediaWiki\SpecialPage\SpecialPageFactory->executePath(string, RequestContext)
#6 /srv/mediawiki/php-1.41.0-wmf.30/includes/MediaWiki.php(960): MediaWiki->performRequest()
#7 /srv/mediawiki/php-1.41.0-wmf.30/includes/MediaWiki.php(613): MediaWiki->main()
#8 /srv/mediawiki/php-1.41.0-wmf.30/index.php(50): MediaWiki->run()
#9 /srv/mediawiki/php-1.41.0-wmf.30/index.php(46): wfIndexMain()
#10 /srv/mediawiki/w/index.php(3): require(string)
#11 {main}
```
==== Impact ====
==== Notes ====
Noticed a single spike of 12 of these in 1.41.0-wmf.30.
As seen in here: https://gerrit.wikimedia.org/g/mediawiki/core/+/4bc5734399d240534af95139cefced7df760c5e2/maintenance/updateSpecialPages.php#138
```lang=php
private function reopenAndWaitForReplicas() {
$lbFactory = $this->getServiceContainer()->getDBLoadBalancerFactory();
$lb = $lbFactory->getMainLB();
if ( !$lb->pingAll() ) {
$this->output( "\n" );
do {
$this->error( "Connection failed, reconnecting in 10 seconds..." );
sleep( 10 );
} while ( !$lb->pingAll() );
$this->output( "Reconnected\n\n" );
}
// Wait for the replica DB to catch up
$this->waitForReplication();
}
```
This will get stuck if the DB it was previously using gets taken down for maintenance or something similar.
**Steps to replicate the issue** (include links if applicable):
* Go to https://en.wikipedia.org/w/index.php?title=Special:LinkSearch&limit=500&offset=0&target=kb.nl
**What happens?**:
* This returns results including www.kb.nl and other subdomains
**What should have happened instead?**:
An exact match should have been made. This is also documented on the special page. By default matches should be exact, but a wildcard sign can be used in the search.
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
This is most likely fallout from {T312666}
The other option is that the query was rewritten to the new query builder and this issue was introduced thus.
* Open https://en.wikipedia.org/wiki/Special:Contributions
If the user clicks "Search" with no username provided, the page just get "refreshed" and the user gets nothing (even an error message).
**Steps to replicate the issue** (include links if applicable):
* Open https://en.wikipedia.org/wiki/Special:EmailUser
**What happens?**:
{F37917842}
"This value is required" is shown. This may make users confused as nothing has been submitted yet.
**What should have happened instead?**:
No warning is shown.
**Software version** (skip for WMF-hosted wikis like Wikipedia)
Steps to replicate:
* Enable Vector 2010 as skin on https://tr.wikipedia.org/wiki/Özel:Tercihler#mw-prefsection-rendering
* Go to the [[ https://tr.wikipedia.org/wiki/Anasayfa | Turkish Wikipedia main page ]]
* Click on the talk page (leading you to Tartışma:Anasayfa)
* Alternatively, search "VP:KÇ" in the search bar (shortcut to trwiki village pump)
The skin should automatically change to Vector 2022, while you have 2010 enabled. A refresh returns you to the correct skin.
I noticed that this issue only happens on the Turkish Wikipedia, despite me browsing through a lot of projects, as well as these specific pages. These are high-traffic pages that I visit from time to time, so I'm not sure if some other low-traffic pages have this issue as well.
https://en.wikipedia.org/wiki/Special:GlobalRenameQueue/open incorrectly uses mw-ui-button-group to create a set of tabs at the top of the page.
{F37817695}
{F37817697}
SpecialPage's support tabs natively (See https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralNotice/+/934428 as an example of how to implement this)
**Steps to replicate the issue** (include links if applicable):
* Navigate to Special:ProtectedPages, select the "Min size" radio box, and click the "Display pages" button.
**What happens?**:
The selection of radio boxes switched to "Max size", it's annoying since we usually don't want to set "Max size".
**What should have happened instead?**:
The min/max size selection sticks to the user's choice, and defaults to "Min size" as several versions ago did, probably before switching to OOUI.
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
**Steps to replicate the issue** (include links if applicable):
* Export some logs with `php dumpBackup.php --logs` to an XML file
* Import the XML file to another site with Special:Import
**What happens?**:
On Special:Logs and in the actor table, the actor name's first letter of interwiki prefix is in upper case.
{F37754188}
**What should have happened instead?**:
They are in lower case as specified on Special:Import, like revision importing does.
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
When looking at the sentence "Account created on ..." above a list of contributions in Special:Contributions, I noticed that the creation date is in another timezone (I guess UTC) than my own timezone (CEST). Look for example [[ https://en.wikipedia.org/wiki/Special:Contributions/Scarthy737 | here]]. For me, it shows "Account created on 22 September 2023.", while [[ https://en.wikipedia.org/wiki/Special:Log/Scarthy737 | here ]] it says 23 September 2023. Is there a way to make this consistent?
Kind regards,
Ennomien
==== Error ====
* service.version: 1.41.0-wmf.27
* trace.id: 2d68cb4f-fbfd-40a4-811e-36d729034644
* [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2023-09-20T14:32:30.229Z',to:'2023-09-21T15:29:25.232Z'))&_a=(query:(query_string:(query:'reqId:%222d68cb4f-fbfd-40a4-811e-36d729034644%22'))) | Find trace.id in Logstash ]]
```name=labels.normalized_message,lines=10
[{reqId}] {exception_url} InvalidArgumentException: Wikimedia\Rdbms\Platform\SQLPlatform::makeList: empty input for field page_namespace
```
```name=error.stack_trace,lines=10
from /srv/mediawiki/php-1.41.0-wmf.27/includes/libs/rdbms/platform/SQLPlatform.php(241)
#0 /srv/mediawiki/php-1.41.0-wmf.27/includes/libs/rdbms/platform/SQLPlatform.php(738): Wikimedia\Rdbms\Platform\SQLPlatform->makeList(array, integer)
#1 /srv/mediawiki/php-1.41.0-wmf.27/includes/libs/rdbms/database/Database.php(3442): Wikimedia\Rdbms\Platform\SQLPlatform->selectSQLText(array, array, array, string, array, array)
#2 /srv/mediawiki/php-1.41.0-wmf.27/includes/libs/rdbms/database/DatabaseMySQL.php(719): Wikimedia\Rdbms\Database->selectSQLText(array, array, array, string, array, array)
#3 /srv/mediawiki/php-1.41.0-wmf.27/includes/libs/rdbms/database/Database.php(1375): Wikimedia\Rdbms\DatabaseMySQL->selectSQLText(array, array, array, string, array, array)
#4 /srv/mediawiki/php-1.41.0-wmf.27/includes/libs/rdbms/database/DBConnRef.php(119): Wikimedia\Rdbms\Database->select(array, array, array, string, array, array)
#5 /srv/mediawiki/php-1.41.0-wmf.27/includes/libs/rdbms/database/DBConnRef.php(351): Wikimedia\Rdbms\DBConnRef->__call(string, array)
#6 /srv/mediawiki/php-1.41.0-wmf.27/includes/specials/SpecialRandomPage.php(228): Wikimedia\Rdbms\DBConnRef->select(array, array, array, string, array, array)
#7 /srv/mediawiki/php-1.41.0-wmf.27/includes/specials/SpecialRandomPage.php(173): MediaWiki\Specials\SpecialRandomPage->selectRandomPageFromDB(string, string)
#8 /srv/mediawiki/php-1.41.0-wmf.27/includes/specials/SpecialRandomPage.php(86): MediaWiki\Specials\SpecialRandomPage->getRandomTitle()
#9 /srv/mediawiki/php-1.41.0-wmf.27/includes/specialpage/SpecialPage.php(721): MediaWiki\Specials\SpecialRandomPage->execute(string)
#10 /srv/mediawiki/php-1.41.0-wmf.27/includes/specialpage/SpecialPageFactory.php(1622): MediaWiki\SpecialPage\SpecialPage->run(string)
#11 /srv/mediawiki/php-1.41.0-wmf.27/includes/MediaWiki.php(354): MediaWiki\SpecialPage\SpecialPageFactory->executePath(string, RequestContext)
#12 /srv/mediawiki/php-1.41.0-wmf.27/includes/MediaWiki.php(953): MediaWiki->performRequest()
#13 /srv/mediawiki/php-1.41.0-wmf.27/includes/MediaWiki.php(601): MediaWiki->main()
#14 /srv/mediawiki/php-1.41.0-wmf.27/index.php(50): MediaWiki->run()
#15 /srv/mediawiki/php-1.41.0-wmf.27/index.php(46): wfIndexMain()
#16 /srv/mediawiki/w/index.php(3): require(string)
#17 {main}
```
==== Impact ====
==== Notes ====
2 of these seen in 1.41.0-wmf.27 (T345888). On further investigation, has been happening at a low rate for a while, so not train related.
**Steps to replicate the issue** (include links if applicable):
* Set skin to vector (2010)
* Go to [[https://zh.wikipedia.org/wiki/Wikipedia:Growth團隊功能/導師列表]] or [[https://zh.wikipedia.org/w/index.php?title=Wikipedia:Growth團隊功能/導師列表&action=edit]]
**What happens?**:
This error does not occur every time.
{F37739302}
[[https://performance.wikimedia.org/excimer/profile/ad3ee062fa3da77f]]
{F37739287}
Incorrectly rendered as vector2022.
ReqId = `5c73572e-0de9-4682-85cd-1a6153624060`
**Feature summary** (what you would like to be able to do and where):
At Special:Log/upload you can choose to see 1. All uploads 2. New uploads 3. Reuploads or 4. Reverts. This option is not available at Special:ListFiles. I suggest they get added there.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
Personally I make a lot of edits to others' files (mainly with CropTool) and these small edits swamp my ListFiles when I would most rather only see my own new uploads. People who revert a lot of files would also find this problem.
**Benefits** (why should this be implemented?):
To make people being able to see only the files which they themselves have uploaded and not the files they have reverted or edited.
Links to my pages on Commons: https://commons.wikimedia.org/wiki/Special:ListFiles/Jonteemil and https://commons.wikimedia.org/w/index.php?title=Special:Log/upload&user=Jonteemil.
**Steps to replicate the issue** (include links if applicable):
* Visit https://meta.wikimedia.org/wiki/Special:MyLanguage/Special:MyLanguage/Test
* Alternatively, visit https://incubator.wikimedia.org/wiki/Special:MyLanguage or https://meta.wikimedia.org/wiki/Special:MyLanguage (the reason I discovered this bug)
**What happens?**:
* You just get a completely blank page
**What should have happened instead?**:
* Special:MyLanguage should handle self-references/loops more graciously by removing any repeats "Special:MyLanguage" before trying to resolve the URL
This is most noticeable when you visit a plain [[Special:MyLanguage]] on incubatorwiki or metawiki; on those wikis, the main page (via MediaWiki:Mainpage) is set to "Special:MyLanguage/Main page", which essentially leads Special:MyLanguage to double (even if it's not visible).
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
**Steps to replicate the issue** (include links if applicable):
* Visit https://test.wikipedia.org/wiki/Special:TrackingCategories
**What happens?**:
[[https://test.wikipedia.org/wiki/Category:Pages_that_use_Phonos|Category:Pages that use Phonos]] and [[https://test.wikipedia.org/wiki/Category:Pages_with_Phonos_rendering_errors|Category:Pages with Phonos rendering errors]] are not on the list.
**What should have happened instead?**:
The categories are on the list.
**Background**
This is a proposed feature enhancement to the work that went into {T337431}. That project is about introducing a much more user-friendly means to manage the old Spamblacklist, which before was a giant wikitext page full of regular expressions. The problem is that in this case, admins almost never need regular expressions, rather just the top-level domain or maybe a subdomain. A simple UI to add/remove domains with an optional comment is more than sufficient.
Similar to Spamblacklist, there is a URL ignore list at [[ https://meta.wikimedia.org/wiki/User:CopyPatrolBot/UrlIgnoreList | User:CopyPatrolBot/UrlIgnoreList ]] that is used by #copypatrol. Here we list Wikipedia mirrors and other sites that frequently show up as possible copyright violations, when in actuality they're a [[ https://en.wikipedia.org/wiki/Wikipedia:Copyright_problems#Backwards_copying:_when_Wikipedia_had_(or_may_have_had)_it_first | backwards copy ]] of Wikpedia. It would be great if users of CopyPatrol could take advantage of the same UI that is used by [[ https://en.wikipedia.org/wiki/Special:BlockedExternalDomains | Special:BlockedExternalDomains ]], given [[ https://meta.wikimedia.org/wiki/Talk:CopyPatrol#c-Diannaa-20230821164800-MusikAnimal_(WMF)-20230821163400 | some people aren't comfortable with regex ]]. Functionally what we want is the same, the only difference being we want the list saved to a different JSON page.
There may be other use cases beyond CopyPatrol and Spamblacklist, too. For example, as part of the #editcheck project, we may want a machine-readable [[ https://en.wikipedia.org/wiki/Wikipedia:Reliable_sources/Perennial_sources | list of unreliable sites ]] that can easily be maintained by the community (T276857).
**Proposal**
Abstract out the UI from [[ https://en.wikipedia.org/wiki/Special:BlockedExternalDomains | Special:BlockedExternalDomains ]] into a general purpose manager of JSON pages that list URLs/domains. This could be called `Special:EditUrlList`, and accept a path of the page in question, such as `Special:EditUrlList/Pagename.json`.
Special:BlockedExternalDomains (which lives in #abusefilter) can simply extend the Special page class for Special:EditUrlList, adding the relevant interface messages and changing the title. Or, it could simply redirect to `Special:EditUrlList/MediaWiki:BlockedExternalDomains.json`. The usual permission checks should be added, ensuring the editor has rights to edit the target JSON page.
This new Special page could perhaps live in MediaWiki Core, as it seems a bit too broad to keep in AbuseFilter, especially if other extensions will come to rely on it.
I find this very doable since Special:Contributions already have some logic for external users, maybe just some changes broke it.
**Steps to replicate the issue** (include links if applicable):
* Import some revisions, set interwiki prefix to e.g. `imported`
* Visit `Special:Log?user=imported>User_name`, where `User_name` is the author of imported revisions.
*
**What happens?**:
```
MediaWiki internal error.
Original exception: [edf1a2fec4a8c5d39a9bd439] /wiki/Special:Log?type=&user=imported%3EAdmin&page=&wpdate=&tagfilter=&wpfilters%5B%5D=newusers&wpFormIdentifier=logeventslist Error: Call to a member function getLocalURL() on null
Backtrace:
from /var/www/html/w/includes/skins/components/SkinComponentUtils.php(103)
#0 /var/www/html/w/includes/skins/Skin.php(1377): MediaWiki\Skin\SkinComponentUtils::makeSpecialUrlSubpage()
#1 /var/www/html/w/includes/skins/Skin.php(1536): Skin->buildNavUrls()
#2 /var/www/html/w/includes/skins/SkinTemplate.php(611): Skin->buildSidebar()
#3 /var/www/html/w/includes/skins/SkinTemplate.php(180): SkinTemplate->getPortletsTemplateData()
#4 /var/www/html/w/includes/skins/SkinMustache.php(125): SkinTemplate->getTemplateData()
#5 /var/www/html/w/skins/Vector/includes/SkinVector22.php(313): SkinMustache->getTemplateData()
#6 /var/www/html/w/includes/skins/SkinMustache.php(92): MediaWiki\Skins\Vector\SkinVector22->getTemplateData()
#7 /var/www/html/w/includes/skins/SkinTemplate.php(173): SkinMustache->generateHTML()
#8 /var/www/html/w/includes/OutputPage.php(2915): SkinTemplate->outputPage()
#9 /var/www/html/w/includes/MediaWiki.php(960): OutputPage->output()
#10 /var/www/html/w/includes/MediaWiki.php(591): MediaWiki->main()
#11 /var/www/html/w/index.php(50): MediaWiki->run()
#12 /var/www/html/w/index.php(46): wfIndexMain()
#13 {main}
```
**What should have happened instead?**:
Fail nicely without exceptions since this is not supported.
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
**Feature summary** (what you would like to be able to do and where):
* New special page (Special:HighestEditCounts?) to list top 100 users with highest edit count
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
* Went to go see who has the highest edit counts on metawiki. Couldn't find a page with this info.
**Benefits** (why should this be implemented?):
* Useful info. Shouldn't need a third party tool for this. SQL query would be cheap since this information is stored in a field in the user table.
**Acceptance criteria**
* [ ] create new special page
* [ ] should display username and edit count, descending by edit count
* [ ] maybe also include a column with date of last edit, so you can see if they're active
* [ ] usernames should be hyperlinked to their profile pages
* [ ] make sure it shows up correctly at Special:SpecialPages (probably in the "Users and rights" section)
On some wikis, there are log entries whose authorship information has been lost due to bugs. They have user names associated with them, but no users by that name exist, and they aren't valid IP address names either. Special:Log refuses to show them.
For example, this shows an error: https://en.wikipedia.org/wiki/Special:Log/Unknown_user {F37618237} …even though there are log entries for this user name, which can be viewed via the API: https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&format=json&list=logevents&formatversion=2&leuser=Unknown%20user
This issue was originally noticed in T344632 (although that bug should be fixed by fixing the log entries).
**Steps to replicate the issue** (include links if applicable):
* Load https://en.wikipedia.org/wiki/User:Global_rename_script
* Click on the link to https://en.wikipedia.org/wiki/Special:Log/Global_rename_script (present on the userpage)
**What happens?**:
Log entries are not shown and instead the error that "Global rename script does not exist." is shown
**What should have happened instead?**:
Log entries should be shown as entries are shown via the API.
**Software version** (skip for WMF-hosted wikis like Wikipedia):
English Wikipedia
**Other information** (browser name/version, screenshots, etc.):
As this can be used as the performer when running fixStuckGlobalRename.php script or as part of `LocalRenameJob::getRenameUser`. This therefore means that it is stopping me from being able to debug T343983 effectively, as I cannot verify if the performer of the un-stuck renames was this system user.
**Steps to replicate the issue** (include links if applicable):
* Visit https://en.wikipedia.org/wiki/Special:ChangeContentModel
**What happens?**:
{F37569530}
**What should have happened instead?**:
{F37569536}
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
* It violates the principle of least astonishment and is confusing for Sanitized CSS to be selected as the new content model by default. I suggest adding a blank option, then throwing a form validation error if that remains selected.
* Confusingly, in ooui, when text boxes are editable they are white, and when they are not editable (readonly) they are gray. But when combo boxes are editable they are gray, and when they are not editable (readonly) they are gray. Special:ChangeContentModel uses a mix of readonly and editable, with lots of gray, and gray not corresponding to readonly or editable consistently. Since changing the ooui combo box background color doesn't seem likely to me to get merged, I think this approach of adding a blank combo box option helps solve that confusion.
{F41464464}
The top caption for one of extensions tables on Special:Version is "Parser hooks". It includes extensions such as Babel, Cite, Math, and SyntaxHighlight, that is—extensions that add something to the wikitext.
The title "Parser hooks" is rather obscure. Especially the "hooks" part: it is meaningful to experienced backend MediaWiki developers, but most wikis' users are not experienced backend MediaWiki developers.
In addition, Special:Version also has a section with a very similar name: "Parser function hooks", which refers more directly to actual hooks.
I recommend renaming the "Parser hooks" (message key `version-parserhooks`) caption to a more descriptive name. Some suggestions:
* Wikitext extensions
* Wikitext syntax additions
* Syntax extensions
* Wikitext modifications
etc.
Special:WantedFiles lists files that are used but do not exist on given wiki. This includes files from Wikimedia Commons and thus effectively renders Special:WantedFiles useless for looking up files that don't exist anywhere.
One way to fix that would be to exclude files from other repositories from being listed on Special:WantedFiles.
See also T8220#6846373.
==== Error ====
* mwversion: 1.41.0-wmf.19
* reqId: fd22e236-8c0f-43ac-b5f7-fbf448de088c
* [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2023-07-25T11:28:41.852Z',to:'2023-07-26T11:30:09.821Z'))&_a=(query:(query_string:(query:'reqId:%22fd22e236-8c0f-43ac-b5f7-fbf448de088c%22'))) | Find reqId in Logstash ]]
```name=normalized_message,lines=10
[{reqId}] {exception_url} Wikimedia\Assert\PreconditionException: Expected MediaWiki\User\UserIdentityValue to belong to the local wiki, but it belongs to 'metawiki'
```
```name=exception.trace,lines=10
from /srv/mediawiki/php-1.41.0-wmf.19/includes/dao/WikiAwareEntityTrait.php(59)
#0 /srv/mediawiki/php-1.41.0-wmf.19/includes/user/UserIdentityValue.php(139): MediaWiki\User\UserIdentityValue->assertWiki(boolean)
#1 /srv/mediawiki/php-1.41.0-wmf.19/includes/user/UserFactory.php(188): MediaWiki\User\UserIdentityValue->getId()
#2 /srv/mediawiki/php-1.41.0-wmf.19/includes/ServiceWiring.php(2232): MediaWiki\User\UserFactory->newFromUserIdentity(MediaWiki\User\UserIdentityValue)
#3 /srv/mediawiki/php-1.41.0-wmf.19/includes/user/UserGroupManager.php(872): Wikimedia\Services\ServiceContainer::{closure}(MediaWiki\User\UserIdentityValue)
#4 /srv/mediawiki/php-1.41.0-wmf.19/includes/specials/SpecialUserRights.php(484): MediaWiki\User\UserGroupManager->addUserToGroup(MediaWiki\User\UserIdentityValue, string, string, boolean)
#5 /srv/mediawiki/php-1.41.0-wmf.19/includes/specials/SpecialUserRights.php(399): MediaWiki\Specials\SpecialUserRights->doSaveUserGroups(MediaWiki\User\UserIdentityValue, array, array, string, array, array)
#6 /srv/mediawiki/php-1.41.0-wmf.19/includes/specials/SpecialUserRights.php(269): MediaWiki\Specials\SpecialUserRights->saveUserGroups(string, MediaWiki\User\UserIdentityValue)
#7 /srv/mediawiki/php-1.41.0-wmf.19/includes/specialpage/SpecialPage.php(701): MediaWiki\Specials\SpecialUserRights->execute(NULL)
#8 /srv/mediawiki/php-1.41.0-wmf.19/includes/specialpage/SpecialPageFactory.php(1565): SpecialPage->run(NULL)
#9 /srv/mediawiki/php-1.41.0-wmf.19/includes/MediaWiki.php(344): MediaWiki\SpecialPage\SpecialPageFactory->executePath(string, RequestContext)
#10 /srv/mediawiki/php-1.41.0-wmf.19/includes/MediaWiki.php(948): MediaWiki->performRequest()
#11 /srv/mediawiki/php-1.41.0-wmf.19/includes/MediaWiki.php(597): MediaWiki->main()
#12 /srv/mediawiki/php-1.41.0-wmf.19/index.php(50): MediaWiki->run()
#13 /srv/mediawiki/php-1.41.0-wmf.19/index.php(46): wfIndexMain()
#14 /srv/mediawiki/w/index.php(3): require(string)
#15 {main}
```
==== Impact ====
This prevents changes of user rights on a different wiki via Special:UserRights, which is a part of the Stewards process to deal with abuse or remove PII from Wikimedia sites. Traiging as UBN/train blocker.
==== Notes ====
This is similar to (but different from) {T342322} which happened last week.
We apparently need better tests for interwiki Special:Userrights, as this is the second week in a row in which this feature of Special:Userrights caused a train blocker.
**Steps to replicate the issue** (include links if applicable):
* Perform a large number of edits at the same time (identical timestamp, perhaps through scripting)
* attempt to observe edits on your Special:Contributions page
**What happens?**:
Not all edits will be displayed in the list of contribs if they span across pages.
**What should have happened instead?**:
All contribs should be listed in Special:Contribs
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
This was discovered by User:Fayenatic london, after using my MassRollback.js script on enwiki. This script performs a large number of rollbacks at once; in this case, they used it to roll back over 130 edits at 00:45 July 20, 2023.
Viewing Special:Contributions/Fayenatic london for this time period at a page size smaller than 500 will illustrate the issue (e.g. https://en.wikipedia.org/w/index.php?title=Special:Contributions/Fayenatic_london&target=Fayenatic+london&offset=20230720122220&limit=20 ).
At a limit of 20 contribs, we see: 13 edits at 00:45 on the first page, a full 20 contribs on the next page, and 15 contribs on the next, for a total of only 48 edits made at 00:45.
At a limit of 50 with the same initial offset, we see: 40 edits on the first page and 15 edits on the next page, for 65 total edits made at 00:45.
At a limit of 100 with the same initial offset, we see: 90 edits on the first page and 15 edits on the next page, for a total of 105 edits at 00:45.
At a limit of 500 with the same initial offset, we see: 136 edits on the first page at 00:45.
Obviously, these should all give consistent counts, but they don't. Fayenatic london reports that they would expect 139 total reverts, so it's possible that even on the 500 page, some edits are missing.
**Steps to replicate the issue** (include links if applicable):
* Have userrights-interwiki
* Go to https://meta.wikimedia.org/wiki/Special:UserRights/AntiCompositeNumber@enwiki (or any user at any wiki, other than metawiki)
**What happens?**:
```
[501ab252-6ddc-4957-b73d-8ce62a2c67ef] /wiki/Special:UserRights/AntiCompositeNumber@enwiki TypeError: Argument 1 passed to MediaWiki\User\UserNameUtils::isTemp() must be of the type string, object given, called in /srv/mediawiki/php-1.41.0-wmf.18/includes/specials/SpecialUserRights.php on line 652
from /srv/mediawiki/php-1.41.0-wmf.18/includes/user/UserNameUtils.php(372)
#0 /srv/mediawiki/php-1.41.0-wmf.18/includes/specials/SpecialUserRights.php(652): MediaWiki\User\UserNameUtils->isTemp(UserRightsProxy)
#1 /srv/mediawiki/php-1.41.0-wmf.18/includes/specials/SpecialUserRights.php(174): MediaWiki\Specials\SpecialUserRights->fetchUser(string, boolean)
#2 /srv/mediawiki/php-1.41.0-wmf.18/includes/specialpage/SpecialPage.php(701): MediaWiki\Specials\SpecialUserRights->execute(string)
#3 /srv/mediawiki/php-1.41.0-wmf.18/includes/specialpage/SpecialPageFactory.php(1563): SpecialPage->run(string)
#4 /srv/mediawiki/php-1.41.0-wmf.18/includes/MediaWiki.php(344): MediaWiki\SpecialPage\SpecialPageFactory->executePath(string, RequestContext)
#5 /srv/mediawiki/php-1.41.0-wmf.18/includes/MediaWiki.php(948): MediaWiki->performRequest()
#6 /srv/mediawiki/php-1.41.0-wmf.18/includes/MediaWiki.php(597): MediaWiki->main()
#7 /srv/mediawiki/php-1.41.0-wmf.18/index.php(50): MediaWiki->run()
#8 /srv/mediawiki/php-1.41.0-wmf.18/index.php(46): wfIndexMain()
#9 /srv/mediawiki/w/index.php(3): require(string)
#10 {main}
```
**What should have happened instead?**:
it works
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
This will prevent Stewards from effectively responding to abuse.
**Steps to replicate the issue** (include links if applicable):
* Visit for instance https://de.wikivoyage.org/wiki/Special:Longpages
* Press "next 100"
**What happens?**:
* After pressing "next 100", only one article is shown. Now, it is impossible to press "next 100" again.
**What should have happened instead?**:
* A new page with furthermore 100 (or so on) should be presented
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
* Firefox 115.0.2, Windows 10: 22H2
We have a tracking mechanism, so why not use it?
It's not a trivial change because it introduces pseudo-namespaces to the `linktarget` table, but I don't think it breaks any contract. The table is the DB equivalent of the `LinkTarget` class, which can represent special pages.
[Special:WantedPages](https://en.wikipedia.org/wiki/Special:WantedPages) looks like this
{F37127376}
But when you transclude it, it looks like this
{F37127381}
Almost unreadable.
For comparison, almost all other similar Wanted{Files,Templates,Categories} pages do not allow transclusion.
I think WantedPages should either also disable transclusion, or show numbered list formatted output which clearly looks better.
**Steps to replicate the issue** (include links if applicable):
* Open https://en.wikipedia.org/wiki/Special:Contributions/37.161.0.0/16 and confirm it is under a block
* Click "block log" beneath the top heading, which goes to https://en.wikipedia.org/w/index.php?title=Special:Log/block&page=User%3A37.161.0.0%2F16
** Or click "View full log", which goes to https://en.wikipedia.org/w/index.php?title=Special:Log&page=User%3A37.161.0.0%2F16&type=block
**What happens?**:
"No matching items in log."
**What should have happened instead?**:
The block log is shown.
**Other information** (browser name/version, screenshots, etc.):
The block log correctly appears if you
* click "Show" again, which goes to https://en.wikipedia.org/wiki/Special:Log?type=block&user=&page=37.161.0.0%2F16&wpdate=&tagfilter=&subtype=&wpFormIdentifier=logeventslist
* remove `User%3A` from the URL, i.e. https://en.wikipedia.org/w/index.php?title=Special:Log/block&page=37.161.0.0%2F16 or https://en.wikipedia.org/w/index.php?title=Special:Log&page=37.161.0.0%2F16&type=block
On French Wiktionary [[ https://fr.wiktionary.org/wiki/Sp%C3%A9cial:Pages_longues | Spécial:Pages longues ]] and [[ https://fr.wiktionary.org/wiki/Sp%C3%A9cial:Pages_courtes | Spécial:Pages courtes ]] list pages by namespace in this order: 106, 100 and 110 instead of starts with pages in the main namespace. For example, even if [[ https://fr.wiktionary.org/wiki/eau | this article ]] is clearly longer than the first page listed [[ https://fr.wiktionary.org/wiki/Sp%C3%A9cial:Pages_longues | here ]].
Wikis may be affected:
```lang=php
'wgContentNamespaces' => [
'default' => [ NS_MAIN ],
'+arwikisource' => [ 102 ],
'+aswikisource' => [ 102 ], // T45129, T72464
'+bgwikisource' => [ 100 ],
'+bnwikisource' => [ 100 ],
'+bnwikibooks' => [ 104 ], // T236840
'+brwikisource' => [ 104 ],
'+cawikisource' => [ 106 ],
'+cswikiquote' => [ 100 ],
'+cswikisource' => [ 100 ],
'+dawikisource' => [ 102 ],
'+dewikiversity' => [ 106 ], // T93071
'+enwikibooks' => [ 102, 110 ],
'+enwikisource' => [ 102, 114 ], // T52007
'+eswiki' => [ 104 ], // T41866
'+etwikisource' => [ 106 ],
'+euwiki' => [ 104 ], // T191396
'+fawikibooks' => [ 102, 110 ], // T76663
'+fawikisource' => [ 102 ],
'+frrwiki' => [ 106 ], // T40023
'+frwikisource' => [ 102 ],
'+frwikiversity' => [ 104 ], // T125948
'+frwiktionary' => [
106, // T97228
100, 110, 114, 116, 118, // T270821
],
'+hewikisource' => [ 100, 106, 108, 110 ], // T98709
'+hrwiki' => [ 102 ], // T42732
'+hrwikisource' => [ 100 ],
'+huwikisource' => [ 100 ],
'+hywikisource' => [ 100 ],
'+idwikibooks' => [ 100, 102 ], // T4282
'+idwikisource' => [ 100 ],
'+itwikisource' => [ 102 ],
'+itwikivoyage' => [ 100, 104 ], // T57620
'+kowikisource' => [ 100, 114 ], // T183836 for 114
'+lawikisource' => [ 102 ],
'+ltwiki' => [ 104 ], // T144118
'+mediawikiwiki' => [ 100, 102, 104, 106 ], // Manuals, extensions, Api & skin - T86391
'+metawiki' => [ NS_HELP ], // T45687
'+mlwikisource' => [ 100 ],
'+nlwikisource' => [ 102 ],
'+nowikisource' => [ 102 ],
'+nowikibooks' => [ 102 ], // T274265
'+plwikisource' => [ 104, 124 ], // T154711
'+ptwikisource' => [ 102 ],
'+rowikisource' => [ 102 ], // Follow-up for T31190
'+srwikibooks' => [ 102, ], // T17282
'+srwikisource' => [ 100 ],
'+svwikisource' => [ 106 ],
'+tewikisource' => [ 102 ],
'+thwikibooks' => [ 104, 106 ], // T308376
'+thwikisource' => [ 102, 114 ], // T275282
'+trwikibooks' => [ 100, 110, ],
'+trwikisource' => [ 100 ],
'+ukwikibooks' => [ 102 ], // T310940
'+ukwikisource' => [ 102, 116 ], // T52561, T53684
'+vecwikisource' => [ 100 ],
'+viwikibooks' => [ 104, 106 ],
'+viwikisource' => [ 102 ],
'+wikitech' => [ NS_HELP, 116 ], // Tools - T122865
'+zhwikisource' => [ 102, 114 ], // T66127
'+zhwikiversity' => [ 100, 102, 104, 106, 108 ], // T201675, T212919 (106, 108)
'+dewikivoyage' => [ 104 ],
'+commonswiki' => [ 6 ], // T167077
'+testwikidatawiki' => [
120, // Property (T321282)
146, // So that Lexeme is indexed in the content index (Cirrus)
],
'+wikidatawiki' => [
120, // Property (T321282)
146, // So that Lexeme is indexed in the content index (Cirrus)
],
],
```
If an article is orphaned but is linked from any page (user page, talk page, etc.) then it is removed from Special:LonelyPages. I think it should only be removed from Special:LonelyPages if it is linked from another content page. If someone links to the page on a talk page, for example, that shouldn't be sufficient to "un-orphan" it since it's still orphaned as far as the encyclopedia content is concerned.
**Steps to replicate the issue** (include links if applicable):
* Log in with a user having a confirmed email
* Go to https://de.wikipedia.beta.wmflabs.org/wiki/Spezial:E-Mail_senden/Test1
* Go to https://de.wikipedia.beta.wmflabs.org/wiki/Spezial:E-Mail_senden?wpTarget=Test1
* Go to https://de.wikipedia.beta.wmflabs.org/wiki/Spezial:E-Mail_senden/NonExists
**What happens?**:
The form field is empty and no error is shown.
**What should have happened instead?**:
Expect the form field prefilled with "Test1" and the error message "This user has not specified a valid email address."
This happens when putting "Test1" into the empty field and submit
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
https://de.wikipedia.beta.wmflabs.org/wiki/Spezial:Aktive_Benutzer shows all the temp users from the last 30 days.
Would not expect them counted as active as that not the case when ips doing the edits
One fix should fix also {{NUMBEROFACTIVEUSERS}} and the count on Special:Statistics
Code is in `RecentChangesUpdateJob::updateActiveUsers`, needs to call isTemp on each `actor_name`
**Steps to replicate the issue** (include links if applicable):
* Navigate to Special:Log, e.g. [[ https://www.mediawiki.org/wiki/Special:Log | mw:Special:Log ]]
* Type an invalid title for the target, e.g. `>foo`
* Click `Show`
**What happens?**:
No error was given, and all logs are present below the form.
{F37091253}
**What should have happened instead?**:
Error about `contains invalid characters` should be given, and no logs shown.
{F37091269}
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
Go to https://en.wikipedia.org/wiki/Special:Log?type=renameuser&user=&page=User%3A%09Foo&wpdate=&tagfilter=&wpFormIdentifier=logeventslist
**What happens?**:
You get log entries for all renames
**What should have happened instead?**:
It should ignore the extraneous whitespace after the ":"
==== Error ====
* mwversion: 1.41.0-wmf.8
* reqId: 692e4c83-8f88-47f3-a37e-ef7a9753ee7c
* [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2023-05-15T15:17:48.283Z',to:'2023-05-16T15:19:37.475Z'))&_a=(query:(query_string:(query:'reqId:%22692e4c83-8f88-47f3-a37e-ef7a9753ee7c%22'))) | Find reqId in Logstash ]]
```name=normalized_message,lines=10
[{reqId}] {exception_url} Wikimedia\Assert\ParameterAssertionException: Bad value for parameter $title: should not be empty unless namespace is main
```
```name=exception.trace,lines=10
from /srv/mediawiki/php-1.41.0-wmf.8/vendor/wikimedia/assert/src/Assert.php(72)
#0 /srv/mediawiki/php-1.41.0-wmf.8/includes/title/TitleValue.php(190): Wikimedia\Assert\Assert::parameter(boolean, string, string)
#1 /srv/mediawiki/php-1.41.0-wmf.8/includes/title/TitleValue.php(144): TitleValue::assertValidSpec(integer, string, string, string)
#2 /srv/mediawiki/php-1.41.0-wmf.8/includes/specials/pagers/CategoryPager.php(97): TitleValue->__construct(integer, string)
#3 /srv/mediawiki/php-1.41.0-wmf.8/includes/pager/IndexPager.php(549): CategoryPager->formatRow(stdClass)
#4 /srv/mediawiki/php-1.41.0-wmf.8/includes/pager/IndexPager.php(586): IndexPager->getRow(stdClass)
#5 /srv/mediawiki/php-1.41.0-wmf.8/includes/specials/pagers/CategoryPager.php(93): IndexPager->getBody()
#6 /srv/mediawiki/php-1.41.0-wmf.8/includes/specials/SpecialCategories.php(78): CategoryPager->getBody()
#7 /srv/mediawiki/php-1.41.0-wmf.8/includes/specialpage/SpecialPage.php(701): MediaWiki\Specials\SpecialCategories->execute(NULL)
#8 /srv/mediawiki/php-1.41.0-wmf.8/includes/specialpage/SpecialPageFactory.php(1537): SpecialPage->run(NULL)
#9 /srv/mediawiki/php-1.41.0-wmf.8/includes/MediaWiki.php(328): MediaWiki\SpecialPage\SpecialPageFactory->executePath(string, RequestContext)
#10 /srv/mediawiki/php-1.41.0-wmf.8/includes/MediaWiki.php(925): MediaWiki->performRequest()
#11 /srv/mediawiki/php-1.41.0-wmf.8/includes/MediaWiki.php(579): MediaWiki->main()
#12 /srv/mediawiki/php-1.41.0-wmf.8/index.php(50): MediaWiki->run()
#13 /srv/mediawiki/php-1.41.0-wmf.8/index.php(46): wfIndexMain()
#14 /srv/mediawiki/w/index.php(3): require(string)
#15 {main}
```
==== Impact ====
* 830 hits in the last 2 weeks per [[ https://logstash.wikimedia.org/goto/79f0b317f363b325a441295ad73ed325 | logstash ]].
* Looks like only https://id.wikipedia.org/wiki/Istimewa:Daftar_kategori is affected.
* Appears to have started 2023-05-06 ([[ https://logstash.wikimedia.org/app/discover#/doc/logstash-*/logstash-deploy-1-7.0.0-1-2023.05.06?id=Mn618YcB1uRNVZD3SOaM | oldest entry ]]).
==== Notes ====
* This is the `Special:Categories` special page.
```
#2 /srv/mediawiki/php-1.41.0-wmf.5/includes/libs/rdbms/database/DBConnRef.php(119): Wikimedia\Rdbms\Database->query(string, string, integer)
#3 /srv/mediawiki/php-1.41.0-wmf.5/includes/libs/rdbms/database/DBConnRef.php(302): Wikimedia\Rdbms\DBConnRef->__call(string, array)
#4 /srv/mediawiki/php-1.41.0-wmf.5/includes/specials/SpecialShortPages.php(139): Wikimedia\Rdbms\DBConnRef->query(string, string)
#5 /srv/mediawiki/php-1.41.0-wmf.5/includes/specialpage/QueryPage.php(732): SpecialShortPages->reallyDoQuery(integer, integer)
```
This call to `->query()` is very special:
```lang=php
$sql = $dbr->unionConditionPermutations(
$tables,
$fields,
[ 'page_namespace' => $namespaces ],
$conds,
$fname,
$options,
$join_conds
);
// phpcs:ignore MediaWiki.Usage.DbrQueryUsage.DbrQueryFound
$res = $dbr->query( $sql, $fname );
```
According to codesearch, `Special:ShortPages` is the only caller of `unionConditionPermutations()`. Ideally, we would probably transform this method into one that does the query and returns results, instead of returning SQL; but perhaps it’s easier to just add the right `ISQLPlatform::QUERY_CHANGE_*` constant to the `->query()` call for now, to silence the deprecation warning.
**Feature summary** (what you would like to be able to do and where):
Short: The new feature from T174349 would be nice to have it on Special:NewPages as well.
On Special:NewPages is an option to filter the new pages for a change tag. Allow also to invert this search as possible on Special:RecentChanges and Special:WatchList.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
This can help to exclude redirect creation from the list
**Benefits** (why should this be implemented?):
Known filters have same options (inverttags)
**Feature summary** (what you would like to be able to do and where):
We have special pages like long pages, short pages, unused categories... I would like a big categories special page.
**Benefits** (why should this be implemented?):
It's good for maintanence, looking for categories that are subject to subcat them.
from:
https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2023/Miscellaneous/Change_year_range_shown_in_date_selection_popup
> Problem: In the Date selection popup, e.g. on the User contributions page after "To date:", if clicking Up Up (^ then ^), the list of years is the current and next decades (2020 to 2039). The next decade is unlikely to be required.
> Proposed solution: Please change the range of years displayed to the previous and current decades.
> Who would benefit: Users looking for contributions at dates earlier than 2020.
**Feature summary**:
As it currently stands, Special:ShortPages is completely useless in Wikisources. It's completely populated with purposefully blank pages (i.e.: blank pages from books) so it can't be used to find very short pages that might need supervision.
My feature wish would be to either:
- Filter out pages with proofread status 0 from the list (ideal)
- Be able to filter by namespace in special pages (T218350)
**Feature summary**
Redirect from Special:RenderPage/$1 to index.php?title=$1&action=render.
**Use cases**
1. (This is not specifically intended for use on WMF wikis) My personal, primary use case is setting a rendered page as MediaWiki:Mainpage. With this trick, it is possible to create a full main page without any navigation elements. Of course, this can be done with CSS too, but I think using Special:RenderPage is a more straight forward solution.
2. `[{{fullurl:An Article|action=render}} Render]` wikitext make an external link, and It seems to be harmful in some context to readers, while `[[Special:RenderPage/An Article]]` is an internal link.
**Steps to replicate the issue** (include links if applicable):
* Go to https://m.mediawiki.org/wiki/Special:Contributions/Hamdsaif
* notice the duplicate headers '1 March 2023' above '18 February 2023' and '11 February 2023' above '9 February 2023'
**What happens?**:
Double date headers on mobile (presumably do to the Flow edits?)
**What should have happened instead?**:
no double date headers
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
Chrome 110.0.5481.153 (Android)
When inspected the following HTML is present:
"<!-- Could not format Special:Contribution row. -->"
This inline comment was added by @Bawolff in ede90ac05abc in December 2012 but I'm not sure I understand the circumstances in which it occurs.
{F36907849}
**Steps to replicate the issue** (include links if applicable):
* Upload a file, then upload a second version of the same file.
* Look in your Uploads tab, https://commons.wikimedia.org/w/index.php?title=Special:ListFiles/Jidanni&ilshowall=1 is mine.
* Try to get a link to the first upload.
**What happens?**:
Both "(file)" links link to the new version,
https://upload.wikimedia.org/wikipedia/commons/3/3e/19940722epoplar.jpg
**What should have happened instead?**:
The older one should link to the older version:
https://upload.wikimedia.org/wikipedia/commons/archive/3/3e/20230304033700%2119940722epoplar.jpg
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
{F36891154}
Imagine you upload a picture of the letter A, then a newer version with the letter B.
Well, even though we still see A on the upload list, we can't get a link to it,
e.g., to ask someone to delete it.
Even though we are staring at a row with a picture of A in it,
all the links in that row are to B, just as if we were looking at the previous row.
The only difference is the
```
<img src=>
```
line.
Anyway, we might think we are giving an admin a link to the old version, but end up asking to delete the newer version!
Yes the File:xxx page does contain the proper links.
P.S.. please do your own experiment, as the older one I mentioned in this report are probably gone now.
**Steps to replicate the issue** (include links if applicable):
1. Visit https://zh.wikibooks.org/wiki/Special:captcha/image
**What happens?**:
Request Error
Requested bogus captcha image
**What should have happened instead?**:
Displays a special page interface for mediawiki.
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
**Steps to replicate the issue** (include links if applicable):
* Go to Special:Log
* Select "edit tags of selected log entries"
**What happens?**:
```
Deprecated: htmlspecialchars(): Passing null to parameter #1 ($string) of type string is deprecated in includes\parser\Sanitizer.php on line 859
from includes\parser\Sanitizer.php(859)
#0 includes\xml\Xml.php(76): Sanitizer::encodeAttribute(NULL)
#1 includes\xml\Xml.php(49): Xml::expandAttributes(array)
#2 includes\xml\Xml.php(292): Xml::element(string, array)
#3 includes\specials\SpecialEditTags.php(278): Xml::input(string, integer, NULL, array)
```
**What should have happened instead?**:
No deprecation message should be shown
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
After {T34892}, these two look odd
```
5 Installed libraries
6 Installed client-side libraries
```
There is potentially some renaming, and some changes to the heirarchy that need to come.
It's also more noticeable with the change for {T326126} applied