Wikitech-l September 2024

wikitech-l@lists.wikimedia.org

43 participants
48 discussions

MediaWiki 1.43-alpha will be branched as a beta on 22 October 2024
by Mateus Santos 14 Sep '24

14 Sep '24

Hey all, This is a quick note to highlight that in five weeks' time, the REL1_43 branch will be created for MediaWiki core and each of the extensions and skins in Wikimedia git, with some (the 'tarball') included as sub-modules of MediaWiki itself[0]. This is the first step in the release process for MediaWiki 1.43, which should be out in December 2024, approximately six months after MediaWiki 1.42. The branches will reflect the code as of the last 'alpha' branch for the release, 1.43.0-wmf.28, which will be deployed to Wikimedia wikis in the week beginning 22 October 2024 for MediaWiki itself and those extensions and skins available there. After that point, patches that land in the main development branch of MediaWiki and its bundled extensions and skins will be instead be slated for the MediaWiki 1.44 release unless specifically backported[1]. If you are working on a new feature that you wish to land for the release, you now have a few days to finish your work and land it in the development branch; feature changes should not be backported except in an urgent case. If your work might not be complete in time, and yet should block release for everyone else, please file a task against the `mw-1.43-release` project on Phabricator.[2] If you have tickets that are already tagged for `mw-1.43-release`, please finish them, untag them, or reach out to get them resolved in the next few weeks. We hope to issue the first release candidate, 1.43.0-rc.0, two weeks after the branch point, and if all goes well, to release MediaWiki 1.43.0 a few weeks after that, before the end of year code freeze. Mateus Santos (he/him) Product Manager, MediaWiki Engineering Group Wikimedia Foundation [0]: https://www.mediawiki.org/wiki/Bundled_extensions_and_skins [1]: https://www.mediawiki.org/wiki/Backporting_fixes [2]: https://phabricator.wikimedia.org/tag/mw-1.43-release/

1 0

Log out (Global Auth)?
by Martin Domdey 13 Sep '24

13 Sep '24

Hi, when I login I click on "Keep me logged in". In dewiki and enwiki and the other wikipedia.org domain sites I stay logged in, but all several days I become logged out from commonswiki and metawiki and the other wikimedia.org domain sites. My nickname is: user:Doc_Taxon Please check, what's going wrong with logging out. Thanks a lot, Martin aka Doc Taxon

2 1

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

Deprecation notice: migration of metrics from graphite to Prometheus
by Leo Mata 12 Sep '24

12 Sep '24

TLDR Graphite is deprecated. Existing metrics are being actively migrated to Prometheus. The SRE Observability team asks that no new metrics be deployed to Graphite, as the service will be transitioned to a read-only state by EoQ3 FY2024/25 (~Spring 2025). For additional details, please see the tracking task https://phabricator.wikimedia.org/T228380 or the roadmap here: https://wikitech.wikimedia.org/wiki/Graphite/Deprecation_Roadmap. ------------------------------ Context The SRE Observability team has been operating Prometheus in production for several years, offering several operational benefits over Graphite. After a long period of observation and usage, the team has determined that migrating MW off Graphite ensures we stay ahead with a supported, scalable metrics platform for more effective, multidimensional metrics analysis and storage. Prometheus also provides more robust data labeling, storage, and querying capabilities. This initiative is fundamental to unifying our metrics, enhancing monitoring, improving MW observability, and reducing tool fragmentation. Background Last (fiscal) year, the SRE Observability team set out to test whether a new metrics interface was viable <https://phabricator.wikimedia.org/T240685> [1] and determined that long-term platform sustainability demanded migrating MediaWiki metrics to Prometheus <https://wikitech.wikimedia.org/wiki/Prometheus> [2]. To this end, the team decided to utilize StatsLib, a new, internally developed, Prometheus-capable metrics interface <https://phabricator.wikimedia.org/T350592> [3]. By the end of FY23/24 Q2, the team had successfully tested the component in production, and by the end of FY23/24 Q4, it had advanced the migration by about 42% in total metrics volume; we are set on reaching ~60% migration by the end of Q1 FY 2024/2025. See Graphite metrics volume migration dashboard <https://grafana.wikimedia.org/d/nCxX65cSk/mediawiki-statslib-migration?orgI…>. [4] Working to improve MW ecosystem sustainability, we are setting goals to complete the migration of active, production, and in-use (by dashboards/alerts) metrics to Prometheus this fiscal year. For scoping purposes, we define as “in-use” any metric emitted to graphite mapped to a dashboard panel or alert active in Grafana. See Graphite Utilization Dashboard <https://grafana.wikimedia.org/d/K6DEOo5Ik/grafana-graphite-datasource-utili…> [5] for details. RFC on Prometheus as a better interface for MW metrics: T249164 <https://phabricator.wikimedia.org/T249164> [6]. Notice and Action Required The team plans to enable read-only mode on the Graphite cluster by the end of Q3 FY 2024/2025 and begin the formal deprecation of Graphite in production <https://phabricator.wikimedia.org/T228380> [7]. We are asking all teams and maintainers to review https://phabricator.wikimedia.org/T350592 [3] and related subtasks, claim metrics, and components under their care, disable/remove any unused metrics and dashboards first, then follow the migration process outlined in the task for any in-use relevant metrics before the end of Q3 FY 2024/2025 (March 2025). After this date, Graphite will be read-only, and no new data will be ingested. Graphite will continue to be available for another year to provide historical data in read-only “mode” while new history is recorded in Prometheus. For additional details, please see the tracking task T228380 <https://phabricator.wikimedia.org/T228380> [7] or roadmap here: https://wikitech.wikimedia.org/wiki/Graphite/Deprecation_Roadmap [8]. Related Links: [1] https://phabricator.wikimedia.org/T240685 [2] https://wikitech.wikimedia.org/wiki/Prometheus [3] https://phabricator.wikimedia.org/T350592 [4] https://grafana.wikimedia.org/d/nCxX65cSk/mediawiki-statslib-migration?orgI… [5] https://grafana.wikimedia.org/d/K6DEOo5Ik/grafana-graphite-datasource-utili… [6] https://phabricator.wikimedia.org/T249164 [7] https://phabricator.wikimedia.org/T228380 [8] https://wikitech.wikimedia.org/wiki/Graphite/Deprecation_Roadmap thank you, Leo Mata. *Leo Mata* (he/him) Engineering Manager - Observability Wikimedia Foundation <https://wikimediafoundation.org/>

1 0

Disabling createpage right in Serbian Wikipedia for non-registered users
by Zoran Dori 11 Sep '24

11 Sep '24

Hello everyone, currently, some sysops (including me) and one non-sysop user are having an on-wiki discussion on Serbian Wikipedia, regarding disabling page creation there, because lately (some) anonymous and new users don't have peace and are "making vandalisms" (I'm sure that there is a better word, so feel free to correct me if I'm wrong) by creating new pages. See this screenshot as an example: https://i.imgur.com/wpvq4kG.png As well and https://sr.wikipedia.org/wiki/Википедија:Администраторска_табла#Неприкладан… and https://sr.wikipedia.org/wiki/Википедија:Администраторска_табла# Ограничења%20за%20креирање%20нових%20страница? I know that these topics could be confusing, but the second one is more about technical stuff. I'm aware of the procedure for configuration changes on Wikimedia's projects regarding gaining community consensus, so I would happily start RfC there. Is this something that could be done, from the perspective of limitations for configuration changes? The non-sysop user, which I mentioned here, made a suggestion (which I'm considering as a compromise to not fully interfere with concept of Wikipedia works) to keep creating pages in the Draft namespace as an available option, like on English (and Persian) Wikipedia. See https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/223497. I'm looking forward to responses, questions, suggestions, and a nice discussion. :) Best regards, Zoran P. S. I wanted to make a draft patch in Gerrit for this, but I'm unsure of where to start, so help about that would be really appreciated.

4 6

MediaWiki Insights - August edition
by Birgit Müller 11 Sep '24

11 Sep '24

Hi All, Welcome to the monthly MediaWiki Insights email! First of all, many thanks and congratulations to the 12 new volunteer contributors: Alex (AllUsernamesArePicked), andrybak (Andrei Rybak), AutumnFeather, Claire (BlankEclair), Daniel Riedmueller, Jbol, Mahmoud Al-Qudsi (mqudsi), Newton Kamau, Nunya Klah, Rummskartoffel, XXBlackburnXx, and أنون (Lolekek). Each of them got their first patch merged in MediaWiki core, extensions or services deployed in Wikimedia production during the month of August! (or at the very end of July) Some of the developers joining us this month are longstanding members of the Wikimedia project communities; others use MediaWiki outside of Wikimedia and submitted patches upstream for the first time; and others we don't know much about, other than that they also wanted to help with the project. Glad to see you all around! Project Snapshots: Progress on annual plan initiatives In July we kicked off work under the Foundation’s new annual plan <https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/…> (July 2024 - June 2025). Two months into the new plan, we’ve made good progress on many of the initiatives to evolve the MediaWiki platform (WE5) and improve the services and tools that developers need to support the Wikimedia projects (WE6). *WE 5.2* <https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Artifacts/KR_5.2:…> is focusing on exploring ways to simplify feature development by enabling more modularity and improving the maintainability of the software. This Key Result (“KR”) kicked off with research (first quarter) that will inform the initial experiments (second quarter). We started this work by looking at the ecosystem of hooks that are used by extensions to integrate with MediaWiki <https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Artifacts/KR_5.2:…>. So far, we analyzed a sample of 120 of the 1409 hook handlers we use on MediaWiki sites (implementing 60 of 460 distinct hooks). We evaluated about 20 aspects of each handler in order to identify patterns and opportunities for improvement. For instance, about half of the 60 hooks could be isolated from the database to improve maintainability and security. And it looks like 9 of the hooks could even be replaced by declarative registration, which would reduce complexity. Next, we will summarize our findings and propose experiments and explorations that could lead us towards a more expressive and sustainable interface between MediaWiki core and extensions. You can find more information on the project page <https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Artifacts/KR_5.2:…> . *WE5.3* is focusing on performance experiments by treating a page as a composition of structured fragments. The initial work consists of two pieces: Instrumentation and data gathering to inform future performance and templating improvements (5.3.1 <https://phabricator.wikimedia.org/T363421>) and Prototype selective html updates in Parsoid (5.3.2 <https://phabricator.wikimedia.org/T371713>). We have implemented a very basic selective html update technique in Parsoid to update pages when a dependent template is edited. There are still correctness and functionality gaps, but the implementation is complete enough to let us gather preliminary performance numbers. We notice up to 5x+ speedup updating a page when a dependent template is edited - the benefit depends on the complexity of the template and the page using the template. The larger the page and simpler the template, the larger the expected benefit. There is more work to be done to ensure correctness, but we don’t expect this to impact expected performance benefits significantly. This code in Parsoid assumes that the previous version of the HTML is available in cache and the template and page meet the criteria for selective HTML updates. The selective update technique crucially relies on a set of conditions being satisfied: previous version of page available in parser cache and template generating well-formed DOM fragments. So far, we find that previous HTML is present during parses that account for 50% of time spent in production and we expect to understand how often this is true with the collected data. Once complete, 5.3.1 and 5.3.2 can let us estimate the benefit of fully implementing and deploying these in production. The early results from 5.3.1 and 5.3.2 look promising. Separately, we have also been discussing and planning the work required to support the embedding of Wikifunctions on a Parsoid-enabled wiki. This work, when complete, will let Parsoid support Wikifunctions without needing to build a lot of new infrastructure for it. A previous edition of MediaWiki Insights <https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports/June_2024> mentioned work the MediaWiki Interfaces Team has been doing on improving the experience of REST API endpoint creators and callers. Another phase of that work was finished in August with the completion of Rest: Deprecate BodyValidato <https://phabricator.wikimedia.org/T358560>r. This required compatibility changes to several extensions, including: Checklists <https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Checklists/+/1043823?…>, MenuEditor <https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MenuEditor/+/1047154?…>, TuleapWikiFarm <https://gerrit.wikimedia.org/r/c/mediawiki/extensions/TuleapWikiFarm/+/1046…>, ContentStabilization <https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ContentStabilization/…>, Workflows <https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Workflows/+/1047144?u…>, BlueSpiceExtendedSearch <https://gerrit.wikimedia.org/r/c/mediawiki/extensions/BlueSpiceExtendedSear…> and others. Deprecating the old system directs endpoint creators down an implementation path that allows them to take advantage of recent improvements, such as convenience methods to generate response schemas <https://phabricator.wikimedia.org/T368131>, an initial usage of which can be seen in UpdateHandler <https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1055181/6/includes/Rest/H…>. This work is part of *KR 5.1*: Interventions to increase sustainability of the MediaWiki platform. A key goal of WE6 (Developer Services) this year is to evolve and improve our software testing capabilities. In the last Insights email <https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports/July_2024…> we shared about the work that is underway to facilitate the provisioning of testing environments on-demand for automatic and exploratory testing. In the meantime, we have released the new backend for PatchDemo <https://patchdemo.wmcloud.org/> that is backed by Kubernetes. You can try it out by enabling a flag on the PatchDemo UI. Next we will provide full feature completeness to the current offering and enable not just the provisioning of MediaWiki for testing, but also the testing of custom services & extensions. If you don't see your previously created environment, they are still available at patchdemo-legacy.wmcloud.org. You can read through the full list of initiatives planned under the Knowledge Platform objectives WE5 (MediaWiki Platform) and WE6 (Developer Services) on this page <https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/…> . With this, we’re wrapping up this edition! It has been great to see some of you at Wikimania <https://wikimania.wikimedia.org/wiki/2024:Wikimania> in August, at the Future of MediaWiki session <https://www.youtube.com/live/iRw444uS1-E?t=5698s>, the hallway track and in the dev corner <https://wikimania.wikimedia.org/wiki/2024:Program/Hackathon#Developer_Corne…> . Amir Sarabadani just shared with me the link to this ticket <https://phabricator.wikimedia.org/T183490>, which is an effort primarily driven by Zabe: It started at Wikimania and is about to complete: MCR schema migration for External Store URLs. Many thanks to Zabe & Amir for kicking this off, and for continuing the work after the event! Thanks all for reading, Birgit P.S.: For those of you who have missed the announcement on other channels: The voting period for the 2024 Board of Trustees election <https://meta.wikimedia.org/wiki/Special:MyLanguage/Wikimedia_Foundation_ele…> is still open through September 17, 2024. Eligibility criteria for developers (and for editors and translators) can be found on this page <https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections/2024/Voter_e…>. -- Birgit Müller (she/her) Director of Product, MediaWiki and Developer Experiences Wikimedia Foundation <https://wikimediafoundation.org/>

1 0

edit-a-thon scheduled at 2024-10-19 in San Miguel, Argentina
by Esteban Zarate 10 Sep '24

10 Sep '24

please take a look to https://phabricator.wikimedia.org/T374484 Regards!!!

1 0

[BREAKING CHANGE ANNOUNCEMENT] Wikidata Query Service graph split available in production; scholarly entity queries require migration by March 2025
by Guillaume Lederrey 10 Sep '24

10 Sep '24

Hi all! As part of the WDQS Graph Split project,[1] we have new SPARQL endpoints available for serving the “main”[2] and “scholarly”[3] subgraphs of Wikidata. As you might be aware we are addressing the Wikidata Query Service stability and scaling issues. We have been working on several projects to address these issues. This announcement is about one of them, the WDQS Graph Split.[1] This change will have an impact on certain uses of the Wikidata Query Service. We are now entering a transition period until the end of February 2025. The three SPARQL endpoints will remain in place until the end of the transition. At the end of the transition, query.wikidata.org will serve the main Wikidata subgraph (without scholarly articles). The query-main and query-scholarly endpoints will continue to be available after the transition. If you know to want more this change, please refer to the talk page on Wikidata.[4] Have fun! Guillaume [1] https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/WDQS_graph_split [2] https://query-main.wikidata.org [3] https://query-scholarly.wikidata.org [4] https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/WDQS_backend_up… -- *Guillaume Lederrey* (he/him) Engineering Manager Wikimedia Foundation <https://wikimediafoundation.org/>

4 8

When transcluding a Special page, is the target page not available?
by Mark A. Hershberger 09 Sep '24

09 Sep '24

Hey MediaWiki devs! TL;DR: When including a SpecialPage (e.g. Special:PrefixIndex), how can the code access the Title of the page currently being rendered? I'm sure I'm missing sometthing as I track down this issue, so maybe this plea for help will result in my enlightenment. For T373259[1], I thought it would be straight-forward to get the page that is the the parser is currently including the results of a special page into. Once I had that, I thought, it would be simple to address the issue since that page could be compared to the links that are included from PrefixIndex, but it looks like the context contains the SpecialPage that is being included and not the page that its output is being included into. In my attempt to resolve the problem I was trying to solve, I refactored Special:PrefixIndex into something I could more easily digest[2]. After that, I'm left with renderRow()[3] where I used my l33t print-debug skills to fail to find any instance of the calling page--the page whose wikitext had the {{Special:PrefixIndex}} that was currently being expanded. Maybe this is all documented somewhere or maybe it is common knowledge. Perhaps it is just a limitation of the way the parser and/or transclusions works. I know I'm ignorant. Can someone please enlighten me? Thanks! Mark Footnotes: [1] https://phabricator.wikimedia.org/T373259 [2] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1069649 -- reviews welcome! [3] https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/6d33307d790… -- http://hexmode.com/ Don't ask me who's influenced me. A lion is made up of the lambs he's digested, and I've been reading all my life. -- Giorgos Seferis

3 4

Drop dedicated support for IE 11, Edge Legacy and Opera
by Volker E. 06 Sep '24

06 Sep '24

Hi everyone, the Design System Team (DST) is proposing the following changes to MediaWiki browser support [1]: - Drop support for Internet Explorer 11 (IE 11) - Drop support for all versions of Edge Legacy - Drop support for Opera - Increase Basic (Grade C) support for Chrome and Firefox to versions 49+, Safari and iOS to versions 10+. What this means: The browsers we’re phasing out won’t be tested for layout rendering anymore. While users on these browsers might and will still be able to read and basically interact with content, they might experience some quirks. This step helps us integrate modern web features more seamlessly. These changes will unlock the ability to use specific newer browser features that cannot be safely used today without requiring a fallback, notably CSS custom properties (used in upcoming reading customization features like Night Mode) and the <summary> and <details> HTML elements that can be used to replace the checkbox hack. This will reduce the amount of code sent to 99.9% of users and cut down on software development costs and maintenance burdens. See the full announcement for more details; PDF to download [2]. On behalf of the Wikimedia Foundation Design System Team, Volker [1] https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix [2] https://phabricator.wikimedia.org/F52025988

11 14

2026

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 September 2024