Wikitech-l January 2023

wikitech-l@lists.wikimedia.org

37 participants
34 discussions

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

MediaWiki Extensions and Skins Security Release Supplement (1.35.9/1.38.4/1.39.1)
by Manfredi Martorana 04 Apr '23

04 Apr '23

Greetings- With the security/maintenance release of MediaWiki 1.35.9/1.38.4/1.39.1, we would also like to provide this supplementary announcement of MediaWiki extensions and skins with now-public Phabricator tasks, security patches and backports [1]: CheckUser + (T311337 <https://phabricator.wikimedia.org/T311337>, CVE-2022-39193) - Edits with the performer suppressed still show the performer in results from the CheckUser extension https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/879167/ CheckUser + (T316414 <https://phabricator.wikimedia.org/T316414>, CVE-2022-39193) - Special:Investigate can expose supressed information in check results https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/879166/ CheckUser + (T318166 <https://phabricator.wikimedia.org/T318166>, CVE-2022-39193) - CheckUser API can expose the suppressed performer https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/879073/ GrowthExperiments + (T321733 <https://phabricator.wikimedia.org/T321733>, CVE-2023-22945) - Action=growthmanagementorlist makes it possible for blocked users to enroll as mentors https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/8… CheckUser + (T315123 <https://phabricator.wikimedia.org/T315123>, CVE-2023-22912) - CheckUser TokenManager insecurely uses AES-CTR encryption with repeated nonce, allowing an adversary to decrypt https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/879074/ MobileFrontend + (T320987 <https://phabricator.wikimedia.org/T320987>, CVE-2023-22909) - Mobile frontend's history makes really slow db queries https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/8577… Widgets + (T149488 <https://phabricator.wikimedia.org/T149488>, CVE-2023-22911) - Widgets does widget replacement in html attributes potentially leading to XSS https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Widgets/+/856035/ Wikibase + (T323592 <https://phabricator.wikimedia.org/T323592>, CVE-2023-22910) - XSS in Wikibase date formatting https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/879171/ 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]. [1] https://phabricator.wikimedia.org/T318974 [2] https://www.mediawiki.org/wiki/Version_lifecycle [3] https://www.mediawiki.org/wiki/Reporting_security_bugs

1 1

Deprecation: directly invoking maintenance scripts
by Daniel Kinzler 03 Mar '23

03 Mar '23

TLDR: Invoking maintenance scripts directly will be deprecated in MW 1.40, use maintenance/run.php instead. This affects anyone managing a MediaWiki installation, for development, testing, or production use. Until now, MediaWiki maintenance scripts have been handled standalonePHP scripts - for instance, to run the script that outputs the MediaWiki version, you would use: > php maintenance/version.php Starting with MediaWiki 1.40, this is deprecated. The preferred way to run maintenance scripts is now by name, using the maintenance runner: > php maintenance/run.php version Similarly, the preferred way to run the updater is now: > php maintenance/run.php update The script to run cal also be specified using the full path of the script file, or the full PHP class name of a subclass of the Maintenance class. For more details, run > php maintenance/run.php --help Rationale and History: Treating maintenance scripts as standalone PHP scripts requires some boilerplate code to be present at the top and at the bottom of every file. This is error prone and makes it difficult to update the maintenance framework. But more importantly, for this boilerplate to work, the location of the MediaWiki installation has to be known relative to the maintenance script, which is not reliably possible for scripts defined in extensions. A similar problem arises if the maintenance script needs a base class other than the default Maintenance class: since the class is loaded before MediaWiki is initialized, the autoloader is not yet in place, and the file containing the base class needs to be included explicitly. These and similar issues can be avoided by creating a wrapper script that loads and executes the actual maintenance class. This way, the maintenance wrapper can initialize MediaWiki before passing control to the script. I propose creating such a wrapper as an RFC in 2018 (T99268)[^1], which was approved in 2019. However, implementing the proposal proved challenging, and soon stalled. I picked it up again as a side project after working on overhauling the configuration and bootstrapping code in early 2022: With the introduction of SettingsBuilder, it became much simpler to create a MaintenanceRunner class, because it was no longer necessary to juggle global variables. Several bits and pieces got reviewed and merged over the course of 2022 (shout out to Amir, Tim, Timo, and everyone who contributed). Now the runner is ready, and we should stop calling maintenance scripts directly. For now, existing maintenance scripts will function both ways[^2] : when called using the runner, or directly. However, newly created maintenance scripts should not be required to be callable as standalone scripts. So it's best to change all callers to use the wrapper. This should now work for nearly all[^2] cases, though there are still a couple of rough edges to be smoothed out. If you are running MediaWiki 1.40, please try the new mechanism, and report any isses on Phabricator. Thanks, Daniel [^1] https://phabricator.wikimedia.org/T99268 [^2] with the exception over very old-school scripts that do not use the Maintenance base class and rely on CommandLineInc.php instead. -- Daniel Kinzler Principal Software Engineer, Platform Engineering Wikimedia Foundation

6 8

Call for projects and mentors for Google Summer of Code 2023 and Outreachy Round 26 is ongoing!
by Srishti Sethi 24 Feb '23

24 Feb '23

Hello everyone, TLDR; Wikimedia will soon be applying as a mentoring organization to *Google Summer of Code 2023* < https://www.mediawiki.org/wiki/Google_Summer_of_Code/2023> [1] and *Outreachy Round 26* <https://www.mediawiki.org/wiki/Outreachy/Round_26> [2]. We are currently working on a list of interesting project ideas to include in the application. If you have some ideas for *coding or non-coding (design, documentation, translation, outreach, research) projects*, share them by* February 7th* here: <https://phabricator.wikimedia.org/T326991> [3]. For non-coding projects that can be promoted via Outreachy, there are only two available slots, which will be allocated to mentors on a first-come, first-serve basis. *Timeline* As a mentor, you will engage potential candidates in the application period for both programs between March and April. You will help candidates make small contributions to your project and answer any project-related queries during this time. You will work more closely with the accepted candidates during the coding period between May and August. *Tips for proposing projects* * Follow this task description template when you propose a project in Phabricator: < https://phabricator.wikimedia.org/tag/outreach-programs-projects> [4]. You can also use this workboard to pick an idea if you don't have one already. Add #Google- Summer-of-Code (2023) or #Outreachy (Round 26) tag. * Project should require an experienced developer ~15 days and a newcomer ~3 months to complete. * Each project should have at least two mentors, including one with a technical background. * Ideally, the project has no tight deadlines, a moderate learning curve, and fewer dependencies on Wikimedia's core infrastructure. Projects addressing the needs of a language community are most welcome. Learn more about the roles and responsibilities of mentors on MediaWiki.org: <https://www.mediawiki.org/wiki/Outreachy/Mentors> [5], < https://www.mediawiki.org/wiki/Google_Summer_of_Code/Mentors> [6]. Cheers, Srishti [1] https://www.mediawiki.org/wiki/Google_Summer_of_Code/2023 [2] https://www.mediawiki.org/wiki/Outreachy/Round_26 [3] https://phabricator.wikimedia.org/T326991 [4] https://phabricator.wikimedia.org/tag/outreach-programs-projects/ [5] https://www.mediawiki.org/wiki/Outreachy/Mentors [6] https://www.mediawiki.org/wiki/Google_Summer_of_Code/Mentors *Srishti Sethi* Senior Developer Advocate Wikimedia Foundation <https://wikimediafoundation.org/>

10 13

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

Notification about Gerrit related request
by Zoran Dori 15 Feb '23

15 Feb '23

Hello, as per https://www.mediawiki.org/wiki/Gerrit/Privilege_policy , I want to notify you that I made task https://phabricator.wikimedia.org/T323247 about granting me ownership of the Gerrit repository of the UnblockMe extension. I would appreciate your suggestions or +1s. :) Thank you for your time and consideration! Best regards, Zoran

1 1

[event] [crossposting] Wiki-based Business Process Tooling at NASA: The Need for Open CSP
by Erica Litrenta 08 Feb '23

08 Feb '23

The Tech Department at Wikimedia Foundation [1] invites you to a* special event on February 09, 2023, at 1600 UTC* [2]. *Richard Evans, Electronics & Data Systems Engineer At NASA Glenn Research Center *[3], will be presenting on *how MediaWiki is being used within NASA* to help manage the testing of very large spacecraft to prove they can survive the harsh conditions of launch, orbit, and re-entry. The management platform is built from MediaWiki and several key extensions that provide workflow support. This evolving platform plans to incorporate the extensions that form the MediaWiki-powered Open CSP platform [4]. This talk will explain the architecture and benefits of the NASA platform and motivate the need for Open CSP. We’ll also be recording the event to share with those who can’t make it. You can join the event through Google Meet [5]. Looking forward to seeing you there, *--on behalf of the Tech Department, Wikimedia Foundation.* *(For follow-ups, please reach out to *lnguyen(a)wikimedia.org.) [1] https://www.mediawiki.org/wiki/Wikimedia_Technology [2] https://zonestamp.toolforge.org/1675958415 [3] https://www.wikidata.org/wiki/Q618728#sitelinks-wikipedia [4] https://www.open-csp.org/Main_Page [5] https://stream.meet.google.com/stream/ce81307c-cdb7-4a5e-9697-65c423f27614 -- ________________________________ Erica Litrenta (she/her) Senior Manager, Community Relations Specialists (Product) Wikimedia Foundation

1 2

PSA: ResourceLoader modules now default to mobile and desktop in 1.40
by Jon Robson 05 Feb '23

05 Feb '23

TLDR: Any ResourceLoader module will now run on mobile or desktop site by default. Previously they would only load on the desktop site. Hopefully this goes without disruption, but to be safe, if you maintain code used in Wikimedia production, please: 1) check your experiences over the course of this week in mobile/desktop site for JS errors/obvious UI errors (the former will be detected and monitored via logstash) 2) check that your repository doesn't fail the core testUnsatisfiableDependencies PHPUnit test. 3) Please check out the following Phabricator tickets to see if you are impacted on the long term [4][5]. # Background Back in the early days of MobileFrontend, most of the JavaScript we had was not mobile friendly. To avoid this we created an allow-list system, where JavaScript was disabled by default and extensions/skins had to explicitly enable it by adding a "_targets" property to their ResourceLoaderModule definition. This was meant as a short term solution, but as with many things, attention got pulled elsewhere, and almost ten years later it was still there. There have been many complaints about this over those years. Mainly: 1) It means we have split the ResourceLoader cache further 2) It's not intuitive - new code was getting shipped to desktop only experiences by default. It also featured on the Developer Wishlist of 2017 at #34 [1]. 3) Many older features don't work for community members for no credible reason. # Recent developments As one of the few remaining people responsible for doing this in the first time, I felt obliged to spend some time over December trying to pay off this technical debt. I audited code that was being removed by the _targets system [2] and made the _target explicit. Where modules were problematic on mobile, we marked them in such a way that it was clear that they should only run in a certain mode. This was only possible thanks to attention from Amir, Santosh, Thiemo, Lucas W, Tpt, Sohom D, Bartosz - thank you all. Today, Roan merged a change that makes ResourceLoader modules default to the desktop AND mobile sites. This should be a harmless change, but may be unintentionally triggering failures in testUnsatisfiableDependencies tests as it seems some extension/skins are not included in the MediaWiki core PHPUnit test run. If you encounter this issue, the fix is relatively simple - you must define _targets explicitly (see this example [6] and apologies in advance for any annoyance this may cause) # For action Please take extra care with your code that you test on both mobile/desktop sites and at mobile/desktop breakpoints. It's still possible to ship code to mobile/desktop and see these guidelines [3] if you need to do that or reply to this email with any questions you have. # Next steps This change will help with limiting the _targets system to existing known cases. This has been a long term request of the performance team. Please see the follow up tickets to see if there is any action from you at your leisure [4][5]. [1] https://www.mediawiki.org/wiki/Developer_Wishlist/2017/results [2] in https://phabricator.wikimedia.org/T324723 [3] https://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_for_extension… [4] https://phabricator.wikimedia.org/T328497 [5] https://phabricator.wikimedia.org/T328498 [6] https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PropertySuggester/+/8…

2 2

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 January 2023