MediaWiki-l September 2024

mediawiki-l@lists.wikimedia.org

7 participants
6 discussions

New Code of Conduct Committee members
by Amir Sarabadani 14 Oct '24

14 Oct '24

Hello everyone, The Committee has finished selecting its new members. The new committee candidates are (in alphabetical order): - Amir Sarabadani - Egbe Eugene Agbor (Eugene233) - Greg Grossmeier - Jayprakash12345 - Kamila Součková Auxiliary members will be (alphabetically): - Effie Mouzeli - Joris Darlington Quarshie - Martin Urbanec - MusikAnimal - SD0001 You can read more information about the members at [1]. List of changes from the last term: - Greg and Kamila will be joining the main committee. - Nuria is leaving the main committee - MusikAnimal is moving to the aux committee - Tony is leaving the aux committee This is not the final structure. According to the CoC [2], the current committee publishes the new members and calls for public feedback for *six weeks* and after that, the current committee might apply changes to the structure based on public feedback. Please let the committee know (via techconduct(a)wikimedia.org) if you have any concern regarding the members and its structure until *08 October 2024* and after that, the new committee will be in effect and will serve for a year. [1] https://www.mediawiki.org/wiki/Code_of_Conduct/Committee/Members/Candidates [2] https://www.mediawiki.org/wiki/Code_of_Conduct/Committee#Selection_of_new_m… -- Amir (he/him)

1 1

Security and maintenance release: 1.39.9 / 1.41.3 / 1.42.2
by Sam Reed 01 Oct '24

01 Oct '24

1 0

Mediawiki Caching and Performance Improvemnts
by dileep.paladugu＠hallowelt.com 24 Sep '24

24 Sep '24

I'm new to MediaWiki and currently exploring caching strategies to improve the performance of my wiki setup. Specifically, I have a scenario where MediaWiki is deployed in Kubernetes with multiple replicas running simultaneously. I would appreciate any insights or best practices for managing caching in this environment, especially when it comes to the localization (L10N) cache. I have a few specific questions: 1. Apart from upgrades and extension changes, are there any other scenarios where the localization cache changes? 2. Is it possible for multiple MediaWiki instances (with the same codebase) to share a common L10N cache? 3. What are the recommended strategies for handling caching in a multiple replica setup? Thank you in advance for your help!

2 1

Newbie question: MediaWiki Paywall?
by Maureen Mead 23 Sep '24

23 Sep '24

Hello, I have been working for years with a client that has a huge Wiki on the Internet, used primarily as a journalist’s research tool that eventually feeds books they write. I am a total newbie to MediaWiki/WikiMedia. . .and in the past when the client has needed the site moved or updated, I’ve rustled up a colleague to do it. Now they are toying with the idea of a paywall. Perhaps some parts of the site would be visible. A few pages of the day as a teaser, etc. But they’d like to have a membership/paywall a visitor must join to access the pages. And since they are completely non-technical, the simplest, but more importantly, most SECURE is the driving force. I’ve been poking around web-searching, discovered that using MediaWiki to block pages using “access control" is unadvisable. https://www.mediawiki.org/wiki/Extension:AccessControl Again, not recommended: https://stackoverflow.com/questions/619036/mediawiki-payment-gateway MediaWiki payment gateway stackoverflow.com I’ve seen suggestions of setting up either a Bootstrap html/css page that handles the PayWall—and putting the Wiki in a subdomain and pointing the access to that. I have not tested it. ?--A Wordpress site with the Wiki in a subdomain? There are several membership plugins with Wordpress that I’m familiar with. ?—A Bootstrap or React page and the Wiki Site in a subdomain? And while I’m always up to learn new things—my experience is as a designer/visual creative with a bent for the web—I know my limitations. I’m looking for some advice from the MediaWiki community to see what way is best, most secure, and easiest to maintain. Also, as a sidebar: I’m a neophyte with upgrading. They are needing it and they are on version 1.34.5 I’m worried that if they wait too long to upgrade it will be a monster, as explained by a friend who did the upgrade and said there were so many things that had to be replaced and alternates selected. Thank you SO much for your time, experience, and advice, Maureen Mead / South Sound Washington State mmeadpond(a)icloud.com <mailto:mmeadpond@icloud.com>

2 1

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

MediaWiki Users and Developers Conference : Call for Participation and Contributions
by Bernhard Krabina, KM-A 05 Sep '24

05 Sep '24

Dear MediaWiki Community, the MediaWiki Users and Developers Conference Fall 2024 will be held in Vienna, Austria, from November 4-6. https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_Fa… Important dates: ** September 15: Call for contribution ends! ** Please be quick if you want to present! Proposals can be submitted here: https://www.semantic-mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conf… ** September 30: Early bird deadline ends! ** Registration is open: https://mwstake.eventbrite.com/ You need to register in order to participate in Vienna. We have a limited capacity of 80 seats, so be quick and use the early bird rates! ** Sponsorship ** We thank our sponsors * Blue Spice MediaWiki: https://bluespice.com/ * WikiTeq: https://www.wikiteq.com/ as well as Professioinal Wiki https://professional.wiki/ and Wikibase solutions: https://wikibase-solutions.com/ If you are interested in sponsoring, please contact us. Hope to see you in Vienna! Bernhard Krabina, General chair, bernhard.krabina(a)km-a.net<mailto:bernhard.krabina@km-a.net> Sabine Melnicki, Program chair, sabine.melnicki(a)km-a.net<mailto:sabine.melnicki@km-a.net>

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

MediaWiki-l September 2024