==== Error ====
* [[ https://logstash.wikimedia.org/app/discover#/doc/logstash-*/logstash-default-1-7.0.0-1-2024.04.16?id=V1wi5o4BWjhRzdxnz--_ | Logstash single document ]]
```name=message
ReferenceError: Can't find variable: wpReason
```
```name=trace,lines=10
at https://ja.wikipedia.org/w/index.php:94:73
at mightThrow https://ja.wikipedia.org/w/load.php:45:653
at https://ja.wikipedia.org/w/load.php:46:319
```
==== Impact ====
Unknown.
==== Notes ====
On my wiki, it seems that the recentChangesUpdate Job is very slow, even if only a few updates happened. I wonder if there is a way to prune/restructure the recentChanges table as the wiki has almost 30 million edits
```
2024-03-19 09:45:17 recentChangesUpdate Special:RecentChanges type=cacheUpdate namespace=-1 title=RecentChanges requestId=566c41c175500062e0fe0644 (uuid=e4e66db8034741569f0c7d879fd06247,timestamp=1710841517) STARTING
2024-03-19 09:51:15 recentChangesUpdate Special:RecentChanges type=cacheUpdate namespace=-1 title=RecentChanges requestId=566c41c175500062e0fe0644 (uuid=e4e66db8034741569f0c7d879fd06247,timestamp=1710841517) t=358600 good
```
Details on why this is occurring and how team's can fix this are provided on T356434
**Steps to replicate the issue** (include links if applicable):
* Enable https://chromewebstore.google.com/detail/wcag-color-contrast-check/plnahcmalebffmaghcpcmpaciebdhgdf Chrome extension
* Visit https://en.m.wikipedia.beta.wmflabs.org/w/index.php?title=Special:Homepage&minervanightmode=1&namespace=0
**What happens?**:
10 color contrast issues:
** OOUI form at top of page
** T358406
** T358402
**What should have happened instead?**:
No color contrast issues
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
Sending thanks from page history is an inline two-step operation. Thanks from the recent changes also works like this, except if 'Live changes' is enabled or the user has selected the "View new changes since..." button. In these cases, the page opens up a new page for confirmation, quite unnecessarily.
Thanks behaviour (working in-line) should not change based on these links being clicked.
**Request**Hello, Would it be possible to add the tags "previously undone edit", "possible edit war" and "likely repeated vandalism". All would be activated in slightly different ways, the first would be activated when the same user undos the reversion of their original edit; the second would be activated when 2 separate versions of a revision are rapidly changed between; the third would be an escalation for the first, a high ORES score edit being consistently reverted and re-added. (what you would like to be able to do and where):
**Discovery** I discovered this lack of issue when I was monitoring recent changes and realized that there was no way to easily identify issues that can be overlooked despite needing a quick solution.(
**Benefits** Would make finding problem edits that are repeated much easier, due to the tags flagging them for review.
NOTE: It will likely be easier to first convert these pages to HTMLForm and OOUI form before transitioning to Codex. See T99256, T117740, and T117741.
**Steps to replicate the issue** (include links if applicable):
* Visit https://en.wikipedia.org/wiki/Special:RecentChanges?damaging=likelybad&hidebots=1&hidecategorization=1&hideWikibase=1&limit=50&days=7&enhanced=1&damaging__likelybad_color=c4&damaging__verylikelybad_color=c5&useskin=minerva&urlversion=2 with JS disabled or https://en.wikipedia.org/wiki/Special:Watchlist?useskin=minerva
**What happens?**:
Form appears unstyled
**What should have happened instead?**:
Form should use our standard styles for buttons and input elements
** Note **
The issue is more obvious on Minerva which has a CSS reset file (T205341) but the fundamental issue here is the form is not consistent with the rest of our interfaces.
**Feature summary**: I would like to be able to target **mw-newpages-history** and **mw-newpages-edit** simultaneously with CSS to style them differently.
**Use case(s)**: I was trying to style the output of Special:NewPages. In it there are 2 groups of classes which make use of text elements such as parentheses and pipes. **mw-usertoollinks-talk** and **mw-usertoollinks-contribs** are part of the **mw-usertoollinks**.
**mw-newpages-history** and **mw-newpages-edit** are not part of any unique class and thus, if you for some reason want to change them with CSS, you are left with the parentheses, space and pipe characters behind unchanged.
**Benefits**: The photo shows what is currently on the main page of my homewiki (SqWiki). As it can be seen, the parentheses, spaces and pipe characters are left behind after hiding some classes in Special:NewPages' output, with no way to target them with CSS.
{F41509843}
See https://en.wikipedia.org/w/api.php?hidebots=1&hidecategorization=1&hideWikibase=1&namespace=all-discussions&urlversion=2&days=30&limit=50&action=feedrecentchanges&feedformat=atom
Result:
```
lang=json
{
"error": {
"code": "badvalue",
"info": "Unrecognized value for parameter \"namespace\": all-discussions.",
"*": "See https://en.wikipedia.org/w/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes."
},
"servedby": "mw-api-ext.codfw.main-588d84fdc-9lnnz"
}
```
Not sure what's happening, but on November 2 on all wikis where I have either en.wikipedia.org/w/index.php?title=User:Bradv/Scripts/ExpandDiffs.js or en.wikipedia.org/w/index.php?title=User:Writ Keeper/Scripts/commonHistory.js loaded the mw-userlink elements are out of order / misplaced on narrow screens (mobile).
I'll post screenshots.
Were there any related changes to MediaWiki that could be causing this?
Open console from the recent changes page in "live updates" mode. "wikipage.content hook should not be fired on unattached content" warning is shown.
**Steps to replicate the issue** (include links if applicable):
# Watchlist some pages with recent logged actions (e.g., upload).
- Have some pages watched permanently and some temporarily.
# Open Special:RecentChanges with "Group results by page" disabled.
**What happens?**:
The formatting is different for the watched pages.
Example: Instead of "(Upload log); HH:MM ...", it is "(Upload log). . HH:MM ..."
However, the formatting is consistent for temporarily watched pages, but the ordinary icon (clock) is not displayed.
**What should have happened instead?**:
- The formatting of logged actions is consistent for watched and non-watched pages.
- The clock icon is displayed for temporarily watched pages.
**Other information** (browser name/version, screenshots, etc.):
{F37588519}
The filters in the advanced Special:RecentChanges / Special:Watchlist interface should be available in the corresponding API endpoints as well.
At Fandom, we allow users to use limit above default 500 on RecentChanges pages. Our default `$wgRCLinkLimits` is set to
```
$wgRCLinkLimits = [ 50, 100, 250, 500, 1000, 2000, 3000, 4000 ];
```
Over the past few MW versions, we saw slight degradation of load times for this page and we needed to lower the limit to fit into the `15s` timeout that we have set for all requests. With our investigation with the profiler, it turned out that most of the time for the process is spent on rendering the same "UserLinks" and "Tags", as this is often the case that few active users will make most of the changes or the same tag is visible on RC record. This can be easily and safely optimized with the process cache (eg. MapCacheLRU), used inside the RC rendering.
Below are (not very scientific) response times before and after, we applied the optimisation on the 1.39 version of MW.
For the simple test, we have used popular wiki, where we were varying the limit value:
* https://vsbattles.fandom.com/wiki/Special:RecentChanges?hidebots=1&reviewStatus=unpatrolled&limit=1000&days=90&enhanced=1&urlversion=2
and here are the results:
**Before**
```
### 1000 Records
### 6171ms
### 7335ms
### 6789ms
### 2000 Records
### 12410ms
### 12951ms
### 12976ms
### 3000 Records
### No results means above 15seconds, which looking at jump
### on 1000 to 2000 would finish in ~18seconds
```
**After**
```
### 1000 Records
### 4072ms
### 4021ms
### 3826ms
### 4150ms
### 2000 Records
### 6906ms
### 6644ms
### 6511ms
### 3000 Records
### 9108ms
### 9564ms
### 4000 Records
### 11349ms
### 11763ms
### 5000 Records
### 14555ms
### 14870ms
```
**Steps to replicate the issue**:
I don't know what caused this but one of my file uploads is missing from RecentChanges list and so total changes count is minus 1.
**What happens?**:
Here is the related file that's missing from changes lists: https://tr.riseonline.wiki/index.php/Dosya:Icon_Item_Hell%27s_Scream.png
As you can see, it's date is 13 June 2023 (13 Haziran 2023 in Turkish).
And now, see the RecentChanges list: https://tr.riseonline.wiki/index.php/%C3%96zel:SonDe%C4%9Fi%C5%9Fiklikler
But on 13 June 2023, there is only it's page (https://tr.riseonline.wiki/index.php/Hell%27s_Scream) is listed in RecentChanges list (**Özel:SonDeğişiklikler** in Turkish, meaning Special:RecentChanges). I was uploaded the file just before creating the page.
I'm using a wiki farm. Both of my wikis always had exact same change count, this is how I realized this issue.
TR: https://tr.riseonline.wiki/index.php/Anasayfa
EN: https://en.riseonline.wiki/index.php/Main_Page
Anyone knows how to fix this issue? I know it's not a big deal, but important for me.
**What should have happened instead?**:
Change counts should have to be right.
**Software version** (skip for WMF-hosted wikis like Wikipedia):
MW 1.39.1
**Steps to replicate the issue** (include links if applicable):
* Go to https://meta.wikimedia.org/w/index.php?limit=50&days=30&title=Special:RecentChanges&urlversion=2
*
*
**What happens?**:
* Only a small subset of changes are shown (screen shot below)
**What should have happened instead?**:
* All of the recent changes matching the selection criteria should be shown
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
{F37026172}
Watchlist without JS: {F36957370}
Watchlist with JS: {F36957366}
For some reason it has this strange CSS rule:
```
.client-js .mw-changeslist ul, .client-js .mw-changeslist table.mw-enhanced-rc {
margin-left: calc((6px + 3px) * 5 + 0.35714286em);
}
```
This takes up a lot of usable space, which is especially critical for Vector 2022.
RCFilters is a large app written in OOUI. We should port it to Codex, which should have most of the required components at this point. To the extent it doesn't, we should implement those components in RCFilters, and upstream them to Codex afterwards.
RCFilters also has complex state management, and would benefit from using Pinia(*).
(*) Pinia is now available in MediaWiki, see T326174.
**Steps to replicate the issue** (include links if applicable):
* Use the improved RC/Watchlist or whatever it's called
* Don't use a mouse
* Try to use the tab key to select a link in the list of changes
**What happens?**:
* When you tab through the page and you get to the "Filter changes" field, it automatically opens a selection of filters.
* When you press tab again, the top filter is automatically selected
* When you press tab yet again, the list of changes updates to apply the filter you "selected" in the previous tab, and the entire list of changes is changed, so that what you initially intended to tab to (maybe?) no longer is there
**What should have happened instead?**:
* Tabbing through the page should not trigger a change in what filters are applied
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
=== User story
As a mobile-first editor, I want to automatically have likely problem edits highlighted in Special:RecentChanges, so that I don't need to select this option every time I review recent edits.
=== Description
In T314026 we logged two separate but related problems with ORES in mobile recent changes. That ticket has been re-scoped to the highlighting aspect of ORES filters not working. In this ticket, we also want to fix the issue of the preference selection not automatically selecting the filters as expected.
In the Recent Changes and Watchlist tabs in Preferences, the `Highlight likely problem edits with colors and an "r" for "needs review"` preference has no effect in mobile web, even with #advanced_mobile_contributions turned on. `Show only likely problem edits` does work as expected.
**Desktop** (recent changes)
With the setting turned on, 'Likely have problems' and 'Very likely have problems' should be automatically selected when navigating to Special:RecentChanges and the feed should look like this:
{F35377212}
**Mobile web** (recent changes)
On mobile, the filters are not automatically selected:
{F35377216}
=== Technical description
>>! In T314026#8322692, @Jdlrobson wrote:
> The highlighting code works fine on desktop Minerva so you can rule out skins right away:
> [...]
> That means the highlighting is not working correctly with MobileFrontend.
> Usually this is because of two things:
> - A MobileFrontend hook is being called to disable the feature
> - The relevant code has a client side check that stops it loading
> - The relevant code is not being loaded because the ResourceLoader module does not add a targets property.
> I see that the relevant module is loaded on mobile mw.loader.using('mediawiki.rcfilters.filters.ui') so it's likely something inside that module is not running on mobile.
> [...]
> my suggestion would be to add debugging steps to this module and identify where the code is exiting early on mobile site. I am not familiar with the RecentChanges code and how it works, but at one point there was a common pattern within Wikimedia development to explicitly not run code on mobile to reduce scope for releases and I imagine that's what happened here.
=== Testing and QA steps
- Log in to a Wikipedia account
- Navigate to Special:Preferences, to the Recent Changes tab, and select the `Highlight likely problem edits with colors and an "r" for "needs review"` preference
- Navigate to Special:RecentChanges
- In the Filters drop-down, the 'Likely have problems' and 'Very likely have problems' filters should be selected.
- Similarly, the same preference in the Watchlist tab should have the same effect on Special:Watchlist
=== Acceptance criteria
- When the preferences described above are selected, the 'Likely have problems' and 'Very likely have problems' filters should be selected on Special:RecentChanges and Special:Watchlist
There are two user preferences to "Use non-JavaScript interface": in watchlist and recent changes. They are `rcenhancedfilters-disable` and `wlenhancedfilters-disable`.
Is the purpose of these to disable any JavaScript on these special pages? Or is it just to turn off the enhanced filters?
The label makes it sound like the former, but the help text is more about the latter: "Loads recent changes and related changes without the filtered search or the highlighting functionality."
This matters because if it's about not using JavaScript to create interactive UI on these pages then it should probably be respected by other things (for instance, #expiring-watchlist-items adds "days left" to expiring watchlist items).
Suggestion: change the label to just be about the enhanced filters.
**Summary:** Please add a new filter for `Special:RecentChanges` to filter changes made to unwatched pages.
**Issue:** `Special:UnwatchedPages` is barely helpful for administrators on large wikis (e.g. eswiki) where it has thousands and thousands of entries (the cache is limited to 5,000 results as well). It was suggested on-wiki that it'd be more useful if we could patrol changes to these pages via `Special:RecentChanges` or, in the alternative, a dedicated special page.
**Request:** For users with `unwatchedpages` permissions, please allow a new filter option on `Special:RecentChanges` to list/filter/highlight changes made to unwatched pages.
Thank you.
Message concatenation is a bad practice and should not be used
See https://www.mediawiki.org/wiki/Help:System_message#Avoid_fragmented_or_'patchwork'_messages
----
**Message URL**: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=newpages-showhide-bots&group=core&language=uk
==== Error ====
* mwversion: `undefined`
* reqId: `undefined`
* [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2022-05-09T09:25:09.444Z',to:'2022-05-10T09:25:09.444Z'))&_a=(query:(query_string:(query:'reqId:%22undefined%22'))) | Find reqId in Logstash ]]
```name=normalized_message
SecurityError: Attempt to use history.replaceState() more than 100 times per 30 seconds
```
```
name=exception.trace,lines=10
at https://de.wikipedia.org/w/load.php?lang=de&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets%7Cmediawiki.rcfilters.filters.ui%7Cmediawiki.special%2Cwidgets%7Cmediawiki.special.changeslist.legend.js%7Cmediawiki.special.changeslist.watchlistexpiry%7Cmediawiki.special.recentchanges%7Coojs-ui-windows.icons%7Coojs-ui.styles.icons-content%2Cicons-editing-core%2Cicons-editing-styling%2Cicons-layout%2Cicons-media%2Cicons-moderation&skin=vector&version=1lr8x:425:985\nat https://de.wikipedia.org/w/load.php?lang=de&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets%7Cmediawiki.rcfilters.filters.ui%7Cmediawiki.special%2Cwidgets%7Cmediawiki.special.changeslist.legend.js%7Cmediawiki.special.changeslist.watchlistexpiry%7Cmediawiki.special.recentchanges%7Coojs-ui-windows.icons%7Coojs-ui.styles.icons-content%2Cicons-editing-core%2Cicons-editing-styling%2Cicons-layout%2Cicons-media%2Cicons-moderation&skin=vector&version=1lr8x:427:744\nat https://de.wikipedia.org/w/load.php?lang=de&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets%7Cmediawiki.rcfilters.filters.ui%7Cmediawiki.special%2Cwidgets%7Cmediawiki.special.changeslist.legend.js%7Cmediawiki.special.changeslist.watchlistexpiry%7Cmediawiki.special.recentchanges%7Coojs-ui-windows.icons%7Coojs-ui.styles.icons-content%2Cicons-editing-core%2Cicons-editing-styling%2Cicons-layout%2Cicons-media%2Cicons-moderation&skin=vector&version=1lr8x:422:89\nat https://de.wikipedia.org/w/load.php?lang=de&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets%7Cmediawiki.rcfilters.filters.ui%7Cmediawiki.special%2Cwidgets%7Cmediawiki.special.changeslist.legend.js%7Cmediawiki.special.changeslist.watchlistexpiry%7Cmediawiki.special.recentchanges%7Coojs-ui-windows.icons%7Coojs-ui.styles.icons-content%2Cicons-editing-core%2Cicons-editing-styling%2Cicons-layout%2Cicons-media%2Cicons-moderation&skin=vector&version=1lr8x:415:185\nat https://de.wikipedia.org/w/load.php?lang=de&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets%7Cmediawiki.rcfilters.filters.ui%7Cmediawiki.special%2Cwidgets%7Cmediawiki.special.changeslist.legend.js%7Cmediawiki.special.changeslist.watchlistexpiry%7Cmediawiki.special.recentchanges%7Coojs-ui-windows.icons%7Coojs-ui.styles.icons-content%2Cicons-editing-core%2Cicons-editing-styling%2Cicons-layout%2Cicons-media%2Cicons-moderation&skin=vector&version=1lr8x:523:832\nat https://de.wikipedia.org/wiki/Spezial:Letzte_%C3%84nderungen:204:661\nat https://de.wikipedia.org/wiki/Spezial:Letzte_%C3%84nderungen:204:661\nat https://de.wikipedia.org/w/load.php?lang=de&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets%7Cmediawiki.rcfilters.filters.ui%7Cmediawiki.special%2Cwidgets%7Cmediawiki.special.changeslist.legend.js%7Cmediawiki.special.changeslist.watchlistexpiry%7Cmediawiki.special.recentchanges%7Coojs-ui-windows.icons%7Coojs-ui.styles.icons-content%2Cicons-editing-core%2Cicons-editing-styling%2Cicons-layout%2Cicons-media%2Cicons-moderation&skin=vector&version=1lr8x:518:906\nat https://de.wikipedia.org/wiki/Spezial:Letzte_%C3%84nderungen:204:661\nat https://de.wikipedia.org/w/load.php?lang=de&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets%7Cmediawiki.rcfilters.filters.ui%7Cmediawiki.special%2Cwidgets%7Cmediawiki.special.changeslist.legend.js%7Cmediawiki.special.changeslist.watchlistexpiry%7Cmediawiki.special.recentchanges%7Coojs-ui-windows.icons%7Coojs-ui.styles.icons-content%2Cicons-editing-core%2Cicons-editing-styling%2Cicons-layout%2Cicons-media%2Cicons-moderation&skin=vector&version=1lr8x:242:82\nat https://de.wikipedia.org/w/load.php?lang=de&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets%7Cmediawiki.rcfilters.filters.ui%7Cmediawiki.special%2Cwidgets%7Cmediawiki.special.changeslist.legend.js%7Cmediawiki.special.changeslist.watchlistexpiry%7Cmediawiki.special.recentchanges%7Coojs-ui-windows.icons%7Coojs-ui.styles.icons-content%2Cicons-editing-core%2Cicons-editing-styling%2Cicons-layout%2Cicons-media%2Cicons-moderation&skin=vector&version=1lr8x:235:261
```
==== Impact ====
5 events as per May 10th
Recentchanges table powers one of core functionalities of Wikipedia and Co. It is the basically the backbone of every patrolling tool. From Special:RecentChanges to Watchlist to Huggle, and so on.
Since most of these tools provide a practically free-form SQL query builder, it easily can lead to "full table scan" queries. That is partially part of the design of rc table. It should small and nimble but pretty hot and being read in different ways as it has 10 indexes atm. The problem starts when a wiki gets really large due to bot edits or just the size of the wiki. For example Wikidata's rc table right now has 22M rows which is clearly bigger than what it should be. Currently, only three wikis have issues with recentchanges table: English Wikipedia, Wikidata, and Wikimedia Commons.
Here are several bugs caused by rc table getting large:
- {T276699}
- {T239192}
It is also blocking adding more features such as {T179010}
The underlying problem is that RC table is trying to juggle two things:
- Vandalism and problematic edits detection, which requires complex queries on non-patrolled edits (which are a small subset of edits). e.g. get me all edits that have high ores score but also certain tag.
- General pulse check of what's going on. For example, watchlist (=What is happening on pages I care about). This requires seeing all edits but on a more simpler, narrower query. No complex magic but needing the firehose of edits.
Proposed solutions (some mutually exclusive, some not):
# Normalizing the table: This is not a good design and won't help much. This table is the de-normalization table of mediawiki. It's a summary table.
# Reduce the time of storage rc actions in large wikis. Currently it's 30 days. This number has not came from any research and it's used just because it's round. In my role of Wikipedia volunteer, I barely went to older than a week.
# Split autopatrolled[1] actions out of rc table, into something like patrolled_recentchanges. In which querying it would be much limited (e.g. no tag filtering, no ores scores filtering, etc.)
# Reduce the time to store autopatrolled actions. This is basically hybrid of solution 2 & 3. That way we reduce the size without losing much.
# Store one week of data in one table, the rest of the month in another table (or one week for the first table and all of the month in the other meaning first week would get duplicated.) and make the query on the second table more restricted For example no tag filtering, no ores filtering, etc.
# Move it to a NoSQL solution. While I can see the reasoning, I'm not sure it would fix anything. These massive firehose of data would be slow to query in any system.
## That being said, Using Elastic sounds like a good idea (see T307328#7894820)
[1] "autopatrolled" can be useful for wikidata and commons only because "RC patrolling" is not enabled in English Wikipedia. RCPatrolling is a feature of mediawiki to find vandalism and reduce the work of patrollers in English Wikipedia. I find it disheartening it's not enabled there (which can be done with a bit community consultation and small design fixes)
**List of steps to reproduce** (step by step, including full links if applicable):
* Create a large number of namespaces (~500).
* Visit either Special:Watchlist or Special:RecentChanges
**What happens?**:
The browser becomes very unresponsive and the enhanced filters can take up to a minute to fully load. Interacting with the filters also becomes tediously slow.
This happens because of the extreme complexity of the DOM with OOUI and such a large number of namespaces. It takes the browser a long time to generate and render the resulting elements.
**What should have happened instead?**:
The web page is responsive and the filters load in a reasonable amount of time. This can possibly be achieved by lazy-loading the namespace filters.
**Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.**:
MediaWiki 1.35.6 with enhanced filters enabled.
Seen on eswiki https://es.wikipedia.org/wiki/Special:Recentchanges?hidebots=1&hidecategorization=1&hideWikibase=1&limit=500&days=7&urlversion=2, stack trace:
```
at checkUserlist/</< https://es.wikipedia.org/w/load.php?lang=es&modules=ext.gadget.CorrectorOrtografico%2CDetectaDesambiguaciones%2CReferenceTooltips%2CUTCLiveClock%2Ca-commons-directo%2Cbotonera%2Cdeluxe-history%2Cdiff-enlaces%2Cswitcher%2Ctab-oculta-atendidas%2Cver-subpaginas&skin=monobook&version=3f42p:50:830
at fire https://es.wikipedia.org/w/load.php?lang=es&modules=ext.centralNotice.geoIP%7Cext.centralauth.ForeignApi%7Cext.centralauth.centralautologin.clearcookie%7Cext.cx.entrypoints.contributionsmenu%7Cext.cx.eventlogging.campaigns%7Cext.cx.icons%7Cext.cx.widgets.callout%7Cext.echo.api%2Cinit%7Cext.eventLogging%2CnavigationTiming%2CwikimediaEvents%7Cext.uls.common%2Ccompactlinks%2Cinterface%2Cpreferences%2Cwebfonts%7Cjquery%2Coojs%2Coojs-ui-core%2Coojs-ui-widgets%2Csite%7Cjquery.client%2Ccookie%2CmakeCollapsible%2CtextSelection%2Cui%7Cjquery.uls.data%7Cmediawiki.ForeignApi%2CString%2CTitle%2CUri%2Capi%2Cbase%2Ccldr%2Ccookie%2Cexperiments%2CjqueryMsg%2Clanguage%2Cspecial%2Cstorage%2Ctemplate%2Cuser%2Cutil%2CvisibleTimeout%2Cwidgets%7Cmediawiki.ForeignApi.core%7Cmediawiki.editfont.styles%7Cmediawiki.language.specialCharacters%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%7Cmediawiki.rcfilters.filters.ui%7Cmediawiki.special.changeslist.legend.js%7Cmediawiki.special.changeslist.watchlistexpiry%7Cmediawiki.special.recentchanges%7Cmediawiki.ui.button%2Cicon%7Coojs-ui-widgets.icons%7Coojs-ui-windows.icons%7Coojs-ui.styles.icons-content%2Cicons-editing-advanced%2Cicons-editing-citation%2Cicons-editing-core%2Cicons-editing-list%2Cicons-editing-styling%2Cicons-interactions%2Cicons-layout%2Cicons-media%2Cicons-moderation%7Cskins.monobook.scripts&skin=monobook&version=106i3:173:934
at fireWith https://es.wikipedia.org/w/load.php?lang=es&modules=ext.centralNotice.geoIP%7Cext.centralauth.ForeignApi%7Cext.centralauth.centralautologin.clearcookie%7Cext.cx.entrypoints.contributionsmenu%7Cext.cx.eventlogging.campaigns%7Cext.cx.icons%7Cext.cx.widgets.callout%7Cext.echo.api%2Cinit%7Cext.eventLogging%2CnavigationTiming%2CwikimediaEvents%7Cext.uls.common%2Ccompactlinks%2Cinterface%2Cpreferences%2Cwebfonts%7Cjquery%2Coojs%2Coojs-ui-core%2Coojs-ui-widgets%2Csite%7Cjquery.client%2Ccookie%2CmakeCollapsible%2CtextSelection%2Cui%7Cjquery.uls.data%7Cmediawiki.ForeignApi%2CString%2CTitle%2CUri%2Capi%2Cbase%2Ccldr%2Ccookie%2Cexperiments%2CjqueryMsg%2Clanguage%2Cspecial%2Cstorage%2Ctemplate%2Cuser%2Cutil%2CvisibleTimeout%2Cwidgets%7Cmediawiki.ForeignApi.core%7Cmediawiki.editfont.styles%7Cmediawiki.language.specialCharacters%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%7Cmediawiki.rcfilters.filters.ui%7Cmediawiki.special.changeslist.legend.js%7Cmediawiki.special.changeslist.watchlistexpiry%7Cmediawiki.special.recentchanges%7Cmediawiki.ui.button%2Cicon%7Coojs-ui-widgets.icons%7Coojs-ui-windows.icons%7Coojs-ui.styles.icons-content%2Cicons-editing-advanced%2Cicons-editing-citation%2Cicons-editing-core%2Cicons-editing-list%2Cicons-editing-styling%2Cicons-interactions%2Cicons-layout%2Cicons-media%2Cicons-moderation%7Cskins.monobook.scripts&skin=monobook&version=106i3:175:135
at done https://es.wikipedia.org/w/load.php?lang=es&modules=ext.centralNotice.geoIP%7Cext.centralauth.ForeignApi%7Cext.centralauth.centralautologin.clearcookie%7Cext.cx.entrypoints.contributionsmenu%7Cext.cx.eventlogging.campaigns%7Cext.cx.icons%7Cext.cx.widgets.callout%7Cext.echo.api%2Cinit%7Cext.eventLogging%2CnavigationTiming%2CwikimediaEvents%7Cext.uls.common%2Ccompactlinks%2Cinterface%2Cpreferences%2Cwebfonts%7Cjquery%2Coojs%2Coojs-ui-core%2Coojs-ui-widgets%2Csite%7Cjquery.client%2Ccookie%2CmakeCollapsible%2CtextSelection%2Cui%7Cjquery.uls.data%7Cmediawiki.ForeignApi%2CString%2CTitle%2CUri%2Capi%2Cbase%2Ccldr%2Ccookie%2Cexperiments%2CjqueryMsg%2Clanguage%2Cspecial%2Cstorage%2Ctemplate%2Cuser%2Cutil%2CvisibleTimeout%2Cwidgets%7Cmediawiki.ForeignApi.core%7Cmediawiki.editfont.styles%7Cmediawiki.language.specialCharacters%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%7Cmediawiki.rcfilters.filters.ui%7Cmediawiki.special.changeslist.legend.js%7Cmediawiki.special.changeslist.watchlistexpiry%7Cmediawiki.special.recentchanges%7Cmediawiki.ui.button%2Cicon%7Coojs-ui-widgets.icons%7Coojs-ui-windows.icons%7Coojs-ui.styles.icons-content%2Cicons-editing-advanced%2Cicons-editing-citation%2Cicons-editing-core%2Cicons-editing-list%2Cicons-editing-styling%2Cicons-interactions%2Cicons-layout%2Cicons-media%2Cicons-moderation%7Cskins.monobook.scripts&skin=monobook&version=106i3:257:524
at send/callback/< https://es.wikipedia.org/w/load.php?lang=es&modules=ext.centralNotice.geoIP%7Cext.centralauth.ForeignApi%7Cext.centralauth.centralautologin.clearcookie%7Cext.cx.entrypoints.contributionsmenu%7Cext.cx.eventlogging.campaigns%7Cext.cx.icons%7Cext.cx.widgets.callout%7Cext.echo.api%2Cinit%7Cext.eventLogging%2CnavigationTiming%2CwikimediaEvents%7Cext.uls.common%2Ccompactlinks%2Cinterface%2Cpreferences%2Cwebfonts%7Cjquery%2Coojs%2Coojs-ui-core%2Coojs-ui-widgets%2Csite%7Cjquery.client%2Ccookie%2CmakeCollapsible%2CtextSelection%2Cui%7Cjquery.uls.data%7Cmediawiki.ForeignApi%2CString%2CTitle%2CUri%2Capi%2Cbase%2Ccldr%2Ccookie%2Cexperiments%2CjqueryMsg%2Clanguage%2Cspecial%2Cstorage%2Ctemplate%2Cuser%2Cutil%2CvisibleTimeout%2Cwidgets%7Cmediawiki.ForeignApi.core%7Cmediawiki.editfont.styles%7Cmediawiki.language.specialCharacters%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%7Cmediawiki.rcfilters.filters.ui%7Cmediawiki.special.changeslist.legend.js%7Cmediawiki.special.changeslist.watchlistexpiry%7Cmediawiki.special.recentchanges%7Cmediawiki.ui.button%2Cicon%7Coojs-ui-widgets.icons%7Coojs-ui-windows.icons%7Coojs-ui.styles.icons-content%2Cicons-editing-advanced%2Cicons-editing-citation%2Cicons-editing-core%2Cicons-editing-list%2Cicons-editing-styling%2Cicons-interactions%2Cicons-layout%2Cicons-media%2Cicons-moderation%7Cskins.monobook.scripts&skin=monobook&version=106i3:261:167
```
It looks ilke it comes from MediaWiki:Gadget-DeluxeHistory.js on eswiki.
==== Error ====
* mwversion: `1.38.0-wmf.26`
* reqId: `4ea30499-4ecc-4b6c-9a6a-481ea21f8ca9`
* [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2022-03-16T14:29:01.000Z',to:'2022-03-17T15:26:26.288Z'))&_a=(query:(query_string:(query:'reqId:%224ea30499-4ecc-4b6c-9a6a-481ea21f8ca9%22'))) | Find reqId in Logstash ]]
```name=normalized_message
[{reqId}] {exception_url} PHP Deprecated: Caller from TranslatablePage::getTag ignored an error originally raised from SpecialRecentChanges::doMainQuery: [1969] Query execution was interrupted (max_statement_time exceeded) (db1166)
```
```name=exception.trace,lines=10
from /srv/mediawiki/php-1.38.0-wmf.26/includes/debug/MWDebug.php(377)
#0 [internal function]: MWExceptionHandler::handleError(integer, string, string, integer, array)
#1 /srv/mediawiki/php-1.38.0-wmf.26/includes/debug/MWDebug.php(377): trigger_error(string, integer)
#2 /srv/mediawiki/php-1.38.0-wmf.26/includes/db/MWLBFactory.php(436): MWDebug::sendRawDeprecated(string, boolean, string)
#3 [internal function]: MWLBFactory::logDeprecation(string)
#4 /srv/mediawiki/php-1.38.0-wmf.26/includes/libs/rdbms/database/TransactionManager.php(215): call_user_func(array, string)
#5 /srv/mediawiki/php-1.38.0-wmf.26/includes/libs/rdbms/database/Database.php(1548): Wikimedia\Rdbms\TransactionManager->assertTransactionStatus(Wikimedia\Rdbms\DatabaseMysqli, array, string)
#6 /srv/mediawiki/php-1.38.0-wmf.26/includes/libs/rdbms/database/Database.php(1221): Wikimedia\Rdbms\Database->assertQueryIsCurrentlyAllowed(string, string)
#7 /srv/mediawiki/php-1.38.0-wmf.26/includes/libs/rdbms/database/Database.php(1953): Wikimedia\Rdbms\Database->query(string, string, integer)
#8 /srv/mediawiki/php-1.38.0-wmf.26/includes/libs/rdbms/database/Database.php(1792): Wikimedia\Rdbms\Database->select(string, string, array, string, array, array)
#9 /srv/mediawiki/php-1.38.0-wmf.26/includes/libs/rdbms/database/DBConnRef.php(69): Wikimedia\Rdbms\Database->selectField(string, string, array, string, array)
#10 /srv/mediawiki/php-1.38.0-wmf.26/includes/libs/rdbms/database/DBConnRef.php(306): Wikimedia\Rdbms\DBConnRef->__call(string, array)
#11 /srv/mediawiki/php-1.38.0-wmf.26/extensions/Translate/tag/TranslatablePage.php(410): Wikimedia\Rdbms\DBConnRef->selectField(string, string, array, string, array)
#12 /srv/mediawiki/php-1.38.0-wmf.26/extensions/Translate/tag/TranslatablePage.php(351): TranslatablePage->getTag(string)
#13 /srv/mediawiki/php-1.38.0-wmf.26/extensions/Translate/tag/TranslatablePage.php(651): TranslatablePage->getMarkedTag()
#14 /srv/mediawiki/php-1.38.0-wmf.26/extensions/Translate/tag/PageTranslationHooks.php(169): TranslatablePage::isTranslationPage(Title)
#15 /srv/mediawiki/php-1.38.0-wmf.26/includes/HookContainer/HookContainer.php(338): PageTranslationHooks::fetchTranslatableTemplateAndTitle(Title, Title, boolean, NULL)
#16 /srv/mediawiki/php-1.38.0-wmf.26/includes/HookContainer/HookContainer.php(137): MediaWiki\HookContainer\HookContainer->callLegacyHook(string, array, array, array)
#17 /srv/mediawiki/php-1.38.0-wmf.26/includes/HookContainer/HookRunner.php(974): MediaWiki\HookContainer\HookContainer->run(string, array)
#18 /srv/mediawiki/php-1.38.0-wmf.26/includes/parser/Parser.php(3643): MediaWiki\HookContainer\HookRunner->onBeforeParserFetchTemplateRevisionRecord(Title, Title, boolean, NULL)
#19 /srv/mediawiki/php-1.38.0-wmf.26/includes/parser/Parser.php(3579): Parser->statelessFetchTemplate(Title, Parser)
#20 /srv/mediawiki/php-1.38.0-wmf.26/includes/parser/Parser.php(3473): Parser->fetchTemplateAndTitle(Title)
#21 /srv/mediawiki/php-1.38.0-wmf.26/includes/parser/Parser.php(3212): Parser->getTemplateDom(Title)
#22 /srv/mediawiki/php-1.38.0-wmf.26/includes/parser/PPFrame_Hash.php(276): Parser->braceSubstitution(array, PPFrame_Hash)
#23 /srv/mediawiki/php-1.38.0-wmf.26/includes/parser/Parser.php(2932): PPFrame_Hash->expand(PPNode_Hash_Tree, integer)
#24 /srv/mediawiki/php-1.38.0-wmf.26/includes/parser/Parser.php(1579): Parser->replaceVariables(string)
#25 /srv/mediawiki/php-1.38.0-wmf.26/includes/parser/Parser.php(697): Parser->internalParse(string)
#26 /srv/mediawiki/php-1.38.0-wmf.26/includes/cache/MessageCache.php(1323): Parser->parse(string, Title, ParserOptions, boolean)
#27 /srv/mediawiki/php-1.38.0-wmf.26/includes/specials/SpecialRecentChanges.php(735): MessageCache->parse(string, Title, boolean, boolean, LanguageEn)
#28 /srv/mediawiki/php-1.38.0-wmf.26/includes/specials/SpecialRecentChanges.php(617): SpecialRecentChanges->setTopText(FormOptions)
#29 /srv/mediawiki/php-1.38.0-wmf.26/includes/specialpage/ChangesListSpecialPage.php(1537): SpecialRecentChanges->doHeader(FormOptions, integer)
#30 /srv/mediawiki/php-1.38.0-wmf.26/includes/specialpage/ChangesListSpecialPage.php(666): ChangesListSpecialPage->webOutputHeader(integer, FormOptions)
#31 /srv/mediawiki/php-1.38.0-wmf.26/includes/specials/SpecialRecentChanges.php(205): ChangesListSpecialPage->execute(NULL)
#32 /srv/mediawiki/php-1.38.0-wmf.26/includes/specialpage/SpecialPage.php(671): SpecialRecentChanges->execute(NULL)
#33 /srv/mediawiki/php-1.38.0-wmf.26/includes/specialpage/SpecialPageFactory.php(1378): SpecialPage->run(NULL)
#34 /srv/mediawiki/php-1.38.0-wmf.26/includes/MediaWiki.php(315): MediaWiki\SpecialPage\SpecialPageFactory->executePath(string, RequestContext)
#35 /srv/mediawiki/php-1.38.0-wmf.26/includes/MediaWiki.php(910): MediaWiki->performRequest()
#36 /srv/mediawiki/php-1.38.0-wmf.26/includes/MediaWiki.php(564): MediaWiki->main()
#37 /srv/mediawiki/php-1.38.0-wmf.26/index.php(53): MediaWiki->run()
#38 /srv/mediawiki/php-1.38.0-wmf.26/index.php(46): wfIndexMain()
#39 /srv/mediawiki/w/index.php(3): require(string)
#40 {main}
```
* new with 1.38.0-wmf.26
* Happening at a rate of about once an hour
When rollback is used to revert an unpatrolled revision, the "rc_patrolled" field of the reverted revision in the recentchanges table is currently updated from value 0 (meaning "unpatrolled") to value 2 (meaning "autopatrolled"). Since the rollback action is usually the result of a manual review process, I think it is much more appropriate to switch to value 1 (meaning "manually patrolled") instead which is also used when a revision is patrolled without rollback.
In fact, value 2 (meaning "autopatrolled") should be reserved for revisions that have been made by editors with the "autopatrol" right at the time when the revision was made.
**Instructions:** In `RollbackPage.php` use `PRC_PATROLLED` instead of `PRC_AUTOPATROLLED` and update `tests/phpunit/integration/includes/page/RollbackPageTest.php` as necessary.
As @Jdlrobson pointed out in the comments for {T298638}, currently Special:RecentChanges and Special:Watchlist insert `<h4>` date headings after `<h1>`. After T298638 goes live, a bunch of other special pages and ?action=history will also use `<h4>` for date headings. This is a common accessibility mistake that is prescribed to be avoided by most accessibility guidelines:
> Skipping heading ranks can be confusing and should be avoided where possible: Make sure that a <h2> is not followed directly by an <h4>, for example. https://www.w3.org/WAI/tutorials/page-structure/headings/
> Do not skip heading levels to be more specific (for example, do not skip from <h2> to <h5>). It is permissible to skip headings in the other direction if the outline of the page calls for it (for example, from <h5> to <h2>). https://usability.yale.edu/web-accessibility/articles/headings
> Do not skip a heading level from the top down. https://www.a11yproject.com/posts/how-to-accessible-heading-structure/
I would assume that `<h4>` was chosen //in the olden years// because of its (regular) font size, and not much else. However, it makes the interface less accessible. I think we should find some way to work around this (either by upping the level, adding appropriate CSS to make the text smaller, or even `aria-level="2"` I guess ¯\_(ツ)_/¯).
**List of steps to reproduce**:
* Create a topic on a wiki enabled structured discussions
* Several edits on that topic
* Enable `tog-usenewrc` in `Special:Preferences#mw-prefsection-rc`
* Visit `Special:RecentChanges`
**What happens?**:
Incorrect `mw-diff-bytes`.
{F34947403}
**What should have happened instead?**:
`mw-diff-bytes` should be the correct value, rather than the latest revision's value.
**Software version**:
MediaWiki `1.38.0-wmf.21 (ce757a7)`
From {T74811}:
> I am embarrassed to say I did not notice the arrowhead expanding the individual uploads here: ...
> This function is not listed in the legend box at the top right of my Commons watchlist. I have no idea if this is a new function or not. No one mentioned it in this 8 year old thread previously.
> If it has been there all along then maybe many people aren't noticing that tiny arrowhead or what it does. I suggest putting it in the legend.
The expand icon (a small triangle), for showing multiple edits to the same article or multiple log events of same type, is not particularly noticeable. Maybe there are design improvements that could help with that. Or we could just mention it in the legend as suggested (note that whether edits are grouped or not depends on user preferences).
The expand icon is gray. Maybe it should be black. Timeshifter has difficulty with gray text on his light gray monitor screen. Like many people nowadays (and as many eye doctors recommend) he turns down the brightness on his desktop PC monitor. So when the brightness is turned down the screen goes from being bright white to being very slightly gray. Gray text on gray backgrounds is harder to read or notice for many people. Timeshifter has emailed various web sites asking them to use black text instead of gray text.
The issue was reported [[ https://www.mediawiki.org/w/index.php?title=Topic:Wgsq0q2fchmqna7f | here ]]
Steps to reproduce
1. On Recent changes select **Unpatrolled** filter - the list of unpatrolled edits will be presented.
2. Click on one of the results to open in a separate tab and mark an edit as patrolled.
3. The Recent changes results won't refresh - the list of unpatrolled changes will display the recently patrolled edit as unpatrolled.
Notes:
- If RC page is manually refreshed, the records will be updated correctly.
- Having **Live updates** on or off does not have any effect.
- marking **pages** (not page edits) as patrolled works as expected - the RC records will be updated promptly
==== Error ====
* mwversion: `undefined`
* reqId: `undefined`
* [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2022-01-23T22:33:58.022Z',to:'2022-01-24T22:33:58.022Z'))&_a=(query:(query_string:(query:'reqId:%22undefined%22'))) | Find reqId in Logstash ]]
```name=normalized_message
Error: cannot call methods on dialog prior to initialization; attempted to call method 'destroy'
```
```
name=exception.trace,lines=10
at Function.error https://hy.wikipedia.org/w/load.php?lang=hy&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets%7Cmediawiki.special%7Cmediawiki.special.changeslist.legend.js%7Cmediawiki.special.changeslist.watchlistexpiry%7Cmediawiki.special.recentchanges&skin=vector&version=1q699:4:678
at HTMLDivElement.<anonymous> https://hy.wikipedia.org/w/load.php?lang=hy&modules=jquery.ui&skin=vector&version=1e6t4:9:878
at Function.each https://hy.wikipedia.org/w/load.php?lang=hy&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets%7Cmediawiki.special%7Cmediawiki.special.changeslist.legend.js%7Cmediawiki.special.changeslist.watchlistexpiry%7Cmediawiki.special.recentchanges&skin=vector&version=1q699:5:285
at jQuery.fn.init.each https://hy.wikipedia.org/w/load.php?lang=hy&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets%7Cmediawiki.special%7Cmediawiki.special.changeslist.legend.js%7Cmediawiki.special.changeslist.watchlistexpiry%7Cmediawiki.special.recentchanges&skin=vector&version=1q699:3:93
at jQuery.fn.init.$.fn.<computed> [as dialog] https://hy.wikipedia.org/w/load.php?lang=hy&modules=jquery.ui&skin=vector&version=1e6t4:9:792
at HTMLDivElement.click <anonymous>:213:840
at HTMLButtonElement.props.click https://hy.wikipedia.org/w/load.php?lang=hy&modules=jquery.ui&skin=vector&version=1e6t4:204:720
at HTMLButtonElement.dispatch https://hy.wikipedia.org/w/load.php?lang=hy&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets%7Cmediawiki.special%7Cmediawiki.special.changeslist.legend.js%7Cmediawiki.special.changeslist.watchlistexpiry%7Cmediawiki.special.recentchanges&skin=vector&version=1q699:70:260
at HTMLButtonElement.elemData.handle https://hy.wikipedia.org/w/load.php?lang=hy&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets%7Cmediawiki.special%7Cmediawiki.special.changeslist.legend.js%7Cmediawiki.special.changeslist.watchlistexpiry%7Cmediawiki.special.recentchanges&skin=vector&version=1q699:66:877
```
==== Impact ====
==== Notes ====
https://logstash.wikimedia.org/app/discover#/doc/logstash-*/logstash-2022.01.24?id=oSZSjH4BMAtV7EgGW0zh
Currently, you can filter Special:RecentChanges/Watchlist by `userExpLevel`. However, for the API:RecentChanges module, you only have access to the the `rcshow` filter, which does not include, say, `newcomer`.
It would be good if any Special:RecentChanges/Watchlist URL could map to an equivalent API query.
**Use case(s)**: Allowing API queries to produce the same (or at least similar) result sets to those available in the Special:RecentChanges/Watchlist pages. For example in "popups" gadgets when hovering over links to RC/WL pages.
**List of steps to reproduce** (step by step, including full links if applicable):
* Open https://en.wikivoyage.org/wiki/User_talk:SHB2000
* Leave a message
* Go to https://en.wikivoyage.org/wiki/Special:RecentChanges looking the above change
**What happens?**:
* Visually the link "User_talk:SHB2000 " is red and the associated link address is https://en.wikivoyage.org/w/index.php?title=User_talk:SHB2000&action=edit&redlink=1
**What should have happened instead?**:
* Visually the link "User_talk:SHB2000 " should be blue and the associated link address should be https://en.wikivoyage.org/wiki/User_talk:SHB2000
**Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc**:
* Discussion happening [[ https://en.wikivoyage.org/wiki/Wikivoyage:Travellers%27_pub#Why_is_a_link_to_User_talk:SHB2000_coming_up_as_a_redlink_in_Special:RecentChanges? | here ]]
** Further notes **
On Special:RecentChanges, a link to User talk:SHB2000 comes up as a redlink even though it's a page that has more than 1000 revisions.
Moving the page to another page without a redirect and then moving it back has failed, and so has deleting it and then restoring the page
Some screenshots below
{F34764486}{F34764488}
**List of steps to reproduce** (step by step, including full links if applicable):
* There is no reproducibility. Occurs rarely.
**What happens?**:
It looks like a red link on a special page. The page exists and is linked correctly. Take a look at the screenshot.
特別:最近の更新（Special:RecentChanges）、特別:ウォッチリスト（Special:Watchlist）
**Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc**:
page: jawiki Template:Treccani/doc
https://ja.wikipedia.org/wiki/Template:Treccani/doc
{F34730105}
**List of steps to reproduce** (step by step, including full links if applicable):
* Set `$wgSQLMode = 'ONLY_FULL_GROUP_BY';` in `LocalSettings.php`
* Visit Special:RecentChanges
* Choose two tags out of the list, for example `#mw-undo` and `#mw-reverted`
* Refresh the page (Bypass javascript)
**What happens?**:
```
Error: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading or after adding a new extension?
Error 1055: 'recentchanges.rc_namespace' isn't in GROUP BY (localhost)
Function: SpecialRecentChanges::doMainQuery
Query: SELECT DISTINCT rc_id,rc_timestamp,rc_namespace,rc_title,rc_minor,rc_bot,rc_new,rc_cur_id,rc_this_oldid,rc_last_oldid,rc_type,rc_source,rc_patrolled,rc_ip,rc_old_len,rc_new_len,rc_deleted,rc_logid,rc_log_type,rc_log_action,rc_params,rc_actor,recentchanges_actor.actor_user AS `rc_user`,recentchanges_actor.actor_name AS `rc_user_text`,comment_rc_comment.comment_text AS `rc_comment_text`,comment_rc_comment.comment_data AS `rc_comment_data`,comment_rc_comment.comment_id AS `rc_comment_cid`,page_latest,(SELECT GROUP_CONCAT(ctd_name SEPARATOR ',') FROM `change_tag` JOIN `change_tag_def` ON ((ct_tag_id=ctd_id)) WHERE ct_rc_id=rc_id ) AS `ts_tags` FROM `recentchanges` JOIN `actor` `recentchanges_actor` ON ((actor_id=rc_actor)) JOIN `comment` `comment_rc_comment` ON ((comment_rc_comment.comment_id = rc_comment_id)) LEFT JOIN `page` ON ((rc_cur_id=page_id)) JOIN `change_tag` ON ((ct_rc_id=rc_id)) WHERE rc_bot = 0 AND (rc_type != 6) AND (rc_timestamp >= '20211025154421') AND ct_tag_id IN (5,11) AND rc_new IN (0,1) GROUP BY rc_timestamp, rc_id ORDER BY rc_timestamp DESC, rc_id DESC LIMIT 50
```
It works when removing ONLY_FULL_GROUP_BY from the setting
**What should have happened instead?**:
The filtered result
**Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc**: 1.38
**List of steps to reproduce** (step by step, including full links if applicable):
* create a user page on Meta-Wiki
* go to a wiki where you don't have a local user page
* edit any page and include the link to your user page in the edit summary
==Test==
I edited [[https://pt.m.wikivoyage.org/wiki/Utilizador:Edu!/Testes|my page for testing]] on Portuguese Wikivoyage. The editing summary was as follows:
teste [[User:Edu!|Edu!]]
**What happens?**:
In the history the link appears red. The link also appears red on the [[https://pt.m.wikivoyage.org/wiki/Especial:Mudan%C3%A7as_recentes|recent changes page]] and [[https://pt.m.wikivoyage.org/wiki/Especial:Contribuições/Edu!|my contributions page]].
{F34716954}
**What should have happened instead?**:
On the [[https://pt.m.wikivoyage.org/wiki/Especial:MobileDiff/132994|mobile version diff page]] the link appears blue, the same should happen on other pages as well.
{F34716963}
**Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc**:
Google Chrome (94.0.4606.85)
**List of steps to reproduce** (step by step, including full links if applicable):
* https://en.wikipedia.org/wiki/Special:RecentChangesLinked?hidebots=1&hidecategorization=1&hideWikibase=1&target=Category%3ASuspected_Wikipedia_sockpuppets_of_Bodiadub&limit=500&days=30&urlversion=2
* No namespaces or tags are selected.
**What happens?**:
{F34661408}
**What should have happened instead?**: There are several block log entries missing. Each of the edits I made is associated with a block I made within a few minutes.
**Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc**: 1.38.0-wmf.1 (c439f11)
I assembled some filters at German Wikipedia, in order to check the usage of Growth features. I see the following:
{F34634565}
URL:
```https://de.wikipedia.org/wiki/Spezial:Letzte_%C3%84nderungen?hidebots=1&hidenewpages=1&hidecategorization=1&hideWikibase=1&tagfilter=mentorship+module+question%7Cnewcomer+task&limit=500&days=30&enhanced=1&tagfilter__mentorship+module+question_color=c3&tagfilter__newcomer+task_color=c1&urlversion=2
```
Then I wanted to check on the same thing at another wiki. I did the following:
# copy the link at de.wp
# open a new tab in my browser
# paste the link
# changed the wiki's language prefix
# replaced `Spezial:Letzte_%C3%84nderungen` with the generic `Special:RecentChanges`
# pressed Enter
Expectation:
* same colors being applied
Reality:
* no colors
{F34634569}
URL reused and customized:
```
https://nl.wikipedia.org/w/index.php?title=Speciaal:RecenteWijzigingen&hidebots=1&hidenewpages=1&hidecategorization=1&hideWikibase=1&tagfilter=mentorship+module+question%7Cnewcomer+task&limit=500&days=30&enhanced=1&tagfilter__mentorship_module_question_color=c3&tagfilter__newcomer_task_color=c1&urlversion=2
```
---------
Tested one again at Spanish Wikipedia, with the same outcome. URL :
```https://es.wikipedia.org/w/index.php?hidebots=1&hidenewpages=1&hidecategorization=1&hideWikibase=1&tagfilter=newcomer+task&limit=500&days=30&enhanced=1&title=Especial:CambiosRecientes&tagfilter__mentorship_module_question_color=c3&tagfilter__newcomer_task_color=c1&urlversion=2```
Strangly, the order if the elements in the page have been changed when the page loaded. See the position of `Especial:CambiosRecientes`.
I tried it at German one again, just copy/pasting the URL in a private browsing window, and still have no color. URL I got:
```https://de.wikipedia.org/wiki/Spezial:Letzte_%C3%84nderungen?hidebots=1&hidenewpages=1&hidecategorization=1&hideWikibase=1&tagfilter=newcomer+task%7Cmentorship+module+question&limit=500&days=30&enhanced=1&tagfilter__newcomer+task_color=c1&tagfilter__mentorship+module+question_color=c3&urlversion=2```
I noticed that the URL was transformed when the page finishes to load.
------------
I note that `tagfilter__mentorship+module+question_color=c3` on the original URL is sometimes changed to `tagfilter__mentorship_module_question_color=c3` (pluses instead of underscores)
This seems to be possible using the database (filtering `WHERE rc_this_oldid = $myDiffId`), but according to https://www.mediawiki.org/wiki/API:RecentChanges there doesn't seem to be a way to do this via the API.
[I've searched through Phabricator and can't find anything like this, but this is at tricky search. The closest I found is T208868, which is clearly a very different bug. If this is already fixed, great, but otherwise...]
In a two-week-old MediaWiki 1.35 installed under Ubuntu 20.04, with Firefox as the client:
Unchecking the user preference "Group changes by page in recent changes and watchlist" is magically set back to checked when "Recent Changes" is loaded, but ONLY IF "Use non-JavaScript interface" is not checked. As a result, RC lists are always grouped. This is true even if "Expand watchlist to show all changes, not just the most recent" is already checked.
If "Use non-JavaScript interface" is checked, -then- it is possible to uncheck "Group changes by page in recent changes and watchlist", reload Recent Changes, and have the setting persist. Once the setting has survived at least one RC reload, it is then possible to uncheck "Use non-JavaScript interface", reload RC, and it stays ungrouped and "Group changes by page in recent changes and watchlist" stays unchecked.
I originally thought this might be my preferences somehow not getting saved, because I would uncheck "Group changes by page in recent changes and watchlist" and would find it magically checked again after I tested whether it had affected RC. But I could load other pages, and I could also either hop around in the Preferences tab, or reload the page, or load it fresh in a separate browser tab, and the unchecked setting would stay unchecked, -until- I reloaded Recent Changes---whereupon Group was magically checked again as soon as I reloaded the Preferences page.
And other preferences -do- get saved normally, so that rules out (for example) some weird 302 POST problem because I'm using shortened URLs---and, having figured out the workaround where I turn off the JS interface and my grouping preference then get saved, it's clear that prefs are really being saved.
If someone needs me to reproduce this, I have a copy of the database from that time and could if necessary reload it. I would rather -not- have to try to reproduce this in 1.36; I'm running 1.35 because it's LTS and I don't want to be on an upgrade treadmill with a non-LTS release. (It would be a lot of work to install 1.36 in parallel.)
Note that the client side of this was Ubuntu 14.04 running an old (66.0.3) version of Firefox. It's got NoScript running but I've told it to trust scripts on my own wiki. I could attempt to reproduce this in 20.04 with the current version of Firefox without much trouble.
Recent changes enables patrollers to filter out Newcomers, who are defined as "Registered editors who have fewer than 10 edits or 4 days of activity". The 4 days count from the time when the contributors created their accounts. These accounts are often created automatically in individual projects, sometimes even years before they make their first edit there. Would it be possible to change it so that the days of activity were counted from the time of the first edit instead?
See https://www.wikidata.org/wiki/Wikidata:Administrators%27_noticeboard#Mass_rollback,_please
Pigsonthewing accidentally created a bunch of blank items
Using the nuke extension I deleted over a thousand such items. However, there were a bunch remaining visible in the user's contributions that the nuke interface was not finding. Further investigation showed that there did not appear to be recent changes rows for the page creations, hence why nuke didn't know about them.
For reference, the following pages were the ones not found by nuke
```
lines=10
Q106306619
Q106306618
Q106306617
Q106306616
Q106306615
Q106306613
Q106306612
Q106306611
Q106306610
Q106306609
Q106306608
Q106306607
Q106306605
Q106306604
Q106306603
Q106306602
Q106306601
Q106306600
Q106306599
Q106306597
Q106306596
Q106306595
Q106306594
Q106306592
Q106306591
Q106306590
Q106306587
Q106306586
Q106306584
Q106306583
Q106306582
Q106306581
Q106306579
Q106306578
Q106306577
Q106306576
Q106306574
Q106306573
Q106306571
Q106306570
Q106306569
Q106306568
Q106306567
Q106306566
Q106306564
Q106306563
Q106306561
Q106306560
Q106306559
Q106306558
Q106306557
Q106306556
Q106306554
Q106306553
Q106306551
Q106306550
Q106306549
Q106306548
Q106306546
Q106306545
Q106306544
Q106306543
Q106306542
Q106306541
Q106306540
Q106306539
Q106306537
Q106306535
Q106306534
Q106306533
Q106306531
Q106306529
Q106306527
Q106306526
Q106306525
Q106306524
Q106306523
Q106306522
Q106306521
Q106306519
Q106306518
Q106306517
Q106306516
Q106306515
Q106306514
Q106306513
Q106306511
Q106306510
Q106306509
Q106306508
Q106306507
Q106306506
Q106306504
Q106306503
Q106306502
Q106306501
Q106306500
Q106306499
Q106306498
Q106306496
Q106306495
Q106306494
Q106306493
Q106306492
Q106306491
Q106306490
Q106306488
Q106306487
Q106306486
Q106306484
Q106306483
Q106306482
Q106306481
Q106306479
Q106306478
Q106306477
Q106306476
Q106306475
Q106306473
Q106306472
Q106306470
Q106306469
Q106306468
Q106306467
Q106306466
Q106306465
Q106306464
Q106306462
Q106306461
Q106306460
Q106306459
Q106306458
Q106306457
Q106306456
Q106306454
Q106306453
Q106306452
Q106306451
Q106306450
Q106306449
Q106306447
Q106306446
Q106306445
Q106306444
Q106306443
Q106306441
Q106306440
Q106306438
Q106306437
Q106306436
Q106306435
Q106306433
Q106306432
Q106306431
Q106306429
Q106306428
Q106306427
Q106306426
Q106306425
Q106306424
Q106306423
Q106306421
Q106306419
Q106306417
Q106306416
Q106306415
Q106306413
Q106306412
Q106306411
Q106306410
Q106306408
Q106306407
Q106306406
Q106305576
Q106305575
Q106305574
Q106305573
Q106305572
Q106305571
Q106305570
Q106305569
Q106305568
Q106305567
Q106305566
Q106305565
Q106305564
Q106305563
Q106305562
Q106305561
Q106305560
Q106305559
Q106305558
Q106305557
Q106305556
Q106305555
Q106305553
Q106305552
Q106305551
Q106305550
Q106305549
Q106305548
Q106305546
Q106305545
Q106305543
Q106305542
Q106305541
Q106305540
Q106305538
Q106305537
Q106305535
Q106305534
Q106305532
Q106305531
Q106305530
Q106305529
Q106305528
Q106305526
Q106305525
Q106305524
Q106305523
Q106305522
Q106305521
Q106305520
Q106305518
Q106305517
Q106305516
Q106305515
Q106305514
Q106305513
Q106305512
Q106305511
Q106305509
Q106305508
Q106305507
Q106305506
Q106305505
Q106305503
Q106305501
Q106305498
Q106305494
Q106305493
Q106305492
Q106305490
Q106305489
Q106305488
Q106305487
Q106305486
Q106305484
Q106305482
Q106305479
Q106305478
Q106305477
Q106305476
Q106305474
Q106305472
Q106305471
Q106305470
Q106305469
Q106305468
Q106305467
Q106305466
Q106305463
Q106305462
Q106305461
Q106305460
Q106305459
Q106305458
Q106305456
Q106305455
Q106305454
Q106305453
Q106305452
Q106305451
Q106305449
Q106305448
Q106305446
Q106305445
Q106305444
Q106305443
Q106305442
```
When loading https://en.wikipedia.org/w/index.php?damaging=verylikelybad&goodfaith=likelybad%3Bverylikelybad&userExpLevel=unregistered%3Bnewcomer%3Blearner&hidemyself=1&hidepreviousrevisions=1&hideWikibase=1&hidelog=1&limit=1000&days=30&damaging__verylikelybad_color=c5&title=Special:RecentChanges&urlversion=2 I get an WMFTimeoutException instead of the normal recent changes page. This doesn't happen on any other page, or recent changes with other filters
```
[YESs-ymFrvi8w6994LcImgAAAAM] 2021-03-07 10:39:03: Fatal exception of type "WMFTimeoutException"
```
```
from /srv/mediawiki/wmf-config/set-time-limit.php(41)
#0 /srv/mediawiki/php-1.36.0-wmf.33/includes/exception/MWExceptionHandler.php(208): {closure}(integer)
#1 [internal function]: MWExceptionHandler::handleError(integer, string, string, integer, array)
#2 /srv/mediawiki/php-1.36.0-wmf.33/includes/libs/rdbms/database/DatabaseMysqli.php(46): mysqli->query(string)
#3 /srv/mediawiki/php-1.36.0-wmf.33/includes/libs/rdbms/database/Database.php(1380): Wikimedia\Rdbms\DatabaseMysqli->doQuery(string)
#4 /srv/mediawiki/php-1.36.0-wmf.33/includes/libs/rdbms/database/Database.php(1298): Wikimedia\Rdbms\Database->executeQueryAttempt(string, string, boolean, string, integer)
#5 /srv/mediawiki/php-1.36.0-wmf.33/includes/libs/rdbms/database/Database.php(1227): Wikimedia\Rdbms\Database->executeQuery(string, string, integer)
```
[[https://www.mediawiki.org/wiki/Topic:Sdaf3ew396cm661w | mw:Topic:Sdaf3ew396cm661w]] is categorized in [[https://www.mediawiki.org/wiki/Category:Test | Category:Test]].
I have updated the topic posting a new message.
So, this topic should display in Related changes ([[https://www.mediawiki.org/wiki/Special:RecentChangesLinked/Category:Test | Special:RecentChangesLinked/Category:Test]]), but it doesn’t.
Having read T154486, I think this is a regression.
Reported [[https://fr.wikipedia.org/wiki/Sujet:W3m2uk0ldx9i00xp | on fr.wp]].
AbuseFilter uses its own ChangesList to add "examine" links to recentchanges. It does so by [[https://phabricator.wikimedia.org/diffusion/EABF/browse/master/includes/AbuseFilterChangesList.php$36|overriding]] `insertExtra`. Flow has its special way to generate RC rows, which is implemented by handling the `OldChangesListRecentChangesLine` hook. However, the hook runs after insertExtra() is called, so any extra is lost.
I don't think this is supposed to happen. If it is, or if changing this behaviour (by moving insertExtra() to after the hook call) is not feasible, then perhaps there should be an additional method like insertExtra that is called after the hook.
//Notes//:
- **<<MediaWiki:Tag-foo-description>>** tag most likely was created for testing purposes only.
- I did not find any other display regression issues for tags titles.
- it's a regression issue.
1. On `testwiki wmf.25` go to Special:RecentChanges page
2. Click on Tags filter selection and select **<<MediaWiki:Tag-foo-description>>** tag.
The <<MediaWiki:Tag-foo-description>> tag title displays HTML encoding:
{F33986320}
Open this link and inspect any collapsed lines.
https://en.wikipedia.org/wiki/Special:RecentChanges?hidebots=1&hidepageedits=1&hidenewpages=1&hideWikibase=1&hidelog=1&enhanced=1&urlversion=2
Example:
- 22:24 [[https://en.wikipedia.org/wiki/Category:Midtown_Manhattan|Category:Midtown Manhattan]] (2 changes) . . [ [[https://en.wikipedia.org/wiki/User:Ser_Amantio_di_Nicolao|Ser Amantio di Nicolao]] (2×) ]
-- [[https://en.wikipedia.org/w/index.php?title=Category:Midtown_Manhattan&curid=9288855&oldid=995594781|22:24]] . . [[https://en.wikipedia.org/wiki/User:Ser_Amantio_di_Nicolao|Ser Amantio di Nicolao]] ([[https://en.wikipedia.org/wiki/User_talk:Ser_Amantio_di_Nicolao|talk]] | [[https://en.wikipedia.org/wiki/Special:Contributions/Ser_Amantio_di_Nicolao|contribs]]) //([[https://en.wikipedia.org/wiki/3_Park_Avenue|3 Park Avenue]] removed from category, [[https://en.wikipedia.org/wiki/Special:WhatLinksHere/3_Park_Avenue|this page is included within other pages]])//
-- [[https://en.wikipedia.org/w/index.php?title=Category:Midtown_Manhattan&curid=9288855&oldid=995594739|22:23]] . . [[https://en.wikipedia.org/wiki/User:Ser_Amantio_di_Nicolao|Ser Amantio di Nicolao]] ([[https://en.wikipedia.org/wiki/User_talk:Ser_Amantio_di_Nicolao|talk]] | [[https://en.wikipedia.org/wiki/Special:Contributions/Ser_Amantio_di_Nicolao|contribs]]) //([[https://en.wikipedia.org/wiki/Lexington_Avenue|Lexington Avenue]] added to category, [[https://en.wikipedia.org/wiki/Special:WhatLinksHere/Lexington_Avenue|this page is included within other pages]])//
Notice "22:23" on the third line is linked [[https://en.wikipedia.org/w/index.php?title=Category:Midtown_Manhattan&curid=9288855&oldid=995594739|here]], with `curid=9288855`, which is for [[https://en.wikipedia.org/wiki/3_Park_Avenue|3 Park Avenue]], not [[https://en.wikipedia.org/wiki/Lexington_Avenue|Lexington Avenue]]. In any group of category changes, the `curid` for the page on the first line is mistakenly being used on all the rest of the collapsed lines.
Though this can't be reproduced in markup here, the `title` attributes (tooltips) of the timestamps are also wrong: they're set to the name of the category, not the linked pages themselves.
In recent changes and watchlists the reverted edits are flagged with tags `mw-reverted`, `mw-manual-revert`. However, this is only true for local changes and information of Wikidata-edits tags arent propagated to client wikis.
In context of tracking wikidata edits in other wiki than wikidata it would be important to see if the edit is already reverted so there would not be duplicating work to check manually if the vandalism still exist in Wikidata or if it is reverted.
tl;dr: Clicking on the Atom button from Special:RecentChanges doesn't pass through hideminor=1
---
I was trying to set a filter to not notify minor editions. But i can't find the parameter **hideminor=1** in API rss links.
Example of Special:RecentChanges:
https://tuscriaturas.miraheze.org/wiki/Especial:CambiosRecientes?hidebots=1&hideminor=1&translations=filter&hideWikibase=1&limit=50&days=180&enhanced=1&urlversion=2
RSS Atom of that page:
https://tuscriaturas.miraheze.org/w/api.php?hidebots=1&hideWikibase=1&translations=filter&urlversion=1&days=180&limit=50&action=feedrecentchanges&feedformat=atom
This happens too with mediawiki web:
Special:RC:
https://www.mediawiki.org/wiki/Special:RecentChanges?hidebots=1&hideminor=1&translations=filter&hidecategorization=1&hideWikibase=1&hidelog=1&limit=50&days=7&urlversion=2
RSS Atom of that page:
https://www.mediawiki.org/w/api.php?hidebots=1&hidecategorization=1&hideWikibase=1&translations=filter&urlversion=1&days=7&limit=50&action=feedrecentchanges&feedformat=atom
The issue is that Special:RC is set to "hide all minor editions", but the RSS is notifying all these editions because that feature (hideminor=1) is absent.
I would be very grateful if you could include a feature to use **hideminor=1** in RSS api.
Steps to reproduce:
# https://commons.wikimedia.org/wiki/Special:RecentChanges
# Click "Namespaces"
# Select MediaWiki and MediaWiki talk
You'll see nothing if you have "Not translations" selected, and everything if you selected "Translations".
I noticed this problem because a MediaWiki talk page I watched was edited but not shown in my watchlist.
I also tested metawiki, which has Translation feature too. It's normal, so it seems only Commons is affected maybe.
The `mediawiki.rcfilters.filters.dm` resource loader module is only used in two places: QUnitTestResources, and as a dependency for `mediawiki.rcfilters.filters.ui`. I suggest that the `dm` module be merged with the `ui` module, and the `ui` module be used in the QUnit test instead.
Global search reveals no uses of the `mediawiki.rcfilters.filters.ui` module on-wiki
I propose creating a factory for `RecentChange`s that would inject the needed dependencies:
* LoadBalancer (currently uses `wfGetDB`)
* CommentStore (currently uses `CommentStore::getStore()`)
* ActorMigration (currently uses `ActorMigration::newMigration()`)
* HookContainer (currently uses `Hooks::run()`)
* PermissionManager
* Global variables `$wgPutIPinRC`, `$wgUseEnotif`, `$wgShowUpdatedMarker`, `$wgRCFeeds`, `$wgRCEngines`, `$wgUseRCPatrol`, `$wgUseNPPatrol`, `$wgUseFilePatrol`, `$wgLogRestrictions`, `$wgRCMaxAge`
In 2017 (MW 1.27, 39a6e3dc4d) support was added to register an RCFeed backend directly using a `class` option.
For this task:
* Complety any unfinished parts of that migration.
* Updating relevant documentation in code and on mediawiki.org to encourage this method.
* Reduce the footprint of the old mechanism as much as possible, keeping only config-compat but nothing significant at run-time.
##### Configuration example
```lang=php,name=Old way
$wgRCEngines['eg-engine'] = ExampleRCFeed::class;
$wgRCFeeds['eg-feed'] = [
'uri' => 'eg-engine://bogus',
…
];
```
```lang=php,name=New way
$wgRCFeeds['eg-feed'] = [
'class' => ExampleRCFeed::class,
…
];
```
When administrator delete page and reason for deletion is very big, content goes out. See F31758074.
It isn't case with edit summary. See F31758080.
I found this bug on srwiki, for others I'm not sure. Also, I have AMC enabled.
----
**Details about device:**
* Device: Honor 8A
* Operating system: Android 9
* Browser: Chrome 80.0.3987.162
When using the Special:NewPages command, could another boolean be added: "titlesonly"?
IF titlesonly, then truncate the output to only include the titles.
Example input would be:
{{Special:Newpages/limit=5,shownav,offset=20081210,namespace=Template,titlesonly}}
Output would be the same as the current output, but ONLY include the mw-newpages-pagename elements in the list.
c.f. https://www.mediawiki.org/wiki/Help:New_pages
The current implementation of the Wikidata recent changes in other projects shows all the edits to the labels. While this is useful for regular Wikidata patrollers, it clutters the feed of people only interested in vandalism of their home wiki. This is a feature request for implementing filtering based on language. There are 2 possible version of this feature:
1. A simple checkbox for filtering on the current wiki languages
2. A more complex choice allowing users to select any number of languages from those available on wikidata.
In the new recent changes interface I have selected both "human" and "wikidata" filters on ro.wp and yet I still see robot edits from Wikidata (e.g. user GZWDer (flood)). This is polluting the feed and making it hard to monitor recent changes.
#upstream tickets:
- https://github.com/magnusmanske/quickstatements_rs/issues/2
**See also:** {T276921} about bot actions instead of edits.
It would be nice to be able to filter recent changes by topic.
This would presumably be done on top of {T240558}, which fetches ORES topics on edit; but they would also have to be stored somewhere (the ORES extension, presumably?) and we'd have to end up with a non-terrible join/filter for the RC query.
The following query takes more than 2 minutes to run
```
SELECT /* SpecialRecentChanges::doMainQuery */ /*! STRAIGHT_JOIN */ rc_id,rc_timestamp,rc_namespace,rc_title,rc_minor,rc_bot,rc_new,rc_cur_id,rc_this_oldid,rc_last_oldid,rc_type,rc_source,rc_patrolled,rc_ip,rc_old_len,rc_new_len,rc_deleted,rc_logid,rc_log_type,rc_log_action,rc_params,comment_rc_comment.comment_text AS `rc_comment_text`,comment_rc_comment.comment_data AS `rc_comment_data`,comment_rc_comment.comment_id AS `rc_comment_cid`,actor_rc_user.actor_user AS `rc_user`,actor_rc_user.actor_name AS `rc_user_text`,rc_actor,wl_user,wl_notificationtimestamp,page_latest,(SELECT GROUP_CONCAT(ctd_name SEPARATOR ',') FROM `change_tag` JOIN `change_tag_def` ON ((ct_tag_id=ctd_id)) WHERE ct_rc_id=rc_id ) AS `ts_tags`,fp_stable,fp_pending_since,ores_damaging_cls.oresc_probability AS `ores_damaging_score`,ores_goodfaith_cls.oresc_probability AS `ores_goodfaith_score` FROM `recentchanges` JOIN `comment` `comment_rc_comment` ON ((comment_rc_comment.comment_id = rc_comment_id)) JOIN `actor` `actor_rc_user` ON ((actor_rc_user.actor_id = rc_actor)) LEFT JOIN `watchlist` ON (wl_user = 36668941 AND (wl_title=rc_title) AND (wl_namespace=rc_namespace)) LEFT JOIN `page` ON ((rc_cur_id=page_id)) LEFT JOIN `flaggedpages` ON ((fp_page_id = rc_cur_id)) LEFT JOIN `ores_classification` `ores_damaging_cls` ON (ores_damaging_cls.oresc_model = 37 AND (ores_damaging_cls.oresc_rev=rc_this_oldid) AND ores_damaging_cls.oresc_class = 1) LEFT JOIN `ores_classification` `ores_goodfaith_cls` ON (ores_goodfaith_cls.oresc_model = 38 AND (ores_goodfaith_cls.oresc_rev=rc_this_oldid) AND ores_goodfaith_cls.oresc_class = 1) WHERE ((rc_this_oldid = page_latest) OR rc_type = 3) AND (rc_type != 6) AND (rc_source != 'wb') AND ((ores_damaging_cls.oresc_probability BETWEEN 0.919 AND 1)) AND (rc_type NOT IN (3,5)) AND ((ores_goodfaith_cls.oresc_probability BETWEEN 0 AND 0.058)) AND (rc_type NOT IN (3,5)) AND (rc_timestamp >= '20200108105453') AND rc_new IN (0,1) ORDER BY rc_timestamp DESC LIMIT 50;
16 rows in set (2 min 33.94 sec)
```
```
root@db1099.eqiad.wmnet[enwiki]> show explain for 1220761587;
+------+--------------------+--------------------+--------+--------------------------------------------------------+-----------------------+---------+-----------------------------------------------------------------------+---------+-----------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+--------------------+--------------------+--------+--------------------------------------------------------+-----------------------+---------+-----------------------------------------------------------------------+---------+-----------------------------+
| 1 | PRIMARY | recentchanges | range | rc_timestamp,new_name_timestamp,rc_actor,rc_this_oldid | rc_timestamp | 16 | NULL | 4299806 | Using where; Using filesort |
| 1 | PRIMARY | comment_rc_comment | eq_ref | PRIMARY | PRIMARY | 8 | enwiki.recentchanges.rc_comment_id | 1 | |
| 1 | PRIMARY | actor_rc_user | eq_ref | PRIMARY | PRIMARY | 8 | enwiki.recentchanges.rc_actor | 1 | |
| 1 | PRIMARY | watchlist | eq_ref | wl_user,namespace_title,wl_user_notificationtimestamp | wl_user | 265 | const,enwiki.recentchanges.rc_namespace,enwiki.recentchanges.rc_title | 1 | |
| 1 | PRIMARY | page | eq_ref | PRIMARY | PRIMARY | 4 | enwiki.recentchanges.rc_cur_id | 1 | Using where |
| 1 | PRIMARY | flaggedpages | eq_ref | PRIMARY | PRIMARY | 4 | enwiki.recentchanges.rc_cur_id | 1 | |
| 1 | PRIMARY | ores_damaging_cls | eq_ref | oresc_rev_model_class | oresc_rev_model_class | 7 | enwiki.recentchanges.rc_this_oldid,const,const | 1 | Using where |
| 1 | PRIMARY | ores_goodfaith_cls | eq_ref | oresc_rev_model_class | oresc_rev_model_class | 7 | enwiki.recentchanges.rc_this_oldid,const,const | 1 | Using where |
| 2 | DEPENDENT SUBQUERY | change_tag | ref | change_tag_rc_tag_id,change_tag_tag_id_id | change_tag_rc_tag_id | 5 | enwiki.recentchanges.rc_id | 1 | Using index |
| 2 | DEPENDENT SUBQUERY | change_tag_def | eq_ref | PRIMARY | PRIMARY | 4 | enwiki.change_tag.ct_tag_id | 1 | |
+------+--------------------+--------------------+--------+--------------------------------------------------------+-----------------------+---------+-----------------------------------------------------------------------+---------+-----------------------------+
```
On RecentChanges, individual page edits shorten ‘history’ to ‘hist’. When grouping edits by page, ‘history’ is used. We should pick one or the other.
I’ve highlighted it below for clarity
{F31551406}
———ORIGINAL REPORT———
Please don't sometimes say "hist", sometimes say "history"
```
5 February 2020
! 14:08 高雄市警察局旗山分局 diffhist -35 Kenchen1017 talk contribs block →呼號 rollback 1 edit Tags: Mobile web edit Mobile edit
1 February 2020
! 20:50 台南市消防局 3 changes history -355 [Hs (3×)]
30 January 2020
! 14:02 嘉義縣警察局竹崎分局 diffhist +8 Kenchen1017 talk contribs block rollback 1 edit Tags: Mobile web edit Mobile edit
29 January 2020
22:34 User creation log User account S6452559 talk contribs block was created
! 12:34 台北市消防局 diffhist -28 Hs talk contribs block rollback 1 edit Tags: Mobile web edit Mobile edit
! 12:33 屏東縣消防局 2 changes history -33 [Hs (2×)]
```
Please be consistent and use only one or only the other. Thanks.
Seen in
https://radioscanningtw.miraheze.org/wiki/%E7%89%B9%E6%AE%8A:%E8%BF%91%E6%9C%9F%E8%AE%8A%E5%8B%95
P.S., odd that I can't copy the "|" separators with my mouse.
In the process of removing uses of `rc_new`, it came to light that, while there is an index on `rc_new`, there is no such index on `rc_source`.
A new index should be added, to ensure that queries using `rc_source` instead of `rc_new` are not too slow.
The old index can be removed when the column itself is removed.
Feature request to allow better tracking of page count milestones, such as the recent [[ https://en.wikipedia.org/wiki/Wikipedia:Six_million_articles | 6 millionth article ]] on ENWP.
As part of the group that recently determined what the 6 millionth article was, we felt stymied by software limitations. While we could use the stat tracking page's report of how many articles there were, we had no software based way of knowing exactly what that page was. Our stopgap method was to watch the page counter, note roughly when it ticked over, and then use the new page feed to try to figure it out more precisely. Still, we were only able to get it down to the minute, and there were 15 pages created within that minute. In the end, the 6M page was chosen by community consensus of what we thought the best page created in that moment was, not what the actual 6M page was, as we have no way of knowing exactly what it was. Many editors accused this process of being unfair, rigged, or a sham, and were dissapointed to hear that there was no software way to know for sure.
As other page milestones approach on ENWP (chiefly 50 million total pages, ~6 months out), it would be useful to have some sort of tool that accurately tracks page milestones. The billionth edit milestone is also fast approaching (~1 month out), and a similar concern exists that we have no software based way to determine exactly what that edit will be.
Updated to 1.34 this morning, not certain if this was an error before. When I open the Recent Changes page I get a generic "Internal error" and no pages listed (there should be changes as I had made edits). Nothing in php.log, but when I turn on debug I get the following error in the debug console:
```
[exception] [Xf5TyEWj@38AAAjVlmwAAAAB] /index.php?title=Special:RecentChanges Wikimedia\Assert\ParameterAssertionException from line 63 of /home/xxx/xxx.xxx.ca/vendor/wikimedia/assert/src/Assert.php: Bad value for parameter $title: should not be empty unless namespace is main and fragment or interwiki is non-empty
```
Version info:
MediaWiki: 1.34.0 (ff037a9)
Git branch: REL1_34
PHP: 7.3.11
Ran rebuildrecentchanges.php, no improvement.
//Mentioned on https://meta.wikimedia.org/wiki/Talk:WMDE_Technical_Wishes/Rollback#Ajax//
**Problem**
- You're on a list page such as Recent Changes.
- You click on rollback and then confirm the rollback via the confirmation prompt (T199534).
- You are redirected to "Rollback done" screen --> ie. have to leave the Recent Changes page.
This is very cumbersome for people who want to quickly rollback several edits, as they are forced to leave the Recent Changes page with every rollback.
One possible workaround is using Ctrl+Left mouse button or just middle mouse button: Then you have the confirmation window open in a new tab (which you will eventually have to close).
This only works when the confirmation prompt is disabled.
**Wish**
Use AJAX to make rollbacks asynchronous.
**Existing discussions**
T88044 digs into the topic already. An implementation was done and undone again. An argument against this change was the risk of accidentally hitting the rollback button. This risk is reduced with the confirmation prompt that exists since April 2019.
Steps to reproduce:
* use Special:UploadWizard or Special:Upload to upload a File and create a new File page
* check `recentchanges` - there will be an entry with rc_type=3 (RC_LOG) for the File page, but none with rc_type=1 (RC_NEW)
Every edit of the new Special:RecentChanges is marked as bold, even though these articles are not on my watchlist. Turning off Advanced Mode and Beta does not help.
Hungarian Wikipedia:
{F30876227}
Wikidata:
{F30876224}
The [[ https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/542611/6/tests/phpunit/includes/changes/ChangesListStringOptionsFilterGroupTest.php | change ]] to replace `@expectedException` with `expectException()` failed with `MWException: You must specify a default` which indicates that the exception is thrown not from where the comment is suggesting but from the first statement of the function. Therefore, this test case is not testing what's it intended to test.
Translation admins on multilingual wikis tend to work in a bot-like manner, scores of rapidly successive edits.
When I watch a page I am interested in actual content changes, but my watchlist is nowadays cluttered with translations updates that are of no use to me. Thus effectively hiding the actual changes I am //watching// for.
{F30503953}
Please provide a way to filter them completely from watchlist and recent-changes the same way bot edits are filtered.
Steps to Reproduce:
[] Replicated on DESKTOP and MOBILE
[] Visit https://en.wikipedia.beta.wmflabs.org/wiki/Special:RecentChanges?damaging=likelygood&limit=50&days=7&enhanced=1&urlversion=2
[] Click filter changes input to open the filter changes menu
[] Click the delete icon
Expected: the filter menu clears
Actual: while the filters menu is open the filters clear but the menu remains open
{F30046529}
= Developer notes
Likely can be solved by listening to the trash can event and hiding the other components (assuming they can access one another)
Highlighting can be enabled if following a URL e.g. https://en.m.wikipedia.beta.wmflabs.org/wiki/Special:RecentChanges?hidebots=1&hidecategorization=1&limit=50&days=7&enhanced=1&damaging__likelygood_color=c2&urlversion=2
Visit this page in a mobile resolution (320x568).
expected: The menu width should match the width of the Filter button
actual: {F29919969}
= Developer notes
The element with the problem has the classes: `oo-ui-widget oo-ui-widget-enabled oo-ui-selectWidget oo-ui-selectWidget-unpressed oo-ui-clippableElement-clippable oo-ui-floatableElement-floatable oo-ui-menuSelectWidget mw-rcfilters-ui-menuSelectWidget mw-rcfilters-ui-menuSelectWidget-view-namespaces`
It has an inline style set including a width. The calculated width appears to be 10px too big.
Likely an issue with OOUI - "mw-rcfilters-ui-menuSelectWidget-view-namespaces" - the OOUI library sets the width and it's setting it larger than it should be. Looks like it's border box related and will likely need help from @Volker_E to fix this one.
Actual Results:
Expected Results:
Mediawiki provides by default an RSS feed of recent changes at the Special:RecentChanges api endpoint. This is useful for monitoring editing activity. It generates an html summary that is more or less raw embedded wikitext format (for new pages) or a table format (for page revisions).
Given that revisions far outnumber new pages, the RSS feed is usually dominated by such revised pages. When looking at the feed (eg with a feed aggregator / reader) this sets apart the mediawiki rss from other feeds (wordpress blogs etc) which provide occasionally very good html rendering (to the point of not having to look at the page in the browser)
The wiki functionality could be expanded to allow RSS readers to display both new and revised pages in a uniform html format (hence emulating the flow of a blog). This would be useful for RSS viewers who are not interested in the revision details but would like to have an overview of recent content and potentially a quick read-through while in the RSS reader
The implementation could be either an additional endpoint or maybe a configuration flag that changes the format of the existing endpoint
https://translatewiki.net/w/i.php?hidehumans=1&hidepageedits=1&hidelog=1&namespace=8&limit=50&days=90&enhanced=1&title=Special:RecentChanges&urlversion=2&users=&trailer=%2Fen links https://translatewiki.net/w/api.php?hidehumans=1&hidepageedits=1&hidelog=1&namespace=1272&urlversion=2&days=90&limit=50&trailer=%2Fen&action=feedrecentchanges&feedformat=atom which fails to show any item at all.
Some other feeds are working, for instance https://translatewiki.net/w/api.php?hidebots=1&hideminor=1&translations=filter&urlversion=2&days=90&limit=50&action=feedrecentchanges&feedformat=atom
Currently, the rebuildrecentchanges.php script has a pass that enhances entries for page revisions with references to the preceding revision, and the old and new sizes. But the algorithm used in Pass 2 is inaccurate if a page's history contains multiple revisions with the same timestamp. Instead, the script should simply use rev_parent_id to calculate rc_last_oldid, rc_old_len, rc_type, and rc_source. Then, Pass 2 will become redundant, so that pass will be completely removed and all of the following passes will be renumbered.
The rebuildrecentchanges.php script already leaves out $wgFilterLogTypes and page creation log entries in addition to private suppression logs. But it still needs some more improvements.
List of improvements:
* Add the ability to regenerate page categorization entries. (T178038)
* Correctly make edits by autopatrolled users have rc_patrolled = 2. (T199474)
* Delete autogenerated recentchanges entries not just for uploads, but also for null revisions from moves, protections, and imports. (T229458)
* Update the ct_rc_id field to point to the new rc_id for each tagged revision. (T229461)
* Use rev_parent_id instead of an inaccurate algorithm as rc_last_oldid. (T229463)
* Make the autopatrolled edits pass also work correctly for wikis that only have new page patrol, but not recent changes patrol, turned on. (T229466)
* Populate the rc_ip field with the same IP address that performed the edit for IP edits if $wgPutIPinRC is set to true, and possibly also cuc_ip from the cu_changes table if the CheckUser extension is installed.
Too much indentation, and it seems to be more at enwiki than nowiki, which is really weird! Perhaps nowiki didn't get an update? At nowiki we are missing this bug and feel neglected!
Is it some work-in-progress that got rolled out in a half-done state?
Also note [[ https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Problem_with_watchlist_display | w:en:Wikipedia:Village pump (technical)#Problem with watchlist display ]].
{F29513332}
Bug at enwiki
{F29513401}
Less buggy nowiki
Hi everyone,
User:Patriccck reported to me by email that he sees Wikidata changes and categorization changes in Special:RecentChanges, even this isn't enabled in his preferences nor in new RC interface, see attached screenshot. I'm out of ideas, can somebody help, please?
Martin Urbanec
{F29258444}
//Note:// added here a case from comments that illustrates the bug:
the option "Show wikidata edits" is not enabled and "Hide categorization" is enabled and no RC filters are selected, yet wikidata edits and changes in categories are still displayed e.g.
the following options selections
{F29271735}
will result that RC page disregards these options entirely
{F29271742}
@DoRD reports (https://phabricator.wikimedia.org/T220767#5193300)
There is still a problem here. The patch caused the punctuation characters to be displayed again, but the characters cannot be selected in a browser. I haven't tested every browser, but on MacOS at least, this affects both Chrome and Firefox. In most cases, this isn't a problem, however for CheckUsers, it may be an issue.
When investigating complex sockpuppetry cases, I frequently copy/paste CU data into a text editor to make it easier to correctly format the results of the investigation for posting on-wiki. As it stands now, copying the data leaves out the parenthesis and pipe characters, so for this purpose, the fix didn't work. Please see the attached screenshots. [edit] The reason that the parens, etc., are needed for this purpose is because I use regex to find the username, and the first parens is what I search for.
{F29111629}
{F29111628}
@Xaosflux says:
> List users does it as well, for example: https://en.wikipedia.org/wiki/Special:ListUsers?username=DoRD&group=checkuser&wpsubmit=&wpFormIdentifier=mw-listusers-form&limit=1
===== Related tasks
* {T210851}
* {T223872}
Cannot see Topic: entries in Recent Changes in mobile interface
The following change came through on #en.wikipedia on the IRC server:
```
DirNell triggered [[Special:AbuseFilter/34|filter 34]], performing the action "edit" on [[User talk:182.7.221.184]]. Actions taken: Odrzuć ([[Special:AbuseLog/23974551|details]])
```
The "actions taken" is localized to the user's UI language (Polish) instead of the project language.
https://en.wikipedia.org/wiki/Special:AbuseLog/23974551 it says `23:01, 13 May 2019: DirNell (talk | contribs | block) triggered filter 34, performing the action "edit" on User talk:182.7.221.184. Actions taken: Disallow; Filter description: New or unregistered user blanking someone else's user or user talk page`
See this screenshot: This page (https://de.wikipedia.org/w/index.php?title=United-Express-Flug_6291&action=history)
should not get listed here:
{F28971431}
as the page was deleted, other versions imported, and restored the version showed there is not a pagecreation anymore, so it should not get listed as one here. This causes bugs in bot scripts.
These should all have an `mw-` prefix:
```lang=css
.rcfilters-head
.rcfilters-container
.rcfilters-spinner
.rcfilters-spinner-bounce
```
In the English and Spanish Wikipedia (and many others I'm sure), WikiProjects mark articles as being under their scope by adding a template to the articles' talk page ([[ https://en.wikipedia.org/wiki/Template:WPBannerMeta | English example ]], [[ https://es.wikipedia.org/wiki/Plantilla:PR | Spanish example ]]). The template also adds the talk pages to tracking categories for each wikiproject ([[ https://en.wikipedia.org/wiki/Category:High-importance_Philosophy_articles | English example ]], [[ https://es.wikipedia.org/wiki/Categor%C3%ADa:Wikiproyecto:Filosof%C3%ADa/Art%C3%ADculos | Spanish example ]]).
**It would be really useful if we could somehow generate a list of recent changes to articles in these categories.**
However, when using {{Special:RecentChangesLinked}} we only see the changes in the talk pages, rather than changes to the articles themselves (see the demo [[ https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Philosophy/bug | here ]]).
The guided tour for RCFilters and first users is still available on certain languages like Catalan.
Should it be removed?
https://ca.wikipedia.org/w/index.php?title=Especial:Canvis_recents&hidebots=1&hidecategorization=1&hideWikibase=1&limit=50&days=0.0833&enhanced=1&damaging__likelybad_color=c4&damaging__verylikelybad_color=c5&urlversion=2
{F28314063}
>>! In T217400#4993496, @Samwalton9 wrote:
> In particular, of the 200 edits I tested with this, 77 weren't matched. A spot check implies that the revision table has a different (approx one second) timestamp for that edit. Not sure what the source of that issue is, because the timestamp was stored directly from the recentchanges feed, but see for example https://quarry.wmflabs.org/query/33851, which doesn't find the edit with the logged timestamp ("20180831213343"), instead finding it one second later ("20180831213344").
For instance, in [include main + talk]
https://en.wikipedia.org/wiki/Special:RecentChangesLinked?hidebots=1&hideminor=1&hidecategorization=1&hideWikibase=1&target=Wikipedia%3AWikiProject_Academic_Journals%2FLists_of_pages%2FArticles&namespace=0%3B1&limit=1000&days=30&enhanced=1&urlversion=2
No talk pages are reported. Likewise, with [exclude main + talk]
https://en.wikipedia.org/wiki/Special:RecentChangesLinked?hidebots=1&hideminor=1&hidecategorization=1&hideWikibase=1&target=Wikipedia%3AWikiProject_Academic_Journals%2FLists_of_pages%2FArticles&namespace=0%3B1&invert=1&limit=1000&days=30&enhanced=1&urlversion=2
No changes are reported, at all, instead of reporting category, category talk, template, template talk, etc...
Instead of copying Wikibase’s approach of constructing summaries with an autocomment like `/* wbsetsitelink-add:1|frwiki */` and an autosummary containing the value, we want to use the `comment_data` field that’s available in the `comment` table thanks to T166732 to store the information we need to display a translated summary to the user in a structured way (JSON blob). The experience we gain here should be useful when using `comment_data` in Wikibase in the future (T215422).
At the moment, the box for Saved filters is narrow. Long filter descriptions are not easy to read, unless you hover them to get a tooltip. [[ https://www.mediawiki.org/w/index.php?title=Topic:Urlkdjhf93k1fuzk | The request ]] is to have them readable entirely.
For GSoC 2019, the microtask objectives will be:
1. limit the max input length for the filter description. We don't have a finalized input length, but we could start with 128 characters and then get feedback
2. expand the width of the saved filter display. Again we don't have a finalized width, but use your judgement and we can get feedback
Some bots with a bot flag are treated as "Human (not bot)" by Special:RecentChanges. Examples on en-wp include [[ https://en.wikipedia.org/wiki/User:HostBot | User:HostBot ]], [[https://en.wikipedia.org/wiki/User:XLinkBot|User:XLinkBot]] and, most prominently, [[https://en.wikipedia.org/wiki/User:ClueBot_NG| User:ClueBot NG]]. I'll attach one screenshot that shows ClueBot NG's edits with the "Human (not bot)" filter and one that shows that ClueBot NG's edits don't get displayed with a bot flag although ClueBot NG [[https://en.wikipedia.org/wiki/Special:ListUsers?username=ClueBot+NG&group=&wpsubmit=&wpFormIdentifier=mw-listusers-form&limit=1 | has the bot flag]] while another bot's edit gets displayed correctly a few lines down.
{F27835633}{F27835637}
Compare also [[ https://en.wikipedia.org/wiki/User_talk:Jtmorgan#Bot_flag_for_HostBot? | this discussion ]] where I first raised the issue regarding HostBot.
If I create a category tree and then go to Special:RecentChangesLinked, the changes to the pages in the category tree don't show up.
This is unfortunate because using a category tree would be the best way to generate a list of recent changes on a specific topic, which would be really useful for WikiProjects.
Similar to {T164550}.
With Monobook skin, RC and Watchlist filter highlight selection looks like the following:
{F27223838}
Per This discussion: https://en.wikipedia.org/wiki/Wikipedia_talk:New_pages_patrol/Reviewers#Should_we_stop_marking_articles_tagged_with_CSD_and_PROD_as_'reviewed'_now_that_we_can_filter_them_in_the_NewPagesFeed?
We are going to stop marking CSDs and PRODs as 'reviewed' in the new pages feed, to stop things falling through the cracks if the CSD tags are inappropriately removed or a PROD removal is missed. However, this presents a problem at [[Special:NewPages]], which currently will highlight all 'unreviewed' or 'unpatrolled' pages in yellow, with no filtering feature like [[Special:NewPagesFeed]]. The simple fix is to un-highlight pages tagged for deletion, even if unreviewed.
Ideally this should be added as a filtering option similar to the existing:
Show patrolled edits | Hide bots | Show redirects
buttons. An additional button that toggles "un-highlight tagged for deletion" (toggled on by default) would be ideal. However, if this proves to be too difficult, simply treating pages tagged for deletion as 'reviewed' or 'patrolled' for the purposes at [[Special:NewPages]] will work.
Request is here:
https://en.wikipedia.org/wiki/Wikipedia:Page_Curation/Suggested_improvements#85._Special:NewPages_to_not_highlight_pages_if_tagged_for_deletion,_even_if_unreviewed.
[[https://www.mediawiki.org/w/index.php?title=Topic:Uj7w62a5lforw4i2|Based on this feedback on mediawiki.org]]
The goal is to have a way to open all pages displaying changes that have happen after the last visit.
As part of {T192623}, I noticed that RCFilters exports i18n messages by embedding them into the page in an inline script tag. This is fragile and is about to become more fragile, so I'm moving the message blob into `mw.config`. But that just moves it to a different inline script tag, and on enwiki this blob is 9 KB. On top of that, the other config blob for RCFilters (wgStructuredChangeFilters) containing the main filters config is 12.5 KB. The tag list (wgRCFiltersChangeTags) is another 19.2 KB.
Instead of embedding this 40 KB of data into the page and shipping it on each page load, we should load it as an RL module that is only invalidated when the data changes. In order to be able to do this, we would have to solve the following problems.
**Conditional filter registration**: Right now, filters that are available conditionally are registered conditionally. That means that, if the user is not allowed to use the patrol filter, that filter is never registered and the system doesn't even know it exists (for the purposes of that request). An RL data module does not have access to the main request context, and can't vary its output based on who the user is or what the query string parameters are. Instead, these kinds of filters would have to always be registered, and have a property with a callback determining whether they're available or unavailable for a given request. This information would then have to be passed down to the client.
Currently, the following filters are registered conditionally:
* The `reviewStatus` and `legacyReviewStatus` groups are conditional on the user being allowed to patrol, and the special page not being in transclusion mode. Both of these are request-specific, so they aren't OK.
* The `hideCategorization` filter is conditional on `$wgRCWatchCategoryMembership`. This is fine, because it's based on config, not the specific request.
* The `watchlist` group (RC-only) is conditional on the user being logged in and having the `viewmywatchlist` right, and on not being in transclusion mode. None of these are OK.
* ORES filters are conditional on a bunch of things, but they're all config or values periodically being fetched from a service, and none of them are request specific. This is fine.
* Wikibase registers its filters conditional on config (OK) and registers a conflict conditional on ORES being present (OK)
**Filter definitions contain request-dependent data**: Many filters have default values that depend on user preferences. ORES filters also have default highlights that depend on user preferences. To tackle these, we could introduce a new filter definition property to express preference-based defaults declaratively, and handle default highlights either with a callback or on the client. The only preference-based defaults I found that are nontrivial to express are the `userExpLevel` group's default depending on both the `hideliu` and `hideanon` preferences, and the `hidepreviousrevisions` default on WL being the inverse of a preference.
**Filter availability and definitions vary between RC and WL**: `ChangesListSpecialPage::transformFilterDefinition()` is overridden by each subclass to compute `showHide` from `showHideSuffix` where needed, but I don't think that affects filter definitions that get sent to the client. Both RC and WL register filters that only exist on one and not the other: the `watchlist` group is RC-only, and the `extended-group` and `watchlistactivity` groups are WL-only. Some definition properties vary as well. The names of the preferences controlling defaults vary between RC and WL for almost all filters, and a few filters have preference-controlled defaults only on one of the two. We could solve these issues by marking filters/groups as RC-only or WL-only where appropriate, and by having separate rcdefault and wldefault properties.
**Filter definitions are not fully declarative**: they mostly are, but to register subsets and conflicts you need to call methods on the filter objects. This is not a big problem in and of itself (an RL data module could run the code needed to build the tree of objects, then serialize it as we do now), but it's linked to the problem that you need a ChangesListSpecialPage instance to get to a fully-built filter registry. If the definitions are fully declarative, we can just take them and serialize them without needing to run much code (we'd still need to run hooks that extensions use to add filters, or migrate this to an extension.json attribute) and without needing to instantiate a UI class in a place where we're not supposed to be using the request context.
**What we need to solve to pull out what**:
* Tag list: Nothing, this can be pulled out already
* Messages: Conditional registration, RC vs WL differences (need to be able to discover all messages that could possibly be used), full declarativeness (conflicts include messages)
* FIlter data: Everything
This will also affect the `SpecialNewPagesFilters` and `SpecialNewpagesConditions` hooks which are currently only being used by #mediawiki-extensions-flaggedrevs.
It seems a little strange to use spaces to align the lists in 2018.
{F18162664}
{F18162567}
Take this example:
{F16439659, size=full}
What it means is `("Human (not bot)") AND ("Page edits" OR "Page creations" OR "Logged actions") AND ("tag=#AWB" OR "tag=#Blanking")` but the Boolean relationship is not there, and therefore it misleadingly looks like all those combinations are being combined with the same logic (whether it is AND or OR), which is untrue.
This is a design flaw.
One way to fix it is to color code the tags. All tags that define the search scope (e.g. "Page edits" or "Page creations", etc.) can be in one color (say white), all that define other restrictions (e.g. tags, or "May have problems", etc.) in another color such as pink, and we can have multiple color groups corresponding to the multiple logical groups.
{F16440087, size=full}
Another approach is to separate the "Active Filters" section into several parts, each shown in a separate row: Search Scope (where conditions are always combined with OR), Tag Restrictions (where conditions are always combined with OR), namespaces, etc.
{F16439990, size=full}
On the "Recent changes" page. Mediawiki displays "Hide anonymous users" and "Hide registered users" options. It's all good for public wikis, but for private wikis or wikis requiring users to be registered to make modifications, theses options are not useful and not pertinent.
Though MediaWiki now uses active filters on the Recent Changes pages, users can still disable the improved version of this page and be presented with this little UI bug. It is also possible that MediaWiki offers the Unregistered or Registered filters on private/non-public wiki, but I have not been able to check since the MediaWiki version I use is too old.
Based on [[ https://www.mediawiki.org/w/index.php?title=Topic:U7f00kiic7u0dzj0 | that feedback ]]. In Recent changes, it is not possible to access all diffs done by one user that are last on a page.
Consider the following workflow (1 is the oldest, 6 the newest):
# A edits the page
# B edits the page
# A edits the page
# A edits the page
# A edits the page
# A edits the page
The goal would be to have access directly to edits 3 to 6 for B.
"Group changes" gaves a link to access all those 6 edits, that include A and B edits.