Wikitech-l June 2023

wikitech-l@lists.wikimedia.org

27 participants
30 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 28 Jun '24

28 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

Announcing: Path review board
by Brian Wolff 04 Oct '23

04 Oct '23

Yesterday there was a conversation about code review on irc and among other things, how sometimes patches can get "stuck". I had an idea for a way to improve things. I'm not sure if it is a good idea, but there's only one way to find out. So without further ado, announcing the Code Review Patch Board: https://www.mediawiki.org/wiki/Code_review/patch_board In short - each person is allowed to list one of their patches on the board that they would really like to see reviewed. You can only list one patch at a time, and it should be a patch that you have been unable to get review for for at least a week through normal means. See the page for the full list of guidelines. I encourage people to give it a try. Add a patch you wrote that you cannot get a review for. Or if you have +2 rights, try giving some love to these underloved patches. I would also love to hear feedback on the general idea as well as the current guidelines. To repeat, the url is: https://www.mediawiki.org/wiki/Code_review/patch_board Thanks, bawolff

4 5

Announcing MediaWiki 1.40.0
by Sam Reed 08 Aug '23

08 Aug '23

I am happy to announce the availability of the general release of MediaWiki 1.40! This includes the security fixes announced in 1.35.11/1.38.7/1.39.4. Tarballs have already been uploaded, and the git tag has been pushed. Thanks to everyone who helped out with this release, especially thanks to those who tested out the release candidate and provided feedback, as well as the developers who worked hard to get several important fixes merged in time for the 1.40 final release. To see what's changed in 1.40, see the release notes below. MediaWiki 1.40 is the second release of MediaWiki 'born' with PHP 8.0 and PHP 8.1 support included. We anticipate there may be some as-yet undiscovered bugs with PHP 8.x support, of which we'd love to hear reports so they can be fixed. We plan to back-port fixes to 1.39, 1.38 and 1.35 to the extent possible. MediaWiki 1.40 is due to be supported until the end of June 2024. As a reminder, 1.35 LTS is due to become end-of-life in November 2023, and 1.38 became end-of-life today, 30 June 2023. === Changes since MediaWiki 1.40.0-rc.0 === * Localisation updates. * (T330464) Work around argument corruption bug in XMLReader::open. * build: Updating mediawiki/mediawiki-phan-config to 0.12.1. * Fix frame and frameless rdfa depending on file existing. * (T329214) Pass whether current rev of file exists to Linker::makeBrokenImageLinkObj. * (T334659) Handle thumb errors when !$enableLegacyMediaDOM. * A manualthumb that doesn't exist should be considered a thumb error. * (T313157) IndexPager: Also protect against $offset being 0. * (T335612, CVE-2023-36674) SECURITY: Move badFile lookup to Linker. Open Bugs: [1] https://phabricator.wikimedia.org/project/board/6139/ Bug report form: [2] https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?tags=MW-1.40-… ********************************************************************** Download: https://releases.wikimedia.org/mediawiki/1.40/mediawiki-1.40.0.tar.gz https://releases.wikimedia.org/mediawiki/1.40/mediawiki-1.40.0.zip Download without bundled extensions: https://releases.wikimedia.org/mediawiki/1.40/mediawiki-core-1.40.0.tar.gz https://releases.wikimedia.org/mediawiki/1.40/mediawiki-core-1.40.0.zip Patch to previous version (1.40.0-rc.0): https://releases.wikimedia.org/mediawiki/1.40/mediawiki-1.40.0.patch.gz https://releases.wikimedia.org/mediawiki/1.40/mediawiki-1.40.0.patch.zip GPG signatures: https://releases.wikimedia.org/mediawiki/1.40/mediawiki-core-1.40.0.tar.gz.… https://releases.wikimedia.org/mediawiki/1.40/mediawiki-core-1.40.0.zip.sig https://releases.wikimedia.org/mediawiki/1.40/mediawiki-1.40.0.tar.gz.sig https://releases.wikimedia.org/mediawiki/1.40/mediawiki-1.40.0.zip.sig https://releases.wikimedia.org/mediawiki/1.40/mediawiki-1.40.0.patch.gz.sig https://releases.wikimedia.org/mediawiki/1.40/mediawiki-1.40.0.patch.zip.sig Public keys: https://www.mediawiki.org/keys/keys.html

3 2

Service Decommission Notice: Mobile Content Service - July 2023
by Adam Baso 07 Jul '23

07 Jul '23

TL;DR: The legacy Mobile Content Service is going away in July 2023. Please switch to Parsoid or another API before then to ensure service continuity. Hello World, I'm writing about a service decommission we hope to complete mid-July 2023. The service to be decommissioned is the legacy Mobile Content Service ("MCS"), which is maintained by the Wikimedia Foundation's Content Transform Team. We will be marking this service as deprecated soon. We hope that with this notice, people will have ample time to update their systems for use of other endpoints such as Parsoid [1] (n.b., MCS uses Parsoid HTML). The MCS endpoints are the ones with the relative URL path pattern /page/mobile-sections* on the Wikipedias. For examples of the URLs see the "Mobile" section on the online Swagger (OpenAPI) specification documentation with matching URLs here: https://en.wikipedia.org/api/rest_v1/#/Mobile == History == The Mobile Content Service ("MCS") is the historical aggregate service that originally provided support for the article reading experience on the Wikipedia for Android native app, as well as some other experiences. We have noticed that there are other users of the service. We are not able to determine all of the users, as it's hard to tell with confidence from the web logs. The Wikimedia Foundation had already transitioned the Wikipedia for Android and iOS apps to the newer Page Content Service ("PCS") several years ago. PCS has some similarities with MCS in terms of its mobility focus, but it also has different request-response signatures in practice. PCS, as with MCS, is intended to primarily satisfy Wikimedia Foundation-maintained user experiences only, and so this is classified with the "unstable" moniker. == Looking ahead == Generally, as noted in the lead, we recommend that folks who use MCS (or PCS, for that matter) switch over to Parsoid for accessing Wikipedia article content programmatically for the most predictable service. The HTML produced by Parsoid has a versioned specification [2] and because Parsoid is accessed regularly by a number of components across the globe tends to have fairly well cached responses. However, please note that Parsoid may be subject to stricter rate limits that can apply under certain traffic patterns. At this point, I do also want to note that in order to keep up with contemporary HTML standards, particularly those favoring accessibility and machine readability enhancements, Parsoid HTML will undergo change as we further converge parsing stacks [3]. Generally, you should expect iteration on the Parsoid HTML spec, and of course as you may have come to appreciate that the shape of HTML in practice can vary nontrivially wiki-by-wiki as practices across wikis vary. You may also want to consider Wikimedia Enterprise API options, which range from no cost to higher volume access paid options. https://meta.wikimedia.org/wiki/Wikimedia_Enterprise#Access == Forking okay, but not recommended == Because MCS acts as a service aggregate and makes multiple backend API calls, caveats can apply for those subresources - possibility of API changes, deprecation, and the like. We do not recommend a plain fork of MCS code because of the subresource fetch behavior. This said, of course you are welcome to fork in a way compatible with MCS's license. == Help spread the word == Although we are aware of the top two remaining consumers of MCS, we also are not sure who else is accessing MCS and anticipate that some downstream tech may break when MCS is turned off. As we are cross-posting this message, we hope most people who have come to rely upon MCS will see this message. Please feel free to forward this message to contacts if you know they are using MCS. == Help == Although we intend to decommission MCS in July 2023, we would like to share resources if you need some help. We plan to hold office hours in case you would like to meet with us to discuss this or other Content Transform Team matters. We will host these events on Google Meet. We will provide notice of these office hours on the wikitech-l mailing list in the coming weeks and months. Additionally, if you would like to discuss your MCS transition plans, please visit the Content Transform Team talk page: https://www.mediawiki.org/wiki/Talk:Content_Transform_Team Finally, some Content Transform Team members will also be at the Wikimedia Hackathon [4] if you would like some in-person support. Thank you. Adam Baso (he/him/his/Adam), on behalf of the Content Transform Team Director of Engineering Wikimedia Foundation [1] https://www.mediawiki.org/wiki/Parsoid [2] https://www.mediawiki.org/wiki/Specs/HTML [3] https://www.mediawiki.org/wiki/Parsoid/Parser_Unification/Updates [4] https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2023

3 7

MediaWiki Extensions and Skins Security Release Supplement (1.35.11/1.38.7/1.39.4/1.40.0)
by Maryum Styles 03 Jul '23

03 Jul '23

Greetings- With the security/maintenance release of MediaWiki 1.35.11/1.38.7/1.39.4/1.40.0, 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 + (T333569, CVE-2023-37255) - Special:CheckUser 'get edits' is vulnerable to HTML injection through user agent string. https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/905706/ GoogleAnalyticsMetrics + (T333980, CVE-2023-37251) - GoogleAnalyticsMetrics parser function in extension does not properly escape js in onclick handler and does not prevent using javascript urls. https://gerrit.wikimedia.org/r/c/905661 CheckUser + (T330968, CVE-2023-37252) - Special:CheckUserLog shows usernames which have been hidden. https://gerrit.wikimedia.org/r/c/933686 https://gerrit.wikimedia.org/r/c/932822 Cargo + (T331311, CVE-2023-37256) - Cargo allows storing javascript URLs in URL fields, and automatically linking them. https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Cargo/+/894679 Cargo + (T331065, CVE-2023-37254) - XSS in Special:CargoQuery using default format. https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Cargo/+/894666 ProofreadPage + (T326952, CVE-2023-37253) - ProofreadPage leaks suppressed user via the API and config variables. https://gerrit.wikimedia.org/r/q/Ibe5f8e25dea155bbd811a65833394c0d4b906a34 DoubleWiki + (T323651, CVE-2023-37304) - XSS in DoubleWiki extension (Wikisource). https://gerrit.wikimedia.org/r/c/933666 https://gerrit.wikimedia.org/r/c/933667 https://gerrit.wikimedia.org/r/c/932825 CheckUser + (T338276, CVE-2023-37303) - Wikimedia\Rdbms\DBQueryDisconnectedError when blocking user. https://gerrit.wikimedia.org/r/c/932823 Wikibase + (T250720, CVE-2023-37301) - Wikidata edit filter does not fire when test tool says it should. https://gerrit.wikimedia.org/r/c/933663 Wikibase + (T339111, CVE-2023-37302) - Style injection into badges on Wikidata due to unescaped quotes. https://gerrit.wikimedia.org/r/c/933649 https://gerrit.wikimedia.org/r/c/933650 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/T333626 [2] https://www.mediawiki.org/wiki/Version_lifecycle [3] https://www.mediawiki.org/wiki/Reporting_security_bugs

2 1

🧑‍💻📊 RESULTS! Wikimedia developer satisfaction survey 2023
by Tyler Cipriani 01 Jul '23

01 Jul '23

Results: https://www.mediawiki.org/wiki/Developer_Satisfaction_Survey/2023 🥰 Thanks to everyone who took the time to respond to the survey! The developer satisfaction survey results show what's important to our developer community—the parts of the developer experience that work well, and the parts that need more resources to improve. ➡️ Read it. Talk about it. And ask questions! (please ;))! 🎉 Huge thanks to the Wikimedia Research Team[0] for helping Release Engineering build the survey and process the data. In particular, Yu-Ming Liou for survey-building expertise. And Caroline Myrick who was a hero processing, exploring, graphing, and patiently explaining all the data. <3 Tyler Cipriani (he/him) Engineering Manager, Release Engineering Wikimedia Foundation [0]: <https://www.mediawiki.org/wiki/Wikimedia_Research>

1 0

MediaWiki 1.38 is End of Life
by Sam Reed 01 Jul '23

01 Jul '23

As per the MediaWiki version lifecycle[1], I would like to announce the formal end of life (EOL) of MediaWiki 1.38 as of today, Friday June 30, 2023. 1.38.7 is expected to be the last release for this branch. This means that MediaWiki 1.38 will no longer receive maintenance or security backports. It is therefore strongly discouraged that you continue to use it. It is recommended to upgrade either to MediaWiki 1.39 (LTS), which will be supported until November 2025 or to 1.40 (released today), which will be supported until June 2024. Thanks! Sam Reed [1] https://www.mediawiki.org/wiki/Version_lifecycle

1 0

Security and maintenance release: 1.35.11 / 1.38.7 / 1.39.4
by Sam Reed 01 Jul '23

01 Jul '23

1 0

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