Page MenuHomePhabricator
Search Advanced Search
    • Task
    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.
    • Task
    === Behavior 1. Visit [en:Special:RecentChanges&tagfilter=wikieditor](https://en.wikipedia.org/w/index.php?title=Special:RecentChanges&tagfilter=wikieditor) **Actual** 2. ❗️The following error appears: ```[4b6e642b-1b06-4d6d-8444-d22a0051aafa] 2021-12-23 02:57:01: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"``` **Expected** 2. ✅A list of edits that have been tagged with the `wikieditor` change tag (T249038) appear === Done - [ ] Expected behavior is implemented --- ``` 2021-12-23 02:57:01 [4b6e642b-1b06-4d6d-8444-d22a0051aafa] mw1405 enwiki 1.38.0-wmf.13 exception ERROR: [4b6e642b-1b06-4d6d-8444-d22a0051aafa] /w/index.php?title=Special:RecentChanges&tagfilter=wikieditor Wikimedia\Rdbms\DBQueryError: Error 1969: Query execution was interrupted (max_statement_time exceeded) (db1099:3311) Function: SpecialRecentChanges::doMainQuery Query: SET STATEMENT max_statement_time=30 FOR SELECT 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`,wl_user,wl_notificationtimestamp,we_expiry,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 `actor` `recentchanges_actor` ON ((actor_id=rc_actor)) JOIN `comment` `comment_rc_comment` ON ((comment_rc_comment.comment_id = rc_comment_id)) LEFT JOIN `watchlist` ON (wl_user = 35724847 AND (wl_title=rc_title) AND (wl_namespace=rc_namespace)) LEFT JOIN `watchlist_expiry` ON ((wl_id = we_item)) LEFT JOIN `page` ON ((rc_cur_id=page_id)) JOIN `change_tag` ON ((ct_rc_id=rc_id)) LEFT JOIN `flaggedpages` ON ((fp_page_id = rc_cur_id)) LEFT JOIN `ores_classification` `ores_damaging_cls` ON (ores_damaging_cls.oresc_model = 59 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 = 60 AND (ores_goodfaith_cls.oresc_rev=rc_this_oldid) AND ores_goodfaith_cls.oresc_class = 1) WHERE rc_bot = 0 AND (rc_type != 6) AND (rc_source != 'wb') AND (rc_timestamp >= '20211123025630') AND ct_tag_id = 616 AND rc_new IN (0,1) ORDER BY rc_timestamp DESC LIMIT 500 {"exception_url":"/w/index.php?title=Special:RecentChanges&tagfilter=wikieditor","reqId":"4b6e642b-1b06-4d6d-8444-d22a0051aafa","caught_by":"entrypoint"} [Exception Wikimedia\Rdbms\DBQueryError] (/srv/mediawiki/php-1.38.0-wmf.13/includes/libs/rdbms/database/Database.php:1817) Error 1969: Query execution was interrupted (max_statement_time exceeded) (db1099:3311) Function: SpecialRecentChanges::doMainQuery Query: SET STATEMENT max_statement_time=30 FOR SELECT 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`,wl_user,wl_notificationtimestamp,we_expiry,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 `actor` `recentchanges_actor` ON ((actor_id=rc_actor)) JOIN `comment` `comment_rc_comment` ON ((comment_rc_comment.comment_id = rc_comment_id)) LEFT JOIN `watchlist` ON (wl_user = 35724847 AND (wl_title=rc_title) AND (wl_namespace=rc_namespace)) LEFT JOIN `watchlist_expiry` ON ((wl_id = we_item)) LEFT JOIN `page` ON ((rc_cur_id=page_id)) JOIN `change_tag` ON ((ct_rc_id=rc_id)) LEFT JOIN `flaggedpages` ON ((fp_page_id = rc_cur_id)) LEFT JOIN `ores_classification` `ores_damaging_cls` ON (ores_damaging_cls.oresc_model = 59 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 = 60 AND (ores_goodfaith_cls.oresc_rev=rc_this_oldid) AND ores_goodfaith_cls.oresc_class = 1) WHERE rc_bot = 0 AND (rc_type != 6) AND (rc_source != 'wb') AND (rc_timestamp >= '20211123025630') AND ct_tag_id = 616 AND rc_new IN (0,1) ORDER BY rc_timestamp DESC LIMIT 500 #0 /srv/mediawiki/php-1.38.0-wmf.13/includes/libs/rdbms/database/Database.php(1801): Wikimedia\Rdbms\Database->getQueryException(string, integer, string, string) #1 /srv/mediawiki/php-1.38.0-wmf.13/includes/libs/rdbms/database/Database.php(1776): Wikimedia\Rdbms\Database->getQueryExceptionAndLog(string, integer, string, string) #2 /srv/mediawiki/php-1.38.0-wmf.13/includes/libs/rdbms/database/Database.php(1310): Wikimedia\Rdbms\Database->reportQueryError(string, integer, string, string, boolean) #3 /srv/mediawiki/php-1.38.0-wmf.13/includes/libs/rdbms/database/Database.php(2020): Wikimedia\Rdbms\Database->query(string, string, integer) #4 /srv/mediawiki/php-1.38.0-wmf.13/includes/libs/rdbms/database/DBConnRef.php(68): Wikimedia\Rdbms\Database->select(array, array, array, string, array, array) #5 /srv/mediawiki/php-1.38.0-wmf.13/includes/libs/rdbms/database/DBConnRef.php(307): Wikimedia\Rdbms\DBConnRef->__call(string, array) #6 /srv/mediawiki/php-1.38.0-wmf.13/includes/specials/SpecialRecentChanges.php(410): Wikimedia\Rdbms\DBConnRef->select(array, array, array, string, array, array) #7 /srv/mediawiki/php-1.38.0-wmf.13/includes/specialpage/ChangesListSpecialPage.php(1018): SpecialRecentChanges->doMainQuery(array, array, array, array, array, FormOptions) #8 /srv/mediawiki/php-1.38.0-wmf.13/includes/specialpage/ChangesListSpecialPage.php(617): ChangesListSpecialPage->getRows() #9 /srv/mediawiki/php-1.38.0-wmf.13/includes/specials/SpecialRecentChanges.php(199): ChangesListSpecialPage->execute(NULL) #10 /srv/mediawiki/php-1.38.0-wmf.13/includes/specialpage/SpecialPage.php(671): SpecialRecentChanges->execute(NULL) #11 /srv/mediawiki/php-1.38.0-wmf.13/includes/specialpage/SpecialPageFactory.php(1377): SpecialPage->run(NULL) #12 /srv/mediawiki/php-1.38.0-wmf.13/includes/MediaWiki.php(314): MediaWiki\SpecialPage\SpecialPageFactory->executePath(string, RequestContext) #13 /srv/mediawiki/php-1.38.0-wmf.13/includes/MediaWiki.php(903): MediaWiki->performRequest() #14 /srv/mediawiki/php-1.38.0-wmf.13/includes/MediaWiki.php(563): MediaWiki->main() #15 /srv/mediawiki/php-1.38.0-wmf.13/index.php(53): MediaWiki->run() #16 /srv/mediawiki/php-1.38.0-wmf.13/index.php(46): wfIndexMain() #17 /srv/mediawiki/w/index.php(3): require(string) #18 {main} ```
    • Task
    **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}
    • Task
    **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}
    • Task
    **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
    • Task
    **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)
    • Task
    **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)
    • Task
    **List of steps to reproduce** (step by step, including full links if applicable): * Create a new page * Delete it and restore it * Check Special:NewPages **What happens?**: The page is missing from Special:NewPages **What should have happened instead?**: The page should be added back to Special:NewPages **Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc**: 1.35.3
    • Task
    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)
    • Task
    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.
    • Task
    **List of steps to reproduce** (step by step, including full links if applicable): * Go to Special:CheckUser and do a check (go to the "get edits" page after getting the IP) * Look for the user creation part of the log **What happens?**: You will notice the result not displaying the correct username of the user being checked. Example (with name generalized) of what it says: "User account Unknown user was created" **What should have happened instead?**: It should have the username instead. **Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc**: Considering the problem has happened for usernames from July 13 onward, I assume it is related to https://gerrit.wikimedia.org/r/c/mediawiki/core/+/684142?
    • Task
    [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.
    • Task
    ==== Error ==== * mwversion: `1.37.0-wmf.4` * reqId: `9a3c67fe-3e34-49b7-99bc-3785b6d03f72` * [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2021-05-11T18:10:56.000Z',to:'2021-05-12T18:44:12.049Z'))&_a=(query:(query_string:(query:'reqId:%229a3c67fe-3e34-49b7-99bc-3785b6d03f72%22'))) | Find reqId in Logstash ]] * [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:now-30d,to:now))&_a=(query:(query_string:(query:'normalized_message:%22Exception%20executing%20job:%20categoryMembershipChange%20User:AmandaNP/UAA/Wait%20pageId=36395484%20revTimestamp=20210512180106%20namespace=2%20title=AmandaNP/UAA/Wait%20requestId=9a3c67fe-3e34-49b7-99bc-3785b6d03f72%20:%20Wikimedia%5CRdbms%5CDBQueryDisconnectedError:%20A%20connectio%22'))) | Find normalized_message in Logstash ]] ```name=normalized_message Exception executing job: categoryMembershipChange User:<user>/<subpage>/<page with a ton of links to user pages> pageId=36395484 revTimestamp=20210512180106 namespace=2 title=User:<user>/<subpage>/<page with a ton of links to user pages> requestId=9a3c67fe-3e34-49b7-99bc-3785b6d03f72 : Wikimedia\Rdbms\DBQueryDisconnectedError: A connectio ``` ```name=exception.trace,lines=10 from /srv/mediawiki/php-1.37.0-wmf.4/includes/libs/rdbms/database/Database.php(1736) #0 /srv/mediawiki/php-1.37.0-wmf.4/includes/libs/rdbms/database/Database.php(1722): Wikimedia\Rdbms\Database->getQueryException(string, integer, string, string) #1 /srv/mediawiki/php-1.37.0-wmf.4/includes/libs/rdbms/database/Database.php(1697): Wikimedia\Rdbms\Database->getQueryExceptionAndLog(string, integer, string, string) #2 /srv/mediawiki/php-1.37.0-wmf.4/includes/libs/rdbms/database/Database.php(1260): Wikimedia\Rdbms\Database->reportQueryError(string, integer, string, string, boolean) #3 /srv/mediawiki/php-1.37.0-wmf.4/includes/libs/rdbms/database/Database.php(4996): Wikimedia\Rdbms\Database->query(string, string, integer) #4 /srv/mediawiki/php-1.37.0-wmf.4/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1758): Wikimedia\Rdbms\Database->ping() #5 /srv/mediawiki/php-1.37.0-wmf.4/includes/libs/rdbms/loadbalancer/LoadBalancer.php(2253): Wikimedia\Rdbms\LoadBalancer::Wikimedia\Rdbms\{closure}(Wikimedia\Rdbms\DatabaseMysqli) #6 /srv/mediawiki/php-1.37.0-wmf.4/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1764): Wikimedia\Rdbms\LoadBalancer->forEachOpenMasterConnection(Closure) #7 /srv/mediawiki/php-1.37.0-wmf.4/includes/libs/rdbms/lbfactory/LBFactory.php(249): Wikimedia\Rdbms\LoadBalancer->approveMasterChanges(array, string, integer) #8 /srv/mediawiki/php-1.37.0-wmf.4/includes/libs/rdbms/lbfactory/LBFactoryMulti.php(236): Wikimedia\Rdbms\LBFactory::Wikimedia\Rdbms\{closure}(Wikimedia\Rdbms\LoadBalancer, string, array) #9 /srv/mediawiki/php-1.37.0-wmf.4/includes/libs/rdbms/lbfactory/LBFactory.php(251): Wikimedia\Rdbms\LBFactoryMulti->forEachLB(Closure, array) #10 /srv/mediawiki/php-1.37.0-wmf.4/includes/libs/rdbms/lbfactory/LBFactory.php(310): Wikimedia\Rdbms\LBFactory->forEachLBCallMethod(string, array) #11 /srv/mediawiki/php-1.37.0-wmf.4/extensions/EventBus/includes/JobExecutor.php(287): Wikimedia\Rdbms\LBFactory->commitMasterChanges(string, array) #12 /srv/mediawiki/php-1.37.0-wmf.4/extensions/EventBus/includes/JobExecutor.php(81): MediaWiki\Extension\EventBus\JobExecutor->commitMasterChanges(Wikimedia\Rdbms\LBFactoryMulti, string) #13 /srv/mediawiki/rpc/RunSingleJob.php(76): MediaWiki\Extension\EventBus\JobExecutor->execute(array) #14 {main} ``` ==== Impact ==== Probably prevents the page from showing up on watchlists of users who are watching the category, which can break patrolling workflows. Happens [[https://logstash.wikimedia.org/goto/d07998ab14518652e3fe99ba4907ffd9|a few dozen times a day]]. ==== Notes ==== * Found this failing multiple times over many days for a single page, see logstash link for details
    • Task
    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?
    • Task
    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 ```
    • Task
    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) ```
    • Task
    [[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]].
    • Task
    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.
    • Task
    //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}
    • Task
    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.
    • Task
    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]])// Compare it to grouped lines for ordinary edits, and notice "(cur | prev)" are missing even though diff links for non-grouped category changes are available at the end of each line. Also there are no history links, and `title` and `curid` in the permalinks (timestamps) are wrong (`title` is that of the category and the second `curid` is same as the first—this part being tracked as T270774). So it should be more like: - 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=3_Park_Avenue&curid=9288855&oldid=995594781|22:24]] ([[https://en.wikipedia.org/w/index.php?title=3_Park_Avenue&curid=9288855&diff=0&oldid=995594781|cur]] | [[https://en.wikipedia.org/w/index.php?title=3_Park_Avenue&curid=9288855&diff=995594781&oldid=995594692|prev]]) . . [[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=3_Park_Avenue&curid=9288855&action=history|hist]]) -- [[https://en.wikipedia.org/w/index.php?title=Lexington_Avenue&curid=1336073&oldid=995594739|22:23]] ([[https://en.wikipedia.org/w/index.php?title=Lexington_Avenue&curid=1336073&diff=0&oldid=995594739|cur]] | [[https://en.wikipedia.org/w/index.php?title=Lexington_Avenue&curid=1336073&diff=995594739&oldid=995594662|prev]]) . . [[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]])// ([[https://en.wikipedia.org/w/index.php?title=3_Park_Avenue&curid=1336073&action=history|hist]]) with - "cur" and "prev" diffs - "hist" link - correct `title` - correct `curid` See also the corollary {T148533}.
    • Task
    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.
    • Task
    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.
    • Task
    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.
    • Task
    Hello, I noticed about a <hr> tag that goes through the Legend box in Recent changes page (I have chosen Use non-JavaScript interface option in the preferences) See the image below: {F32252195} I think this happened because the Legend box has no color. After I added ##background-color: white;## to the Legend box, the problem was resolved. See the image below: {F32252207} I think all Wikis affected with this. Thanks!
    • Task
    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
    • Task
    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`
    • Task
    After merging a user, the log event is not visible on Special:RecentChanges, only on Special:Log. In fact, the "usermerge" log events are not recorded in the `recentchanges` table at all. ---- **Instructions for solving:** In `includes/UserMergeLogger.php`, save the return value of `ManualLogEntry::insert` and call `ManualLogEntry::publish` with it.
    • Task
    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, … ]; ```
    • Task
    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
    • Task
    Steps to Reproduce: # Visit recent changes of a wiki which has ORES edit predictions enabled (eg. cswiki, Wikidata). # Use only the filters "Very likely has problems" & "Page edits" ([[ https://cs.wikipedia.org/w/index.php?damaging=verylikelybad&hidenewpages=1&hidecategorization=1&hideWikibase=1&hidelog=1&enhanced=1&title=Speci%C3%A1ln%C3%AD:Posledn%C3%AD_zm%C4%9Bny&urlversion=2&uselang=en | link ]]). Notice there is a legend which explains the meaning of **r**. # Try both grouped and ungrouped mode, old interface or watchlist. Actual Results: - None of these changes has **r** indicator, although they are identified as potentially problematic. Highlighting does work. - Surprisingly, the indicators can be seen in Special:Contributions. Expected Results: - Changes identified as potentially problematic have **r** indicator in the recent changes (watchlist). | ungrouped recent changes (cswiki) | grouped recent changes (cswiki) | [[ https://cs.wikipedia.org/wiki/Speci%C3%A1ln%C3%AD:P%C5%99%C3%ADsp%C4%9Bvky/2A00:1028:8D1A:461A:6165:BF4B:63D1:667B?uselang=en | contributions ]] | {F34112251} | {F34112247} | {F34112249}
    • Task
    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.
    • Task
    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.
    • Task
    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.
    • Task
    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 | | +------+--------------------+--------------------+--------+--------------------------------------------------------+-----------------------+---------+-----------------------------------------------------------------------+---------+-----------------------------+ ```
    • Task
    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.
    • Task
    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.
    • Task
    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.
    • Task
    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.
    • Task
    **Problem: ** If you combine many filters the page will not load. **Note:** Also true for Wikipedia. **Solution:** Set max limit to 100? **Example:** https://www.wikidata.org/wiki/Special:RecentChanges?hidebots=1&reviewStatus=unpatrolled&hidepreviousrevisions=1&hidecategorization=1&namespace=12%3B120%3B146%3B640%3B828&limit=100&days=30&enhanced=1&urlversion=2 (not working) **Original:** ```name=Error message [XdzZwApAICMAAJF8grcAAAAJ] 2019-11-26 07:53:33: Fatal exception of type "WMFTimeoutException" ``` ```name=trace #0 /srv/mediawiki/php-1.35.0-wmf.5/includes/exception/MWExceptionHandler.php(200): {closure}(integer) #1 [internal function]: MWExceptionHandler::handleError(integer, string, string, integer, array) #2 /srv/mediawiki/php-1.35.0-wmf.5/includes/libs/rdbms/database/DatabaseMysqli.php(46): mysqli->query(string) #3 /srv/mediawiki/php-1.35.0-wmf.5/includes/libs/rdbms/database/Database.php(1308): Wikimedia\Rdbms\DatabaseMysqli->doQuery(string) #4 /srv/mediawiki/php-1.35.0-wmf.5/includes/libs/rdbms/database/Database.php(1226): Wikimedia\Rdbms\Database->executeQueryAttempt(string, string, boolean, string, integer) #5 /srv/mediawiki/php-1.35.0-wmf.5/includes/libs/rdbms/database/Database.php(1162): Wikimedia\Rdbms\Database->executeQuery(string, string, integer) #6 /srv/mediawiki/php-1.35.0-wmf.5/includes/libs/rdbms/database/Database.php(1828): Wikimedia\Rdbms\Database->query(string, string) #7 /srv/mediawiki/php-1.35.0-wmf.5/includes/libs/rdbms/database/DBConnRef.php(68): Wikimedia\Rdbms\Database->select(array, array, array, string, array, array) #8 /srv/mediawiki/php-1.35.0-wmf.5/includes/libs/rdbms/database/DBConnRef.php(318): Wikimedia\Rdbms\DBConnRef->__call(string, array) #9 /srv/mediawiki/php-1.35.0-wmf.5/includes/specials/SpecialRecentChanges.php(349): Wikimedia\Rdbms\DBConnRef->select(array, array, array, string, array, array) #10 /srv/mediawiki/php-1.35.0-wmf.5/includes/specialpage/ChangesListSpecialPage.php(1024): SpecialRecentChanges->doMainQuery(array, array, array, array, array, FormOptions) #11 /srv/mediawiki/php-1.35.0-wmf.5/includes/specialpage/ChangesListSpecialPage.php(629): ChangesListSpecialPage->getRows() #12 /srv/mediawiki/php-1.35.0-wmf.5/includes/specials/SpecialRecentChanges.php(165): ChangesListSpecialPage->execute(NULL) #13 /srv/mediawiki/php-1.35.0-wmf.5/includes/specialpage/SpecialPage.php(575): SpecialRecentChanges->execute(NULL) #14 /srv/mediawiki/php-1.35.0-wmf.5/includes/specialpage/SpecialPageFactory.php(607): SpecialPage->run(NULL) #15 /srv/mediawiki/php-1.35.0-wmf.5/includes/MediaWiki.php(298): MediaWiki\Special\SpecialPageFactory->executePath(Title, RequestContext) #16 /srv/mediawiki/php-1.35.0-wmf.5/includes/MediaWiki.php(967): MediaWiki->performRequest() #17 /srv/mediawiki/php-1.35.0-wmf.5/includes/MediaWiki.php(530): MediaWiki->main() #18 /srv/mediawiki/php-1.35.0-wmf.5/index.php(46): MediaWiki->run() #19 /srv/mediawiki/w/index.php(3): require(string) #20 {main} ``` ##### Impact Unable to see the recent changes with the filters applied
    • Task
    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)
    • Task
    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}
    • Task
    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.
    • Task
    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.
    • Task
    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)
    • Task
    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:
    • Task
    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
    • Task
    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
    • Task
    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.
    • Task
    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.
    • Task
    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
    • Task
    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}
    • Task
    @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}
    • Task
    Cannot see Topic: entries in Recent Changes in mobile interface
    • Task
    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`
    • Task
    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.
    • Task
    These should all have an `mw-` prefix: ```lang=css .rcfilters-head .rcfilters-container .rcfilters-spinner .rcfilters-spinner-bounce ```
    • Task
    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 ]]).
    • Task
    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}
    • Task
    >>! 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").
    • Task
    The issue is present on `cawiki` and `dewiki`. 1. On Special:RecentChanges (Special:Watchlist) click on the bookmark icon to save a filter. 2. The dialog box will be displayed - the bookmark icon is displayed on a separate line (may be it's worth fixing it too). {F28297241} 3. Click in the check box "Set as defaul", "Create default filter" button will be pushed below 'Cancel'. {F28297304} The same issue is present on `dewiki`: {F28297322}
    • Task
    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...
    • Task
    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).
    • Task
    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
    • Task
    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.
    • Task
    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.
    • Task
    Similar to {T164550}. With Monobook skin, RC and Watchlist filter highlight selection looks like the following: {F27223838}
    • Task
    Steps to become frustrated: # Begin by hating the "Group results by page" prefs setting. None of this matters if you think that ugly, unintuitive, inefficient, overbroad page layout is a good thing. # Go to Special:RecentChanges. It looks so nice, right? Everything is working perfectly. # Click "Tags" and choose a tag. (I chose #AWB.) # Notice that the page still looks nice, and everything is fine. # Click a URL from someone who is using the ugly style, e.g., https://en.wikipedia.org/w/index.php?hidebots=1&hidecategorization=1&hideWikibase=1&tagfilter=AWB&limit=100&days=7&enhanced=1&title=Special:RecentChanges&urlversion=2 # Discover that this innocent-looking URL has given you the ugly style. # Just go back to Special:RecentChanges and try to do it the right way. Discover that the URL has secretly changed your preferences, so now everything is ugly. # Discover that hand-editing the original URL to say `&enhanced=0` will temporarily take away the ugly, but it doesn't fix your prefs, so it stays ugly forever, unless and until you figure out which of the jillions of prefs is the screwed up one.
    • Task
    [[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.
    • Task
    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
    • Task
    It seems a little strange to use spaces to align the lists in 2018. {F18162664} {F18162567}
    • Task
    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}
    • Task
    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.
    • Task
    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.
    • Task
    [[https://www.mediawiki.org/wiki/Topic:U7e6w1nm8d2pbrfx|Initial report]]: > If I'm hovering over a link in my watchlist using Navigation Popups at the moment the live update happens, the popups window does not disappear once I move off the link. I have to reload the page to fix the problem. I have found that oddly, this is a problem in Chrome but not in IE. I've tried with Chromium (the closest I have) and I have a persistant pop-up as well. But I manage to have it disappearing when I hover another link. When I use Firefox, the pop-ups overlap each other when I hover a new link, but they disappear when I move my cursor.
    • Task
    When changing a page X to Y that is connected to wikidata, the sitelinks is automatically updated, and the change is propagated correctly to other wikis generating "Language link changed from $1 to $2" message in recent changes. Additionally the change is propagated WRONGLY to the original site where there was a move - and links to invalid URLs for example: 1. This change: https://www.wikidata.org/w/index.php?title=Special:EntityPage/Q1186451&curid=1131433&diff=627491344&oldid=459038914 2. Result in link to: https://www.wikidata.org/wiki/%D7%93%D7%95%D7%97_%D7%A2%D7%9C_%D7%94%D7%A9%D7%99%D7%A0%D7%95%D7%99%D7%99%D7%9D_%D7%91%D7%94%D7%95%D7%9F_%D7%94%D7%A2%D7%A6%D7%9E%D7%99 (as appear in recent changes) So we have here 2 issues: 1. The URL in the recent changes points to wrong URL 2. The change shouldn't propagate to the original wiki(?) as it already updated
    • Task
    When enabling RCFeed ( [[ https://www.mediawiki.org/wiki/Manual:$wgRCFeeds | $wgRCFeeds ]] ) and PHP doesn't have the `php-sockets` extension, if you save an edit, it gets saved but no entry is inserted in the recent changes table. It doesn't add a job to update it neither. Hopefully the debug log displays this information (this happens with a udp URL at least): ``` [error] [31c24f9a84f1fe30a76eaa4c] /index.php?title=Hijo&action=submit ErrorException from line 66 of /home/www/lib/mediawiki-1.30.0/includes/libs/UDPTransport.php: PHP Notice: Use of undefined constant AF_INET - assumed 'AF_INET' #0 /home/www/lib/mediawiki-1.30.0/includes/libs/UDPTransport.php(66): MWExceptionHandler::handleError(integer, string, string, integer, array) #1 /home/www/lib/mediawiki-1.30.0/includes/rcfeed/UDPRCFeedEngine.php(33): UDPTransport::newFromString(string) #2 /home/www/lib/mediawiki-1.30.0/includes/rcfeed/FormattedRCFeed.php(66): UDPRCFeedEngine->send(array, string) #3 /home/www/lib/mediawiki-1.30.0/includes/changes/RecentChange.php(432): FormattedRCFeed->notify(RecentChange, NULL) #4 /home/www/lib/mediawiki-1.30.0/includes/changes/RecentChange.php(354): RecentChange->notifyRCFeeds() #5 /home/www/lib/mediawiki-1.30.0/includes/changes/RecentChange.php(629): RecentChange->save() #6 [internal function]: RecentChange::{closure}() #7 /home/www/lib/mediawiki-1.30.0/includes/deferred/MWCallableUpdate.php(30): call_user_func(Closure) #8 /home/www/lib/mediawiki-1.30.0/includes/deferred/DeferredUpdates.php(257): MWCallableUpdate->doUpdate() #9 /home/www/lib/mediawiki-1.30.0/includes/deferred/DeferredUpdates.php(210): DeferredUpdates::runUpdate(MWCallableUpdate, Wikimedia\Rdbms\LBFactorySimple, string, integer) #10 /home/www/lib/mediawiki-1.30.0/includes/deferred/DeferredUpdates.php(131): DeferredUpdates::execute(array, string, integer) #11 /home/www/lib/mediawiki-1.30.0/includes/MediaWiki.php(895): DeferredUpdates::doUpdates(string) #12 /home/www/lib/mediawiki-1.30.0/includes/MediaWiki.php(719): MediaWiki->restInPeace(string, boolean) #13 /home/www/lib/mediawiki-1.30.0/includes/MediaWiki.php(740): MediaWiki->{closure}() #14 /home/www/lib/mediawiki-1.30.0/includes/MediaWiki.php(553): MediaWiki->doPostOutputShutdown(string) #15 /home/www/lib/mediawiki-1.30.0/index.php(43): MediaWiki->run() #16 {main} [fatal] [bb713578] PHP Fatal Error: Call to undefined function socket_create() ``` MediaWiki should probably check for `socket_create` if $wgRCFeeds is set, and fail early (prevent the save at all), or catch the error, log it and continue without breaking all jobs that need to be inserted.
    • Task
    The text is really small. See screenshot. {F11984294}
    • Task
    If a page is moved/or protected and the resultant null revision is hidden using RevisionDelete, the entry on RecentChanges displays incorrectly with the username and summary visible but the action replaced by "(log details removed)", although the log entry hasn't been actually deleted from Special:Log.
    • Task
    https://meta.wikimedia.org/wiki/Category:2017_Community_Wishlist_Survey/Proposals Navigate to "related changes" in the sidebar. Observe the wrong value of the "show changes in pages linked from" box. https://meta.wikimedia.org/wiki/Special:RecentChangesLinked/Category:2017_Community_Wishlist_Survey?hidebots=1&translations=filter&hidecategorization=1&hideWikibase=1&limit=50&days=7&target=Proposals&urlversion=2 The resulting URL (above) also doesn't seem correct. Then reload the page using your browser's inbuilt functionality. The results returned are based upon the root page (here [[Category:2017_Community_Wishlist_Survey]]) instead of the original input page. Probably a regression, my memory fails me.
    • Task
    While loading Recent Changes/Watchlist with combined items, the line height shifts, making content after the first or second collapsed item to slightly shift up, while the rest of the page is stable during load. See the screenshots (from https://de.wikipedia.beta.wmflabs.org/wiki/Spezial:Letzte_%C3%84nderungen?hidebots=1&hidecategorization=1&hideWikibase=1&limit=50&days=30&enhanced=1&urlversion=2): {F11103322} {F11103324} Starting with the entry from 10:50 the contents slightly move up during load. This happens with disabled RC filters, too. It's also visible on the watchlist.
    • Task
    [[ https://www.mediawiki.org/w/index.php?title=Topic:U2rt9ptfmwc31vwd | Initial report. ]] **Issue** As a user, I can't easily determine the beginning and end of a recent change item. It often has to struggle to see where the entry ends when there are a lot of very verbose changes. **Proposed solution** Add css to highlight the specific line on mouse hover, e.g.: ``` .mw-changeslist-line:hover { background: lightgray; } ```
    • Task
    Hello. Opt in grouping by page in preferences. * In recent changes, grouped edits font is smaller than single. * In watchlist, grouped edits font is larger than single. Checked with safemode. Recognized on Android.
    • Task
    When running rebuildrecentchanges.php, the script should regenerate CatWatch entries if the feature ($wgRCWatchCategoryMembership) is enabled. Page moves are followed, so that if the entry previously said "A added to category" or "A removed from category" and A was moved to B, the entry would instead say "B added to category" or "B removed from category" after running the script.
    • Task
    Currently we have many Wikibase client recent changes entries with the very same `rc_params` values, as these don't depend on the page changed. In order to allow for de-duplication here, we should move this into a separate table and make `rc_params` point to it. This could be done by putting an integer string into the field, pointing to the PK in a `recent_change_params` table. When purging out RC rows, we would need to check whether the `recent_change_params` row(s) are still used and if not, they need to be purged along.
    • Task
    [[https://www.mediawiki.org/wiki/Topic:Tz8xehx7nmj77b7m|Copied from here]]: It is not possible to distinguish, differentiate or filter redirects. They are often represented as "new pages". Possible solution: add a legend ("↳") with a marker to denote the redirect. ``` .mw-redirect.mw-changeslist-title::before { content: '↳'; } ``` CSS suggestion from T177281#5322465: ```lang=css .mw-tag-mw-new-redirect .mw-title:before, .mw-tag-mw-changed-redirect-target .mw-title:before { content: '↳'; } ```
    • Task
    Inspired by T169457... There are at least two cases where rollback and dummy ("null") revisions (e.g. protection events) do not interact well. Suppose "Bot" is a page-protection bot (it could also be a Sysop doing that manually and missing the vandalism). Any log-type null-revision generating event will do. Case I ---- **Edit 3 - Admin; manual revert to version #0** Edit 2 - Bot; null revision (=version #1) Edit 1 - Vandal; vandalism Edit 0 - Editor; OK version Rollback was not an option for Admin here since rollback of #2 would try to revert Bot and go to #1. Those have the same text, so it would error out. Ideally edit #3 could be "Reverted edits by Vandal to last version by Editor)" via [rollback]. Case II ---- **Edit 4 - Admin; manual revert to version #0** Edit 3 - Vandal; vandalism Edit 2 - Bot; null revision (=version #1) Edit 1 - Vandal; vandalism Edit 0 - Editor; OK version Rollback was not an option for Admin since they noticed the vandalism from #1 in addition to #3. Ideally edit #4 could be "Reverted edits by Vandal to last version by Editor)" via normal rollback. This won't handle the case were the edits were from two different vandals, but it could at least detect that when they are the same. This could probably make use of rev_sha1. For case #1, history would need to show [rollback] links for the last non-null revision. Ideally, recentchanges too, but that would probably be too expensive.
    • Task
    Currently the enhanced changes list uses JavaScript from module `jquery.makeCollapsible` to collapse and expand the entries. It would be nice to use a hidden checkbox and CSS to collapse the entries. This improves the performance on loading and allows using the enhanced changes list on clients without JavaScript. Inspiration from https://gerrit.wikimedia.org/r/359474
    • Task
    As part of completing the New Filters for Edit Review project, it's desirable to consolidate the preferences currently spread across the Watchlist and Recent Changes preference tabs into one tab, named "Monitoring changes." Two main considerations recommend this course: # The current arrangement is disorganized and illogical. The two tabs already control behavior on an odd mixture of pages for which no tabs exist, including History, Logs and Contributions. A consolidated tab with sections named for the relevant pages will more accurately reflect the functionality presented. # The New Filters UX enables users to save default page settings directly on RC page and Watchlists—a clear win for usability. When this capability is fully in place, having a parallel system for setting defaults on the Preferences pages is confusing and messy. Once such duplicative preferences are removed, however, the relatively small number of Watchlist and RC page preferences that validly remain aren't numerous enough to justify two separate Preferences tabs. In addition to being more logical, a unified tab enables us to more neatly manage the four possible states that a user can move through with respect to Watchlist and RC page. These four states and the functionality that pertains to them are described on the following four tickets. In addition, a fifth ticket describes the rules that will govern migration and conversion from the old system to the new: - {T172352} - {T172349} - {T172468} - {T172474} - {T172757} =Requirements - When a user moves to the New Filters UX, all user preferences from the old system will be transferred to their equivalents in the new UX for that user (see T172757 for details of old-to-new translation). - When New Filters users bookmark settings to the Saved Filters menu, and declare those settings Default (using the "Set as default" option), the default on-page settings override any existing page preferences that were set on the Preferences pages. - Many existing user preferences will no longer be visible on the consolidated "Change Monitoring" preference page (as detailed in the four subtasks above). However, all such hidden preferences will be stored for each user. - In the event a user opts out of the New Filters on RC or WL or both, all their old preferences, including the hidden ones, will be restored. (Their OLD preferences will be restored; i.e., we don't need to send on-page defaults "upstream" to be stored as hidden preferences).
    • Task
    Is there a useful and non-confusing way to display the patrolled/unpatrolled filters on Special:RecentChanges, when RC Patrol is false? Note, you can already hide patrolled edits on Special:NewPages, and you can hide either patrolled or unpatrolled on Special:NewPagesFeed. --- Basically, the issue is that if you just do it literally based on what's currently marked patrolled, it works fine on wikis with RC Patrol true (when you have hidepatrolled=1, everything you see is patrollable). But on wikis with RC Patrol false, when you have hidepatrolled=1, most of what you see is not patrollable. See below diagrams. {F8861646} {F8861647} --- In theory, we could have both hidepatrolled=1 or hideunpatrolled=1 limit the result set to only include entries that are generally patrollable (plus non-patrollable log types). For RC Patrol = true, this is equivalent to what we already do. For RC Patrol = false, it would mean most entries were hidden when using either of these options (Only entries relevant to patrolling would be shown). This would make it our first non-full coverage boolean group, which would need a tweak to the backend (we can make the two group items conflict with each other). We would potentially need to change the labels to make it clear (e.g. "Patrollable but not already patrolled" and "Patrollable and already patrolled").
    • Task
    Currently Recent changes are listed as a bulleted list which makes them quite difficult to scan. For a long time I've been thinking of a table view which I believe would make a user experience much better. I've made a "test table" with some random entries of this day just to represent the idea a little bit easier: * https://en.wikipedia.org/wiki/User:Janezdrilc#Recent_changes
    • Task
    When you have the "New filters for edit review" beta feature enabled and you open the filters pop-up, I expect that clicking anywhere outside the pop-up will dismiss the pop-up. However, if I click anywhere inside the mw-rcfilters-ui-filterTagMultiselectWidget div (including the empty margin above the active filters interface), it fails to dismiss the pop-up.
    • Task
    (IPs replaced with placeholders for privacy) From https://www.mediawiki.org/wiki/Special:RecentChanges?enhanced=1&hideliu=1&namespace=1 . 6 July 2017 13:32 Talk:Reading/Web/PDF Functionality‎‎ (1 change | history) . . (+13)‎ . . [1.2.3.4; 1234:5678:9012:3456:7890:1234:5678:9012; 3.4.5.6; 4.5.6.7] 13:32 . . (+13)‎ . . 1.2.3.4 (talk)
    • Task
    {F8687341, size=full} There were 2 changes to the item connected with "Hilfe:Variablen" on Wikidata. They are linked correctly in expanded view, but the combined link ("2 Änderungen") links a local diff, which is wrong and confusing.
    • Task
    As a new user or a logged out user, when I go to RecentChanges page, I can click on a "show Wikidata edits". If I select it, I don't see Wikidata edits. It is confusing. See also: * {T169108}
    • Task
    Update documentation once Wikidata changes are enabled in enhanced recent changes on Wikipedia. - https://meta.wikimedia.org/wiki/Help:Enhanced_recent_changes - On English Wikipedia, in the RC tab of the preferences, the label of checkbox includes "(de-activate for the "Show Wikidata" option below to work)" - and probably elsewhere
    • Task
    On my RC page, I have all Wikidata results despite I don't filter them ([[ https://fr.wikipedia.org/wiki/Sp%C3%A9cial:Modifications_r%C3%A9centes?urlversion=2&damaging=verylikelybad&hidepreviousrevisions=1 | URL ]]). I haven't checked the " Show Wikidata edits in recent changes" option in my preferences. {F8548245} If the "Wikidata edits" option is not selected, I expect to have no Wikidata results in my list of results. May be related to {T159787} or {T46874}
    • Task
    From production. This is probably another case where there are simply few or no matches, and insufficient indexes (like its parent {T164796}). However, in this case, instead of just being slow it times out entirely. ``` mattflaschen@mwlog1001:~$ grep -A20 WUPWEgpAIDgAAFdx4R8AAAAQ /srv/mw-log/exception.log 2017-06-16 12:59:58 [WUPWEgpAIDgAAFdx4R8AAAAQ] mw1186 enwiki 1.30.0-wmf.5 exception ERROR: [WUPWEgpAIDgAAFdx4R8AAAAQ] /w/index.php?namespace=1&tagfilter=visualeditor&title=Special:RecentChanges&hidecategorization=1&hideWikibase=1&hidelog=1&hidepageedits=1 Wikimedia\Rdbms\DBQueryError from line 1145 of /srv/mediawiki/php-1.30.0-wmf.5/includes/libs/rdbms/database/Database.php: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading? Query: SELECT rc_id,rc_timestamp,rc_user,rc_user_text,rc_namespace,rc_title,rc_comment,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,wl_user,wl_notificationtimestamp,page_latest,(SELECT GROUP_CONCAT(ct_tag SEPARATOR ',') FROM `change_tag` 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` LEFT JOIN `watchlist` ON (wl_user = '26209855' AND (wl_title=rc_title) AND (wl_namespace=rc_namespace)) LEFT JOIN `page` ON ((rc_cur_id=page_id)) INNER JOIN `change_tag` ON ((ct_rc_id=rc_id)) LEFT JOIN `flaggedpages` ON ((fp_page_id = rc_cur_id)) LEFT JOIN `ores_model` `ores_damaging_mdl` ON (ores_damaging_mdl.oresm_is_current = '1' AND ores_damaging_mdl.oresm_name = 'damaging') LEFT JOIN `ores_classification` `ores_damaging_cls` ON ((ores_damaging_cls.oresc_model = ores_damaging_mdl.oresm_id) AND (rc_this_oldid = ores_damaging_cls.oresc_rev) AND ores_damaging_cls.oresc_class = '1') LEFT JOIN `ores_model` `ores_goodfaith_mdl` ON (ores_goodfaith_mdl.oresm_is_current = '1' AND ores_goodfaith_mdl.oresm_name = 'goodfaith') LEFT JOIN `ores_classification` `ores_goodfaith_cls` ON ((ores_goodfaith_cls.oresc_model = ores_goodfaith_mdl.oresm_id) AND (rc_this_oldid = ores_goodfaith_cls.oresc_rev) AND ores_goodfaith_cls.oresc_class = '1') WHERE (rc_bot = 0) AND (rc_type != '0') AND (rc_type != '3') AND (rc_type != '6') AND (rc_source != 'wb') AND (rc_namespace = '1') AND (rc_timestamp >= '20170609000000') AND ct_tag = 'visualeditor' AND rc_new IN ('0','1') ORDER BY rc_timestamp DESC LIMIT 50 Function: SpecialRecentChanges::doMainQuery Error: 2062 Read timeout is reached (10.64.32.25) {"exception_id":"WUPWEgpAIDgAAFdx4R8AAAAQ","caught_by":"mwe_handler"} [Exception Wikimedia\Rdbms\DBQueryError] (/srv/mediawiki/php-1.30.0-wmf.5/includes/libs/rdbms/database/Database.php:1145) A database query error has occurred. Did you forget to run your application's database schema updater after upgrading? Query: SELECT rc_id,rc_timestamp,rc_user,rc_user_text,rc_namespace,rc_title,rc_comment,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,wl_user,wl_notificationtimestamp,page_latest,(SELECT GROUP_CONCAT(ct_tag SEPARATOR ',') FROM `change_tag` 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` LEFT JOIN `watchlist` ON (wl_user = '26209855' AND (wl_title=rc_title) AND (wl_namespace=rc_namespace)) LEFT JOIN `page` ON ((rc_cur_id=page_id)) INNER JOIN `change_tag` ON ((ct_rc_id=rc_id)) LEFT JOIN `flaggedpages` ON ((fp_page_id = rc_cur_id)) LEFT JOIN `ores_model` `ores_damaging_mdl` ON (ores_damaging_mdl.oresm_is_current = '1' AND ores_damaging_mdl.oresm_name = 'damaging') LEFT JOIN `ores_classification` `ores_damaging_cls` ON ((ores_damaging_cls.oresc_model = ores_damaging_mdl.oresm_id) AND (rc_this_oldid = ores_damaging_cls.oresc_rev) AND ores_damaging_cls.oresc_class = '1') LEFT JOIN `ores_model` `ores_goodfaith_mdl` ON (ores_goodfaith_mdl.oresm_is_current = '1' AND ores_goodfaith_mdl.oresm_name = 'goodfaith') LEFT JOIN `ores_classification` `ores_goodfaith_cls` ON ((ores_goodfaith_cls.oresc_model = ores_goodfaith_mdl.oresm_id) AND (rc_this_oldid = ores_goodfaith_cls.oresc_rev) AND ores_goodfaith_cls.oresc_class = '1') WHERE (rc_bot = 0) AND (rc_type != '0') AND (rc_type != '3') AND (rc_type != '6') AND (rc_source != 'wb') AND (rc_namespace = '1') AND (rc_timestamp >= '20170609000000') AND ct_tag = 'visualeditor' AND rc_new IN ('0','1') ORDER BY rc_timestamp DESC LIMIT 50 Function: SpecialRecentChanges::doMainQuery Error: 2062 Read timeout is reached (10.64.32.25) #0 /srv/mediawiki/php-1.30.0-wmf.5/includes/libs/rdbms/database/Database.php(975): Wikimedia\Rdbms\Database->reportQueryError(string, integer, string, string, boolean) #1 /srv/mediawiki/php-1.30.0-wmf.5/includes/libs/rdbms/database/Database.php(1339): Wikimedia\Rdbms\Database->query(string, string) #2 /srv/mediawiki/php-1.30.0-wmf.5/includes/specials/SpecialRecentchanges.php(403): Wikimedia\Rdbms\Database->select(array, array, array, string, array, array) #3 /srv/mediawiki/php-1.30.0-wmf.5/includes/specialpage/ChangesListSpecialPage.php(584): SpecialRecentChanges->doMainQuery(array, array, array, array, array, FormOptions) #4 /srv/mediawiki/php-1.30.0-wmf.5/includes/specialpage/ChangesListSpecialPage.php(520): ChangesListSpecialPage->getRows() #5 /srv/mediawiki/php-1.30.0-wmf.5/includes/specials/SpecialRecentchanges.php(166): ChangesListSpecialPage->execute(NULL) #6 /srv/mediawiki/php-1.30.0-wmf.5/includes/specialpage/SpecialPage.php(522): SpecialRecentChanges->execute(NULL) #7 /srv/mediawiki/php-1.30.0-wmf.5/includes/specialpage/SpecialPageFactory.php(579): SpecialPage->run(NULL) #8 /srv/mediawiki/php-1.30.0-wmf.5/includes/MediaWiki.php(287): SpecialPageFactory::executePath(Title, RequestContext) #9 /srv/mediawiki/php-1.30.0-wmf.5/includes/MediaWiki.php(862): MediaWiki->performRequest() #10 /srv/mediawiki/php-1.30.0-wmf.5/includes/MediaWiki.php(523): MediaWiki->main() #11 /srv/mediawiki/php-1.30.0-wmf.5/index.php(43): MediaWiki->run() #12 /srv/mediawiki/w/index.php(3): include(string) #13 {main} ```
    • Task
    [x] RecentChanges [x] RecentChangesLinked [X] Watchlist [] Contributions [] NewPages [] NewFiles [] Special Logs [] …?
    • Task
    For {T163429}, we will need backend support for paginating through RecentChanges / ChangesList. There already is a `from` parameter which might be able to be used for this, but it's only used by the "Show new changes since" link, and that might not allow us to page backwards. We will also need reverse sorting for the "sort by oldest first" feature in {T162786}, and the ability to specify both "from" and "to" timestamps for the date selector in {T162784}.