October 2022 - Wikitech-l - lists.wikimedia.org

Database dumps
by Byrial Jensen 17 Apr '25

17 Apr '25

Until some weeks ago http://dumps.wikimedia.org/backup-index.html used to show 4 dumps in progress at the same time. That meant that new database dumps normally was available within about 3 weeks for all databases except for enwiki and maybe dewiki where the dump process due to size took longer time. However the 4 dumps processes at one time become 3 some weeks ago. And after massive failures at June 4, only one dump has been in progress at the same time. So at the current speed it will take several months to come thru all dumps. Is it possible to speed up the process again using several dump processes at the same time? Thank you, Byrial

3 2

User-Agent:
by Domas Mituzas 17 Apr '25

17 Apr '25

Hi! from now on specific per-bot/per-software/per-client User-Agent header is mandatory for contacting Wikimedia sites. Domas

19 61

Acquiring list of templates including external links
by Takashi OTA 17 Apr '25

17 Apr '25

Hoi, This is an inquiry from my friend in academia, researching about Wikipedia. He would like to know whether there's a way to acquire a list of templates including external links. Here are some examples including external links. https://ja.wikipedia.org/wiki/Template:JOI/doc https://ja.wikipedia.org/wiki/Template:Twitter/doc Such links are stored in externallinks.sql.gz, in an expanded form. When you want to check increase/decrease of linked domains in chronological order through edit history, you have to check pages-meta-history1.xml etc. In a such case, traditional links and links by templates are mixed, Therefore, the latter ones (links by templates) should be expanded to traditional link forms. Sorry if what I am saying does not make sense. Thanks in advance, --Takashi Ota [[U:Takot]]

13 24

EBNF grammar project status?
by Steve Bennett 01 Apr '25

01 Apr '25

What's the status of the project to create a grammar for Wikitext in EBNF? There are two pages: http://meta.wikimedia.org/wiki/Wikitext_Metasyntax http://www.mediawiki.org/wiki/Markup_spec Nothing seems to have happened since January this year. Also the comments on the latter page seem to indicate a lack of clear goal: is this just a fun project, is it to improve the existing parser, or is it to facilititate a new parser? It's obviously a lot of work, so it needs to be of clear benefit. Brion requested the grammar IIRC (and there's a comment to that effect at http://bugzilla.wikimedia.org/show_bug.cgi?id=7 ), so I'm wondering what became of it. Is there still a goal of replacing the parser? Or is there some alternative plan? Steve

26 217

Phabricator upstream shutdown
by Brian Wolff 21 Mar '25

21 Mar '25

It sounds like phabricator upstream is going away: https://admin.phacility.com/phame/post/view/11/phacility_is_winding_down_op… Just curious, are we planning to continue using it long term or move to something else? -- Brian

10 12

Missing Section Headings
by Marc Riddell 13 Sep '24

13 Sep '24

Hello, I have been a WP editor since 2006. I hope you can help me. For some reason I no longer have Section Heading titles showing in the Articles. This is true of all Headings including the one that carries the Article subject's name. When there is a Table of Contents, it appears fine and, when I click on a particular Section, it goes to that Section, but all that is there is a straight line separating the Sections. There is also no button to edit a Section. If I edit the page and remove the "== ==" markers from the Section Titles, the Title then shows up, but not as a Section Heading. Also, I don't have any Date separators on my Want List. This started 2 days ago. Any thoughts? Thanks, Marc Riddell [[User:Michael David]]

10 11

How to make commits from mirrored Wikimedia repos show up on your GitHub profile
by Bartosz Dziewoński 27 Jun '24

27 Jun '24

I know it has been annoying a couple of people other than me, so now that I've learned how to make it work I'll share the knowledge here. tl;dr: Star the repositories. No, seriously. (And yes, you need to star each extension repo separately.) (Is there a place on mw.org to put this tidbit on?) ------- Forwarded message ------- From: "Brian Levine" <support(a)github.com> (GitHub Staff) To: matma.rex(a)gmail.com Cc: Subject: Re: Commits in mirrored repositories not showing up on my profile Date: Tue, 09 Jul 2013 06:47:19 +0200 Hi Bartosz In order to link your commits to your GitHub account, you need to have some association with the repository other than authoring the commit. Usually, having push access gives you that connection. In this case, you don't have push permission, so we don't link you to the commit. The easy solution here is for you to star the repository. If you star it - along with the other repositories that are giving you this problem - we'll see that you're connected to the repository and you'll get contribution credit for those commits. Cheers Brian -- Matma Rex

3 3

Research FAQ gets a facelift
by Dario Taraborelli 25 Jun '24

25 Jun '24

We just released a new version of Research:FAQ on Meta [1], significantly expanded and updated, to make our processes at WMF more transparent and to meet an explicit FDC request to clarify the role and responsibilities of individual teams involved in research across the organization. The previous version – written from the perspective of the (now inactive) Research:Committee, and mostly obsolete since the release of WMF's open access policy [2] – can still be found here [3]. Comments and bold edits to the new version of the document are welcome. For any question or concern, you can drop me a line or ping my username on-wiki. Thanks, Dario [1] https://meta.wikimedia.org/wiki/Research:FAQ [2] https://wikimediafoundation.org/wiki/Open_access_policy [3] https://meta.wikimedia.org/w/index.php?title=Research:FAQ&oldid=15176953 *Dario Taraborelli *Head of Research, Wikimedia Foundation wikimediafoundation.org • nitens.org • @readermeter <http://twitter.com/readermeter>

2 1

bluejeans
by Jeremy Baron 22 Feb '23

22 Feb '23

Hi, On Tue, Mar 1, 2016 at 3:36 PM, David Strine <dstrine(a)wikimedia.org> wrote: > We will be holding this brownbag in 25 minutes. The Bluejeans link has > changed: > > https://bluejeans.com/396234560 I'm not familiar with bluejeans and maybe have missed a transition because I wasn't paying enough attention. is this some kind of experiment? have all meetings transitioned to this service? anyway, my immediate question at the moment is how do you join without sharing your microphone and camera? am I correct thinking that this is an entirely proprietary stack that's neither gratis nor libre and has no on-premise (not cloud) hosting option? are we paying for this? -Jeremy

9 16

Unsubscribe from mail list
by Arpit Maheshwari 11 Jan '23

11 Jan '23

This is a request to please kindly unsubscribe me from your mailing list

4 4

List related to repositories which haven't mediawiki/mediawiki-codesniffer
by Zoran Dori 10 Jan '23

10 Jan '23

Hello, can someone to update list https://phabricator.wikimedia.org/P10500 which contains repositories which haven't mediawiki/mediawiki-codesniffer. I found in list that much repositories are empty, and repositories which aren't available on Gerrit. So, can someone please update this list of repositories (in mediawiki/extensions) which haven't mediawiki/mediawiki-codesniffer, but at least, contains one PHP file. or to provide me command with which I can update list when I want, so I don't need to request it every time. Best regards, Zoran. P. S.: Happy weekend! :)

4 6

Repository ownership of the Lingo extension
by Zoran Dori 10 Jan '23

10 Jan '23

Hi everyone, I want to notify you that I have, on behalf of the WikiTeq company, made a task https://phabricator.wikimedia.org/T298277 for requesting repository ownership for the Lingo extension. In case that you have any kind of questions, please let me know. :) Best regards, Zoran

3 3

Feedback wanted: PHPCS in a static types world
by Lucas Werkmeister 08 Dec '22

08 Dec '22

Hi all! In my opinion, MediaWiki’s PHPCS ruleset feels largely rooted in an older version of PHP, where static type declarations (formerly known as “type hints”) did not exist. As we move towards more modern code, I think some rules should be relaxed, and others adjusted. More specifically, I’d like to know if most people agree with the following propositions and conclusion: Proposition 1: *Some code is sufficiently documented by names and types*, and does not require additional documentation. Cases where additional documentation is required do certainly exist, but they can only be identified by human reviewers, not by automated tools. You can see this in our existing code wherever a doc comment specifies only a type (with @var, @param, or @return), but no additional text. For example, in CreditsAction <https://gerrit.wikimedia.org/g/mediawiki/core/+/de752f45af/includes/actions…>, nobody needs to be told that the LinkRenderer will be used to render links, or that the UserFactory creates User objects: class CreditsAction extends FormlessAction { /** @var LinkRenderer */ private $linkRenderer; /** @var UserFactory */ private $userFactory; Likewise, it’s not necessary to explain in great detail that the string returned by LinksTable::getTableName() <https://gerrit.wikimedia.org/g/mediawiki/core/+/de752f45af/includes/deferre…> is the table name, that the $actor parameter of ActorCache::remove( UserIdentity $actor ) <https://gerrit.wikimedia.org/g/mediawiki/core/+/de752f45af/includes/user/Ac…> represents the actor to remove from the cache, or what the meaning of the Message $m and returned MessageValue are in Message\Converter::convertMessage() <https://gerrit.wikimedia.org/g/mediawiki/core/+/de752f45af/includes/Message…> : /** * Convert a Message to a MessageValue * @param Message $m * @return MessageValue */ public function convertMessage( Message $m ) { (I want to clarify that in this last example I’m only talking about the @param and @return tags that already don’t have any prose text. While the method comment “Convert a Message to a MessageValue” might also be considered redundant, I think this would be more contentious, and I’m not advocating for removing that today.) Proposition 2: *Adding types as static types is generally preferable.* Unlike doc comments, static types are checked at runtime and thus guaranteed to be correct (as long as the code runs at all); the small runtime cost should be partially offset by performance improvements in newer PHP versions, and otherwise considered to be worth it. New code should generally include static types where possible, and existing code may have static types added as part of other work on it. I believe this describes our current development practice as MediaWiki developers. Note that some older MediaWiki classes are considered unsuitable for static types, and should only be used in comments; this is expected to help in a future migration away from these classes (see T240307#6191788 <https://phabricator.wikimedia.org/T240307#6191788>). Proposition 3: *Where types can be losslessly represented as PHP static types, types in doc comments are unnecessary.* When doc comments are considered necessary for actual documentation beyond types, then the type is generally still included (and Phan will check that it matches the static type), but when no further documentation is needed (see proposition 1 above), then the @var, @param, etc. doc comment can be omitted. Note that depending on the PHP version, not all types can be losslessly represented as PHP static types yet (e.g. union types and mixed both need to wait for PHP 8.0, null and false for PHP 8.2); in such cases, doc comments can remain necessary. Conclusion: *We should update our PHPCS ruleset to require fewer doc comments.* Exact rules are probably to be decided, depending on how much work we’re willing to put into the sniff implementations (e.g. is it feasible to require /** @param */ doc comments only if a parameter has no static type?), but generally, I argue that we want code such as the following to be allowed by our standard PHPCS ruleset: class CreditsAction extends FormlessAction { private LinkRenderer $linkRenderer; private UserFactory $userFactory; /** Convert a Message to a MessageValue */ public function convertMessage( Message $m ): MessageValue { When doc comments are still necessary or at least beneficial because the type alone isn’t enough information, it’s up to humans to decide this while writing the code or point it out during code review. What do people think about this? :) PS: In PHP 8, we could abbreviate some of this code even more using constructor property promotion: class CreditsAction extends FormlessAction { public function __construct( Page $page, IContextSource $context, private LinkRenderer $linkRenderer, private UserFactory $userFactory ) { parent::__construct( $page, $context ); } (Again, I’m not saying that all code should look like this – but I think we have plenty of existing code that effectively carries no additional information in its documentation, and which could be converted into this form without losing anything.) Cheers, Lucas -- Lucas Werkmeister (he/er) Software Engineer Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin Phone: +49 (0)30-577 11 62-0 https://wikimedia.de Imagine a world in which every single human being can freely share in the sum of all knowledge. Help us to achieve our vision! https://spenden.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207.

10 13

My idea about wikipage parser (shared link on the article)
by Dušan Kreheľ 03 Dec '22

03 Dec '22

Hi, i wanna share my idea (writed in the article) about the wikipage parser: https://en.wikipedia.org/wiki/User:Du%C5%A1an_Krehe%C4%BE/Signpost_draft:My… The primary technical content would be done. Dušan Kreheľ

3 7

Reducing size of pageviews dump (shared link on the article)
by Dušan Kreheľ 23 Nov '22

23 Nov '22

Hi, i wanna share my idea (writed in the article) about the reducing size of pageviews dump: https://en.wikipedia.org/wiki/User:Du%C5%A1an_Krehe%C4%BE/Signpost_draft:Ne… The primary technical content would be done. Dušan Kreheľ

4 12

Outreachy Round 25–projects finalized & contribution period begins!
by Srishti Sethi 22 Nov '22

22 Nov '22

Hello all, Here is a quick update on Outreachy Round 25: we recently concluded the final call for projects and mentors and are now promoting 6 projects led by 14 mentors. If you know someone who cleared the Outreachy's initial eligibility check, encourage them to explore the Wikimedia projects below: - Create a web application for editing Toolhub records, mentored by: Slavina Stefanova, Damilare Adedoyin, Roy Smith - Develop features for Wiki Loves Monuments app, mentored by: Ederporto, Mike Peel - Rewrite Imagebulk tool to scale up, mentored by: Jay Prakash, Sudhanshu Gautam - Write a Ruby gem for analyzing Wikidata edits, mentored by: Sage Ross, Will Kent - Develop a web app for patrolling based on the new ML-based service to predict reverts, mentored by: Diego Saez-Trumper, Muniza A. - Hybrid event production for QueeringWikipedia 2023, mentored by: Z. Blace, Owen Blacker, Freddy eduardo If you are interested in any of these projects, you can either subscribe to the related Phabricator tickets or share your ideas and suggestions in a comment. Learn more here: <https://www.mediawiki.org/wiki/Outreachy/Round_25> [1] Cheers, Srishti [1] https://www.mediawiki.org/wiki/Outreachy/Round_25 *Srishti Sethi* Senior Developer Advocate Wikimedia Foundation <https://wikimediafoundation.org/>

1 1

New Codesearch interface in beta testing
by Kunal Mehta 08 Nov '22

08 Nov '22

Hi, Over two years ago[1] I worked on redesigning the Codesearch UI to make it easier to browse and filter. It didn't go anywhere for various reasons[2], but in June Krinkle picked it up again and I've now deployed his rewrite[3], please try it out: https://codesearch-beta.wmcloud.org/ You can insert "-beta" into the URL of any normal codesearch result and it should just work. Here's an overview of the changes: * Switching backends keeps the search query * Sidebar for easy skipping of many results from one repo * Implement fuzzysort and typeahead autocompletion for the repo selector dropdown * Generate a report in the format of a Phabricator checklist * Add search query to the document title (browser tab) * Implement a pulsating "placeholder" state * Optimise fetching of "repos" config data by caching this server-side * Fix advanced options being hidden by adblockers And there's more, you can read Krinkle's commit message[3] for the full list and links to tasks. Please report bugs you find in the Codesearch Phabricator project[4] (or submit a patch!). If all goes well I'd like to switch over the main domain to the new interface near the end of the year. [1] https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/… [2] lack of time and basing on top of experimental technology [3] https://gerrit.wikimedia.org/r/c/labs/codesearch/+/804785/ [4] https://phabricator.wikimedia.org/project/view/3158/ Thanks, -- Kunal / Legoktm

6 5

[Small wiki toolkits] Final feedback session on Friday, October 28th, at 16:00 UTC
by Srishti Sethi 07 Nov '22

07 Nov '22

Hello everyone, The last & final feedback session on the "Small wiki toolkits" (SWT) workshop series is coming up - it will take place on Friday, October 28th, at 16:00 UTC. You can find more details on the workshop and a link to join here: < https://meta.wikimedia.org/wiki/Small_wiki_toolkits/Workshops#Upcoming:_Fin…> [1]. This workshop will gather feedback on the SWT workshop series around bots and scripts development, ongoing since January 2022. There will be a discussion around the following: - Overall feedback on the workshop series - Technical topics you would like to see the SWT team focus on by running workshops or developing resources in 2023 - Your preferred learning formats This session does not require attendance in previous workshops to participate. We look forward to your participation! Best, Srishti On behalf of the SWT Workshops Organization team [1] https://meta.wikimedia.org/wiki/Small_wiki_toolkits/Workshops#Upcoming:_Fin… *Srishti Sethi* Senior Developer Advocate Wikimedia Foundation <https://wikimediafoundation.org/>

2 3

🚂🌈Summary of 1.40.0-wmf.7 train deployment
by Tyler Cipriani 31 Oct '22

31 Oct '22

This email is a summary of the Wikimedia production deployment of 1.40.0-wmf.7 Conductor: Jaime Nuche Backup Conductor: Antoine Musso Blocker Task: T320512 <https://phabricator.wikimedia.org/T320512> Current Status: Live everywhere <https://versions.toolforge.org/> _____ *📊 Stats* Sparklines comparing the last 5 trains. 213 Patches ▁▆█▃▁ 0 Rollbacks ██▁█▁ 0 Days of delay █▁▁▁▁ 0 Blockers ▂█▂█▁ Moar stats in the train-stats repo <https://gitlab.wikimedia.org/repos/releng/train-stats> _____ *🎉 Traintastic Folks ✨* It was a quiet week. And—wow—a release with no blockers, no delays, and no rollbacks! So thanks to the folks who backported some needed changes over the past week: - *Tim Starling* for handling multi-byte unicode capitalization changes between php7.2 and php7.4: https://phabricator.wikimedia.org/T292552 - *Amir Sarabadani *for finishing work to make running maintenance scripts that interact with the database better and safer: https://phabricator.wikimedia.org/T298485 Until next train! Tyler Cipriani (he/him) Engineering Manager, Release Engineering Wikimedia Foundation

1 0

[BREAKING CHANGE] New optional optional RevisionRecord param added to ContentHandler::getDataForSearchIndex()
by David Causse 31 Oct '22

31 Oct '22

Hi, The method ContentHandler::getDataForSearchIndex() is used by (non-core) MW SearchEngine implementations and was added in MW 1.28 to gather the data to be indexed. In 1.40 this signature will change to let SearchEngine implementations pass an optional RevisionRecord param <https://gerrit.wikimedia.org/r/c/mediawiki/core/+/832957/10/includes/conten…> to clarify what revision is being indexed (instead of assuming that the "latest" was requested). This is a breaking change if you maintain a ContentHandler subclass and have overridden the getDataForSearchIndex() method, you will have to change your method signature from: public function getDataForSearchIndex( WikiPage $page, ParserOutput $output, SearchEngine $engine ) to public function getDataForSearchIndex( WikiPage $page, ParserOutput $output, SearchEngine $engine, RevisionRecord $revision = null ) If you own a SearchEngine implementation and rely on ContentHandler::getDataForSearchIndex() this is not a breaking change but it is advised to pass this new RevisionRecord parameter when calling it. Relatedly the hook SearchDataForIndex <https://www.mediawiki.org/wiki/Manual:Hooks/SearchDataForIndex> will be deprecated (silently) and SearchDataForIndex2 <https://www.mediawiki.org/wiki/Manual:Hooks/SearchDataForIndex2> should be used instead. Please let me know if you have questions/strong objections to this approach. -- David Causse

1 0

Concern person stopping others wiki
by M.SaravanaKumar Malaiyaman 29 Oct '22

29 Oct '22

Hi, This concern person ( https://ta.m.wikipedia.org/wiki/பயனர்:Kanags ) deleting others' wiki. Please take necessary action. Thanks Kind regards Saravanakumar.CM

2 1

[BREAKING CHANGE] Remove AlphabeticPager::getOrderTypeMessages()
by Krinkle 28 Oct '22

28 Oct '22

This was introduced in March 2008 with r32228 <https://www.mediawiki.org/wiki/Special:Code/MediaWiki/32228> (ad178edb80) for use in the CategoryPager of Special:Categories, but almost immediately removed again from there, on the same day, in r32259 <https://www.mediawiki.org/wiki/Special:Code/MediaWiki/32259> (bdf9431795) because it wasn't actually supported. There has been no other use of it to my knowledge, and has remained undocumented and without tests. I'm proposing removal without deprecation (per Stable interface policy#Removal <https://www.mediawiki.org/wiki/Stable_interface_policy#Removal>). Note that if you did use it outside publicly hosted/indexed repos, you don't risk visible breakage and require no migration. Unused method overrides in subclasses are silently ignored. https://gerrit.wikimedia.org/r/c/mediawiki/core/+/850612/ <https://gerrit.wikimedia.org/r/c/mediawiki/core/+/850612/1> -- Timo

1 0

Thank you
by Jacoba Jacqueline Hartnick 28 Oct '22

28 Oct '22

Hi there, I know this must be frustrating for you guys, but keep in mind I've just figured out all this a few weeks ago so please have patience with me. JHartnick

1 0

MediaWiki Language Extension Bundle 2022.10
by Kartik Mistry 28 Oct '22

28 Oct '22

We would like to announce the release of MediaWiki Language Extension Bundle 2022.10. This bundle is compatible with '''MediaWiki >= 1.37.2''' and requires '''PHP 7.3.19''' or above. The next MLEB is expected to be released in 3 months. If there are very important bug fixes, we will do an intermediate release. Please give us your feedback at [[Talk:MLEB|https://www.mediawiki.org/wiki/Talk:MLEB]]. * Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2022.10.tar… * sha256sum: c1cc1667de38a2b27fd0e43024f1c94bee5d58952fda8eabb43346d5ce4b7199 * Signature: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2022.10.tar… Quick links: * Installation instructions are at: https://www.mediawiki.org/wiki/MLEB * Announcements of new releases will be posted to a mailing list: https://lists.wikimedia.org/postorius/lists/mediawiki-i18n.lists.wikimedia.… * Report bugs to: https://phabricator.wikimedia.org/project/view/1464/ A detailed release note for this release can be found at: https://www.mediawiki.org/wiki/MediaWiki_Language_Extension_Bundle/2022.10 -- Kartik Mistry | કાર્તિક મિસ્ત્રી kartikm.wordpress.com

1 0

Filtered lists with checkboxes
by Bináris 26 Oct '22

26 Oct '22

Hi, I work with large categories. My dream is to upload a list of articles to a wikipage, where there are checkboxes next to the titles, and I can click. The page would return a filtered lists which I can use with my bot to change the category. On an advanced level, several columns of checkboxes could exist do divide the category to subcats. Checkbox is not the aim, it is only a way I can explain what I want to do. Of course, I can do it in Excel, but 1. on a wikipage I can move my mouse on the title and see the part of the content, and in Excel I cannot, 2. I can offer a wikipage to another user to make the filtering, an then do the work with bot. As far as I see, the most natural way is to code this in PHP, which needs a MediaWiki extension, if anyone feels like, and likes my idea... By that time, do you know about such service on the tolserver? Or can I do it myself somehow with Lua? -- Bináris

3 7

Standardizing exception handling in MediaWiki
by Daimona 26 Oct '22

26 Oct '22

Hi everyone, Today I created a task proposing that exception handling and annotations be standardized in MediaWiki: https://phabricator.wikimedia.org/T321683. This would affect all MediaWiki code written in PHP (core, extensions, and skins), and the standardization itself will require a lot of effort. Therefore, I invite you to share any questions, thoughts, or concerns that you may have on the task. Thank you, -- https://meta.wikimedia.org/wiki/User:Daimona_Eaytoy "Daimona" is not my real name -- he/him

1 0

maybe somebody can just review and approve this commit of script conversion?
by dinar qurbanov 24 Oct '22

24 Oct '22

hello can somebody help with reviewing technical aspects of a cyrillic <-> latin converter ? it has been said that the file is too big and the commit is too big. the code is nearly 3500 lines. i think it is not worth to divide it into separate library or files. as library it would be very fit for this conversion, not usable for other things. i feel making library as "premature optimisation". and laziness, feeling as useless work. also just dividing into files, into classes. 3500 lines is not very hard for me to browse. if anybody wants to separate it into classes and files, feel free to edit, if you think it is good for mediawiki. i do not want to make such change by myself. i can help with proper names (for classes, variables). i said variables because it is possible to convert some lists of php commands into for cycles with arrays, just to make it look shorter. i think it is also like premature optimisation, i have more freedom when they are as they are, in further editing. i do not want to make such change by myself. feel free to edit. quick link to the newest version of the code: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/164049/219/includes/langu… . also it was suggested to get rid of regex lookahead and lookbehind. and strtr was like suggested. i think i probably cannot easily make those changes. and i think, is strtr really faster than preg_replace? i googled for benchmark results and i do not see, in the first page, like 10 results. the code is big, but it just modifies a string. tatar wikipedians have asked me about this code, yesterday, and now i try this approach, to write to this mailing list, before other ways to go. maybe there is just a lack of some people who can review this code and approve it, and maybe this mailing list can help. other ways to go to the problem's pages: https://phabricator.wikimedia.org/T27537 , https://gerrit.wikimedia.org/r/c/mediawiki/core/+/164049 .

2 1

Infrastructure diagrams
by Krinkle 24 Oct '22

24 Oct '22

I've done a major update to a number of diagrams on Wikitech. Usually, I don't mention an update here, but I'm highlighting it now as it's been a while since we mentioned them on-list and the community and foundation have grown a lot so some of these may be new to you. Given how much has changed in recent changes, I also included a changelog and a link to where in the docs you'd normally discover this diagram on-wiki: *== 1. File:Wikipedia_webrequest_2022.png <https://wikitech.wikimedia.org/wiki/File:Wikipedia_webrequest_2022.png> (Updated) ==* This is a highly simplified diagram, covering the general shape of our stack through the example of a typical Wikipedia webrequest. ** Previous: https://upload.wikimedia.org/wikipedia/commons/b/b3/Wikipedia_webrequest_fl… New: https://upload.wikimedia.org/wikipedia/commons/4/4d/Wikipedia_webrequest_20… Documentation: wikitech:MediaWiki_at_WMF <https://wikitech.wikimedia.org/wiki/MediaWiki_at_WMF> and wikitech:Caching_overview <https://wikitech.wikimedia.org/wiki/Caching_overview>. Notable changes: * Change edge TLS termination ("HTTPS") from ats-tls to HAProxy. I wrote a "Caching overview § History <https://wikitech.wikimedia.org/wiki/Caching_overview>" section. * Change appserver TLS from Nginx- to Envoy. * Add new MainStash DB. * Include storage ExternalStore DB, ParserCache DB, and Swift media. * Include services Shellbox, Mathoid, and Kask. *== 2. File:WMF_infrastructure_2022.png <https://wikitech.wikimedia.org/wiki/File:WMF_infrastructure_2022.png> *(Updated) ==** This is a continous attempt at an overview of tier-1/user-facing infrastructure. It will likely never be complete from all POV, but.. it is more accurate and complete than it has been. Thanks to all that contributed by entertaining my many questions over the years. **** Previous (2016 by Elukey): https://upload.wikimedia.org/wikipedia/labs/4/4d/Infrastructure_overview.png New: https://upload.wikimedia.org/wikipedia/commons/4/48/WMF_infrastructure_2022… Documentation: wikitech:Wikimedia_infrastructure <https://wikitech.wikimedia.org/wiki/Wikimedia_infrastructure> and wikitech:Purged <https://wikitech.wikimedia.org/wiki/Purged> Notable changes: * Add new Drmrs data center in Marseille, France. * Add new services: purged.go, EventStreams, Thumbor, mcrouter, Envoy, etcd. * Add new distinction for Multi-DC between primary and secondary data center. * Change sessionstore from Redis to Kask/Cassandra. * Change jobqueue from Redis to EventGate/Kafka. * Include distinct MediaWiki server roles and clusters. * Include high-level MediaWiki platform components. * Include example flow for "JobQueue job" and "CDN purge". *== 3. File:MediaWiki_infrastructure_2022.png <https://wikitech.wikimedia.org/wiki/File:MediaWiki_infrastructure_2022.png> (New) ==* Similar to WMF Infra diagram, but more abstract around DC and services, and more detailed within the platform. Including more core services, and recognising extensions as their own layer. ** New: https://upload.wikimedia.org/wikipedia/commons/e/ee/MediaWiki_infrastructur… Documentation: wikitech:MediaWiki_at_WMF <https://wikitech.wikimedia.org/wiki/MediaWiki_at_WMF> *== 4. File:Wikipedia_Memcached_flow_2022.png <https://wikitech.wikimedia.org/wiki/File:Wikipedia_Memcached_flow_2022.png> *(Updated)** **** Previous: https://upload.wikimedia.org/wikipedia/commons/d/db/Wikipedia_Memcached_flo… New: https://upload.wikimedia.org/wikipedia/commons/4/45/Wikipedia_Memcached_flo… Documentation: wikitech:Memcached_for_MediaWiki <https://wikitech.wikimedia.org/wiki/Memcached_for_MediaWiki> Notable changes: * Include the three tiers of ParserCache. * Add WANCache legend to explain different keytypes you may encounter on the network. * Add full name of the mcrouter-with-onhost-tier service for greppability. * Add new WRStats service (T310662 <https://phabricator.wikimedia.org/T310662>). This was part of Multi-DC work <https://www.mediawiki.org/wiki/Wikimedia_Performance_Team/Multi-DC_MediaWiki> to reduce primary DB writes and (not bi-di replicated) Redis use in AbuseFilter. This service also replaces the old "User ping limiter" in core and is now able to serve both use cases. * Remove "on-host: soon" labels. Adopting on-host memc for WANCache was considered not worth the added runtime complexity (T264604 <https://phabricator.wikimedia.org/T264604>). Note that SRE's work on adding 10G network links for memcached hosts, and the addition of mcrouter-managed gutter pools take care of the general usecase that we were exploring on-host for. We kept it for ParserCache however (T244340 <https://phabricator.wikimedia.org/T244340>. *== Edit link ==* As before, each diagram file page has an "Edit" link in the description that takes you directly to the open-source Diagrams.net web app (loading file read-only from Google Drive). You can fork by using "Save as" in the web app. See also: wikitech:Performance/Runbook/diagrams.net_conventions <https://wikitech.wikimedia.org/wiki/Performance/Runbook/diagrams.net_conven…> -- Timo

5 4

[Train] 1.40.0-wmf.6 status update
by Antoine Musso 18 Oct '22

18 Oct '22

Hello, The 1.40.0-wmf.6 version of MediaWiki is blocked (T320511 <https://phabricator.wikimedia.org/T320511>). Upon deployment to group0 wikis I found out CheckUser to be broken: Unknown column 'cuc_private' in 'field list' I have filed it as T321041 <https://phabricator.wikimedia.org/T321041>. I am guessing CheckUser should be taught to not insert the cuc_private field unless needed and long term the schema change should be applied to all databases. I have thus blocked the train entirely until the issue get resolved. Antoine "hashar" Musso Wikimedia Release Engineering

1 1

🚂🌈Summary of 1.40.0-wmf.5 train deployment
by Dan Duvall 17 Oct '22

17 Oct '22

This email is a summary of the Wikimedia production deployment of 1.40.0-wmf.5 - Conductor: Dan Duvall - Backup Conductor: Chad Horohoe (graciously deployed to group0; thanks!) - Blocker Task: T314194 <https://phabricator.wikimedia.org/T314194> - Current Status <https://versions.toolforge.org/> 🔢 Stats Sparklines comparing the last 5 trains. - 337 Patches ▄▁▂▇█ - 0 Rollbacks █▁▄▄▁ - 0 Days of delay █▁█▁▁ - 1 Blockers ▄▃▁█▁ 😻 Trainbow Love ✨Thanks to folks who reported or resolved blockers: - Taavi Väänänen - Kosta Harlan -- Dan Duvall Staff Software Engineer, Release Engineering Wikimedia Foundation <http://wikimediafoundation.org>

1 0

Re: TDF is looking for community representatives
by Brian Wolff 15 Oct '22

15 Oct '22

So I see that User:Grunny, User:Rtnf and Dessalegn Yehuala were appointed. Respectfully, given the criteria was someone with +2 rights, I would question the decision to appoint Dessalegn Yehuala, who not only has never contributed to MediaWiki, but also appears to have never edited any Wikimedia project, or even have an account. Brian On Thu, Oct 6, 2022 at 1:58 AM Technical Decision Forum Support < TDFsupport(a)wikimedia.org> wrote: > Hi Brian, > > We have our representatives but we are always looking for some more as we > rotate throughout the year. My apologies for the late updates to the > forum. The lists are here > <https://www.mediawiki.org/wiki/Technical_decision_making/Forum>. The > community representatives have completed one feedback to the IP Masking > Proposal and next week we should have "Modern user interfaces for all > users" proposal out to the representatives for their feedback. You can see > it on the TDF <https://phabricator.wikimedia.org/project/board/5179/> > board. > > Thank you, > TDF > > > On Wed, Oct 5, 2022, 5:46 PM Brian Wolff <bawolff(a)gmail.com> wrote: > >> Out of curiosity, what happened? Aug 12 has come and gone. More to the >> point, i was wondering if TDF is even still a thing? >> >> -- >> Brian >> >> On Tuesday, August 2, 2022, Erica Litrenta <elitrenta(a)wikimedia.org> >> wrote: >> >>> Hi everyone. >>> >>> This is a reminder that the search for community representatives for the >>> Technical Decision Forum is still OPEN. >>> >>> There are a few weeks left to apply and/or recommend someone who would >>> be a great fit for the role (learn more at >>> https://www.mediawiki.org/wiki/Technical_decision_making/Community_represen… >>> ). >>> >>> Please let us know if there are any questions we can answer before you >>> submit your application, or a friend's name! Email us at >>> TDFSupport(a)wikimedia.org by Aug 12, 2022. >>> >>> Looking forward to hearing from you soon… >>> >>> The Technical Decision Forum. >>> >>> On Tue, Jul 12, 2022 at 11:17 AM Erica Litrenta <elitrenta(a)wikimedia.org> >>> wrote: >>> >>>> *(This email may not be written in your native language, and/or may be >>>> a crosspost: our apologies.)* >>>> >>>> >>>> Greetings, everyone. >>>> >>>> The Technical Decision Forum, or TDF (1), is seeking community >>>> representatives. Please visit the TDF Community Representation (2) >>>> page for more information, and email TDFSupport(a)wikimedia.org by Aug >>>> 12, 2022 to be considered for selection. >>>> >>>> >>>> Don't worry about the requirements listed on wiki, they are not set in >>>> stone; just provide your name, name of the group you "represent" if any, >>>> and a short sentence or two explaining your interest. >>>> >>>> >>>> For any questions, please post at *MediaWiki.org (3)*, or on the >>>> related Movement Strategy Forum topic (4), or simply email >>>> TDFSupport(a)wikimedia.org. >>>> >>>> Thanks, >>>> >>>> The Technical Decision Forum. >>>> >>>> (1) https://www.mediawiki.org/wiki/Technical_decision_making/Forum >>>> (2) >>>> https://www.mediawiki.org/wiki/Technical_decision_making/Community_represen… >>>> (3) https://www.mediawiki.org/wiki/Talk:Technical_decision_making/Forum >>>> (4) >>>> https://forum.movement-strategy.org/t/technical-decision-forum-tdf-is-looki… >>>> >>>> -- >>>> >>>> ------------------------------ >>>> >>>> >>>> Erica Litrenta (she/her) >>>> >>>> Senior Manager, Community Relations Specialists (Product) >>>> >>>> Wikimedia Foundation >>>> <https://meta.wikimedia.org/wiki/User:Elitre_(WMF)> >>>> >>>> >>> >>> -- >>> >>> ------------------------------ >>> >>> >>> Erica Litrenta (she/her) >>> >>> Senior Manager, Community Relations Specialists (Product) >>> >>> Wikimedia Foundation <https://meta.wikimedia.org/wiki/User:Elitre_(WMF)> >>> >>> >>>

12 16

Re: Request to post on mailing list.
by Asif Rahaman 14 Oct '22

14 Oct '22

Hi. I recently contacted Wikimedia and subscribe for the mailing list. I would like to post on your mailing list. Regards Asif Rahaman Btech second year student (IIT Bhilai) On Fri, Oct 14, 2022, 20:27 Asif Rahaman <asifrahaman162(a)gmail.com> wrote: > Hi. > I recently contacted Wikimedia and subscribe for the mailing list. I would > like to post on your mailing list. > > Regards > Asif Rahaman > Btech second year student (IIT Bhilai) >

3 2

ParserTests updates
by Subramanya Sastry 13 Oct '22

13 Oct '22

Hello everyone, The Content Transform Team <https://www.mediawiki.org/wiki/Content_Transform_Team> finally decided to act on this old task <https://phabricator.wikimedia.org/T111604> to split up the parserTests.txt file in core into a number of smaller files by functionality. We got a first patch merged and there is one more patch in gerrit that will likely merge this week. More patches will follow in the coming weeks and we expect that by the time we are done, we'll have a few 10s of parser test files which will all be significantly smaller than the parserTests.txt file now. So, when some of you write code that needs an update to parser tests,in some cases, you may have to update tests in multiple files. While I have your attention here, a few more parserTests related updates: * Over the last 6 months, we've updated MediaWiki core's parser test runner to run parser tests against Parsoid (both via CLI and in CI via PHPUnit). We call these tests integrated mode Parsoid test runs to contrast it with standalone mode Parsoid test runs (Core's test runner runs in integrated mode with the MediaWiki core code whereas Parsoid's test runner runs in standalone mode without using MediaWiki core code). * I've also been updating the parser tests wiki page <https://www.mediawiki.org/wiki/Parser_tests> to bring the documentation up to date wrt how to write tests for running with Parsoid. We will continue to improve this page and add more details as necessary. Feel free to edit the page or leave questions / comments on the talk page with requests for clarification. * We have also started enabling test runs with Parsoid in extension repositories as well as in core. If you see a 'parsoid-compatible' clause in a test file, that test file is going to be run with Parsoid. We want to make sure as we move further along with the integration of Parsoid with the rendering pipeline, we catch any newly-introduced regressions so they can be fixed. Thanks! Subbu on behalf of the Content Transform Team.

1 0

Request for feedback: Two changes related to databases in MediaWiki
by Amir Sarabadani 12 Oct '22

12 Oct '22

Hello, Two changes is being made on MediaWiki databases: *First:* We are reworking how extensions manage their database schema. The idea is to basically deprecate LoadExtensionSchemaUpdates hook[1] and replace it with structured values in extension.json. This is needed to avoid arbitrary php code execution during database update which can cause problems and was a contributing factor in one of our major outages [2]. The other reason for this change is to be able to wire abstract schema of extensions to core so it can be tested in CI (for example for having a valid json, having prefixes set correctly, etc.) You can see a POC of that in [3] Given that once the change is merged to core, breaking changs to extension registry schema would require a lot of work (updating the maniphest version and so on), it's better to get it right before merge. I have proposed something like [4]. For any feedback on this, please go to https://phabricator.wikimedia.org/T237839, *Second:* We are working to provide a replacement for raw SQL for query conditions. When the query condition is exact equality condition (e.g. rev_id = 123), you don't need to provide raw SQL but for most other cases you need to either provide it or build it via IDatabase methods. For example: 'rev_timestamp > ' . $db->addQuotes( $db->timestamp( $since ) ). You can see an example of this in [5] (being changed to something much better via a newly introduced method). This is not optimal and not very developer friendly, to solve that, we are proposing to have something like ExpressionBuilder::greater( 'rev_timestamp', $db->timestamp( $since ) ) supported in SelectQueryBuilder::where(). You can see the POC in [6]. For any feedback on this please go to https://phabricator.wikimedia.org/T210206 [1] https://www.mediawiki.org/wiki/Manual:Hooks/LoadExtensionSchemaUpdates [2] https://wikitech.wikimedia.org/wiki/Incidents/2020-04-07_Wikidata%27s_wb_it… [3] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/816262/10/tests/phpunit/s… [4] https://phabricator.wikimedia.org/T237839#8268173 [5] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/832625/6/includes/api/Api… [6] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/841940/ Thank you -- *Amir Sarabadani (he/him)* Staff Database Architect Wikimedia Foundation <https://wikimediafoundation.org/>

1 0

🌱 Fresh 22.09 released!
by Krinkle 11 Oct '22

11 Oct '22

This release promotes Node.js 16 to be the default runtime in fresh-node. Get started by installing, updating, or learning more, at: https://gerrit.wikimedia.org/g/fresh#fresh-environment Changelog: https://gerrit.wikimedia.org/g/fresh/+/22.09.1/CHANGELOG.md Node.js 16 is now the default environment for the fresh-node command. This addresses an issue with Vue.js development using Vite 3, which did not work well under Node.js 14. (Thanks Lucas Werkmeister, T314051 <https://phabricator.wikimedia.org/T314051>). Note that most projects still test on Node.js 14 in WMF CI. [1] If you find that some of your tests don't yet pass under Node.js 16, fret not! Node.js 14 and 12 remain available via the bundled fresh-node14 and fresh-node12 commands. If you encounter problems in Fresh with Node.js 16 or experience other issues, let us know on Phabricator at https://phabricator.wikimedia.org/tag/fresh/. This is also where you can browse previous tasks. Fresh is a fast way to create isolated environments from your terminal. These can be used to work more responsibly with 'npm' developer tools such as ESLint, QUnit, Grunt, Selenium, and more. Example guide: https://www.mediawiki.org/wiki/Manual:JavaScript_unit_testing -- Timo Tijhof [1] https://phabricator.wikimedia.org/T314470

1 0

Cookie-based CSS toggles for logged-out readers?
by Samuel Klein 10 Oct '22

10 Oct '22

Dear WT, The perennial discussion about ways to provide logged-out users with persistent customization of their reading experience in the browser has cropped up again in the context of the pending deployment of Vector 2022. Can a cookie-based width toggle <https://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Deployment_of_…> be offered without splitting the cache or otherwise making the toggler regret their tog? The answers currently range from "*shouldn't be very complicated or hacky, just toggling a class*..." and "*can be delivered to logged-out users on top of the cached parser output*.." to "*impossible*". Could someone clarify the challenges and costs of trying to toggle css classes in this way? Warmly, SJ -- Samuel Klein @metasj w:user:sj +1 617 529 4266

2 3

Subject: [REMINDER] Coolest Tool Award 2022: Call for nominations!
by Seyram Komla Sapaty 10 Oct '22

10 Oct '22

Hello! Last reminder, there are 2 days left (today and tomorrow) to submit your Coolest Tool Award <https://meta.wikimedia.org/wiki/Coolest_Tool_Award> nominations. Please recommend your favorite tools! Thanks! Komla, for the Coolest Tool Academy 2022 -- Seyram Komla Sapaty Developer Advocate Wikimedia Cloud Services

1 0

MediaWiki 1.39.0-rc.1 is ready for testing
by Sam Reed 07 Oct '22

07 Oct '22

I'm pleased to announce the immediate availability of MediaWiki 1.39.0-rc.1, the second release candidate for 1.39.0, the next LTS after MediaWiki 1.35. Download links are at the end of the e-mail. The tag has been signed and pushed to Git. This is not a final release, and should not be used for production websites. Known issues are tracked in Phabricator on the release workboard [1]. As with every release of MediaWiki, a large number of changes have landed in the last six months (over 1850 commits since 1.38.0 was cut), and you should read over the preliminary release notes as part of assuring yourself of areas that may have issues with your configuration, your skins, and/or your extensions. As always, please try out the release candidate in a test environment and do report any issues that you discover. Please use the #MW-1.39-Release [2] tag in Phabricator when reporting issues specific to this release, to make sure that we find them as quickly as possible. It is expected that MediaWiki 1.39 will become final in November 2022, though the date may slip if blockers are identified. Changes since MediaWiki 1.39.0-rc.0: * Localisation updates. * (T318481) composer: Drop symfony/php73-polyfill. * (T318460) SpecialChangeEmail: Set default for returntoquery. * (T318307) HTMLFormField::validate(): Update docs to permit all data types * (T306802) docker: update to latest published images. * (T318754) WebInstallerOptions::addPersonalizationOptions(): Close fieldset. * (T227047) Soft-deprecate the remainder of ActorMigration. * (T316304, CVE-2022-41767) SECURITY: reassignEdits doesn't update results in an IP range check on Special:Contributions. * (T309894, CVE-2022-41765) SECURITY: HTMLUserTextField exposes existence of hidden users. * (T307278, CVE-2022-41766) SECURITY: On action=rollback the message "alreadyrolled" can leak revision deleted user name. * (T319186) .phan/config.php: Update minimum_target_php_version. * Tests: Explicit cast to int in RandomImageGenerator test (php8 warnings). * (T319186) .phan/config.php: Update minimum_target_php_version. * (T310243) Deprecate use of 'wvui-search' package. * utils: Fix return doc about false/null for UrlUtils::expand. * (T319000) WebInstaller: Don't try and run trim() on null. * In the event of preg failure in MagicWordArray throw exception. * (T318753) Installer: Disable logo dropper for now. Preliminary release notes: https://gerrit.wikimedia.org/g/mediawiki/core/+/REL1_39/RELEASE-NOTES-1.39 https://www.mediawiki.org/wiki/Release_notes/1.39 Open Bugs: [1] https://phabricator.wikimedia.org/tag/mw-1.39-release/ Bug report form: [2] https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?tags=MW-1.39-… ********************************************************************** Download: https://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.0-rc.1.tar.gz https://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.0-rc.1.zip Download without bundled extensions: https://releases.wikimedia.org/mediawiki/1.39/mediawiki-core-1.39.0-rc.1.ta… https://releases.wikimedia.org/mediawiki/1.39/mediawiki-core-1.39.0-rc.1.zip Patch to previous version (1.39.0-rc.0): https://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.0-rc.1.patch.gz https://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.0-rc.1.patch.z… GPG signatures: https://releases.wikimedia.org/mediawiki/1.39/mediawiki-core-1.39.0-rc.1.ta… https://releases.wikimedia.org/mediawiki/1.39/mediawiki-core-1.39.0-rc.1.zi… https://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.0-rc.1.tar.gz.… https://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.0-rc.1.zip.sig https://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.0-rc.1.patch.g… https://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.0-rc.1.patch.z… Public keys: https://www.mediawiki.org/keys/keys.html

1 0

[Small wiki toolkits] Upcoming "How to interact with Wikidata via Pywikibot" workshop on Friday, October 7th, 16:00 UTC
by Srishti Sethi 07 Oct '22

07 Oct '22

Hello everyone, The eighth workshop on the topic of "How to interact with Wikidata via Pywikibot" is coming up - it will take place on Friday, October 7th at 16:00 UTC. You can find more details on the workshop and a link to join here: < https://meta.wikimedia.org/wiki/Small_wiki_toolkits/Workshops#How_to_intera…> [1]. This workshop will summarise how to access and save information to Wikidata, including through page generators and queries*, using Pywikibot. It will also cover the Wikidata conventions about the bot editing, including the bot approvals process (*queries not included, please bring your own!). This session will be run by Mike Peel. To participate in this workshop, you would need basic familiarity with Wikidata and Pywikibot installation. We look forward to your participation! Best, Srishti On behalf of the SWT Workshops Organization team [1] https://meta.wikimedia.org/wiki/Small_wiki_toolkits/Workshops#How_to_intera… *Srishti Sethi* Senior Developer Advocate Wikimedia Foundation <https://wikimediafoundation.org/>

2 2

MediaWiki Extensions and Skins Security Release Supplement (1.35.8/1.37.5/1.38.3)
by Maryum Styles 06 Oct '22

06 Oct '22

Greetings- With the security/maintenance release of MediaWiki 1.35.8/1.37.5/1.38.3, we would also like to provide this supplementary announcement of MediaWiki extensions and skins with now-public Phabricator tasks, security patches and backports [1]: OAuth + (T308861 <https://phabricator.wikimedia.org/T308861>, CVE-2022-39191) - OAuth debug log includes consumer secrets https://gerrit.wikimedia.org/r/c/mediawiki/extensions/OAuth/+/839460/ GrowthExperiments + (T313205 <https://phabricator.wikimedia.org/T313205>, CVE-2022-39194) - Growth's Community configuration makes it possible for rogue admin to take down a site https://gerrit.wikimedia.org/r/q/I9b3766a71ee403b3a72c8af995e70c3017abe12e IPInfo + (T310763 <https://phabricator.wikimedia.org/T310763>, CVE-2022-39192) - IP Info tool shows whether an IP is autoblocked, potentially allowing unmasking of users by correlation https://gerrit.wikimedia.org/r/q/Ib1fdac6b2db70fc33f6d9e9f3e9108b6d65961b4 PageTriage + (T314245 <https://phabricator.wikimedia.org/T314245>, CVE-2022-41344) - Someone with patrol user right can mark own article as reviewed if they use api.php?action=pagetriageaction https://gerrit.wikimedia.org/r/q/I9a3c9dafc634c59d7dbf1d6d62da389046a0e22e OAuth + (T312820 <https://phabricator.wikimedia.org/T312820>, CVE-2022-41346) - Special:OAuth/rest_redirect does unrestricted redirects https://gerrit.wikimedia.org/r/q/I789fb7384d89fbf42df22dc7b1953fb9087d95b1 Translate + (T302479 <https://phabricator.wikimedia.org/T302479>, CVE-2022-41345) - Blocked users with "translation administrator" right are able to mark pages for translation https://gerrit.wikimedia.org/r/q/Ic206021 The Wikimedia Security Team recommends updating these extensions and/or skins to the current master branch or relevant, supported release branch [2] as soon as possible. Some of the referenced Phabricator tasks above _may_ still be private. Unfortunately, when security issues are reported, sometimes sensitive information is exposed and since Phabricator is historical, we cannot make these tasks public without exposing this sensitive information. If you have any additional questions or concerns regarding this update, please feel free to contact security(a)wikimedia.org or file a security task within Phabricator [3]. [0] https://w.wiki/5nN3 [1] https://phabricator.wikimedia.org/T311785 [2] https://www.mediawiki.org/wiki/Version_lifecycle [3] https://www.mediawiki.org/wiki/Reporting_security_bugs

1 0

Gerrit upgraded from 3.4.5 to 3.4.6
by Antoine Musso 06 Oct '22

06 Oct '22

Hello, I have upgraded Gerrit from version 3.4.5 to 3.4.6. It addresses a security issue and had one breaking change which should not affect us. It should not have any user facing change beside slightly better performance here and there. Release notes: https://www.gerritcodereview.com/3.4.html#346 Our task: https://phabricator.wikimedia.org/T319513 -- Antoine "hashar" Musso Release Engineering

1 0

TDF is looking for community representatives
by Erica Litrenta 05 Oct '22

05 Oct '22

*(This email may not be written in your native language, and/or may be a crosspost: our apologies.)* Greetings, everyone. The Technical Decision Forum, or TDF (1), is seeking community representatives. Please visit the TDF Community Representation (2) page for more information, and email TDFSupport(a)wikimedia.org by Aug 12, 2022 to be considered for selection. Don't worry about the requirements listed on wiki, they are not set in stone; just provide your name, name of the group you "represent" if any, and a short sentence or two explaining your interest. For any questions, please post at *MediaWiki.org (3)*, or on the related Movement Strategy Forum topic (4), or simply email TDFSupport(a)wikimedia.org. Thanks, The Technical Decision Forum. (1) https://www.mediawiki.org/wiki/Technical_decision_making/Forum (2) https://www.mediawiki.org/wiki/Technical_decision_making/Community_represen… (3) https://www.mediawiki.org/wiki/Talk:Technical_decision_making/Forum (4) https://forum.movement-strategy.org/t/technical-decision-forum-tdf-is-looki… -- ------------------------------ Erica Litrenta (she/her) Senior Manager, Community Relations Specialists (Product) Wikimedia Foundation <https://meta.wikimedia.org/wiki/User:Elitre_(WMF)>

2 2

[REMINDER] Coolest Tool Award 2022: Call for nominations!
by Seyram Komla Sapaty 05 Oct '22

05 Oct '22

Hi everyone! Just a reminder that there are 7 days left to submit your Coolest Tool Award <https://meta.wikimedia.org/wiki/Coolest_Tool_Award> nominations. Please recommend your favorite tools by October 12. Thanks! Komla, for the Coolest Tool Academy 2022 -- Seyram Komla Sapaty Developer Advocate Wikimedia Cloud Services

1 0

Talk to the Search Platform / Query Service Team—October 5th, 2022
by Guillaume Lederrey 05 Oct '22

05 Oct '22

Hello all! The Search Platform Team <https://www.mediawiki.org/wiki/Wikimedia_Search_Platform> usually holds an open meeting on the first Wednesday of each month. Come talk to us about anything related to Wikimedia search, Wikidata Query Service (WDQS), Wikimedia Commons Query Service (WCQS), etc.! Feel free to add your items to the Etherpad Agenda for the next meeting. Details for our next meeting: Date: Wednesday, October 5th, 2022 Time: 15:00-16:00 UTC / 08:00 PDT / 11:00 EDT / 17:00 CEST / 19:00 GST Etherpad: https://etherpad.wikimedia.org/p/Search_Platform_Office_Hours Google Meet link: https://meet.google.com/vgj-bbeb-uyi Join by phone: https://tel.meet/vgj-bbeb-uyi?pin=8118110806927 Have fun and see you soon! Guillaume -- *Guillaume Lederrey* (he/him) Engineering Manager Wikimedia Foundation <https://wikimediafoundation.org/>

1 1

🚂🌈Summary of 1.40.0-wmf.3 train deployment
by Brennen Bearnes 03 Oct '22

03 Oct '22

This email is a summary of the Wikimedia production deployment of 1.40.0-wmf.3 * Conductor: Brennen Bearnes * Backup Conductor: Jaime Nuche * Blocker Task: T314192 <https://phabricator.wikimedia.org/T314192> * Current Status <https://versions.toolforge.org> 🔢 Numbers Sparklines comparing with the last 5 trains. * 208 Patches ██▇▁▃ * 1 Rollbacks ▁▄█▁▄ * 1 Days of delay ▁██▁█ * 1 Blockers ▄▄█▄▁ 🌈 Traintastic Folks ✨ Thanks to folks who reported or resolved blockers: * revi | 레비 * Amir Sarabadani -- Brennen Bearnes Release Engineering Wikimedia Foundation

1 0

MediaWiki-Vagrant broken, master will switch to Debian Buster soon
by Klaas Skelte van der Werf 03 Oct '22

03 Oct '22

This is a heads-up message about upcoming changes to MediaWiki-Vagrant. With MediaWiki master now requiring PHP 7.4, MediaWiki-Vagrant is now completely unusable with MediaWiki. Currently, MediaWiki-Vagrant still uses Debian Stretch, for which custom PHP 7.2 packages were compiled. These are the same that were previously used in production. Stretch is now out of support completely, and no PHP 7.4 packages are available for it. Production already switched to Buster and has only compiled PHP 7.4 for that distro. As a result, switching to Debian Buster is the only remaining option. Because the buster-migration branch is out of date and equally broken, it will be abandoned and its patches cherry-picked onto master. A stretch-compat branch will be created but is basically useless unless you're trying to run older wmf release branches. The phabricator task for the buster migration is https://phabricator.wikimedia.org/T256822. Mainframe98

1 0

Phabricator monthly statistics - 2022-09
by aklapper＠wikimedia.org 30 Sep '22

30 Sep '22

Hi Community Metrics team, This is your automatic monthly Phabricator statistics mail. Accounts created in (2022-09): 256 Active Maniphest users (any activity) in (2022-09): 1005 Task authors in (2022-09): 546 Users who have closed tasks in (2022-09): 302 Projects which had at least one task moved from one column to another on their workboard in (2022-09): 318 Tasks created in (2022-09): 2244 Tasks closed in (2022-09): 2040 Open and stalled tasks in total: 50786 * Only open tasks in total: 49914 * Only stalled tasks in total: 872 Median age in days of open tasks by priority: Unbreak now: 24 Needs Triage: 814 High: 1206 Normal: 1731 Low: 2411 Lowest: 2548 (How long tasks have been open, not how long they have had that priority) Active Differential users (any activity) in (2022-09): 8 To see the names of the most active task authors: * Go to https://wikimedia.biterg.io/ * Choose "Phabricator > Overview" from the top bar * Adjust the time frame in the upper right corner to your needs * See the author names in the "Submitters" panel TODO: Numbers which refer to closed tasks might not be correct, as described in https://phabricator.wikimedia.org/T1003 . Yours sincerely, Fab Rick Aytor (via community_metrics.sh on phab1001 at Sat 01 Oct 2022 12:00:20 AM UTC)

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l October 2022