Hi All,
Welcome to the monthly MediaWiki Insights email!
First of all, many thanks and congratulations to Harshrathod50 and Ahecht
who got their first patch merged in MediaWiki core, extensions or services
deployed in Wikimedia production during the month of June!
As we concluded the Foundation’s fiscal year 2023/2024 on June 30, 2024,
it’s also time to share the final stats for contributions to MediaWiki core
over the past year: We’ve achieved a 25% increase in the number of authors
who have committed more than 5 patches! The overview
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Contributor_reten…>and
celebration
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Contributor_reten…>
pages now include the updated count and authors. Thank you all so much.
Project snapshots: Migration to Prometheus reaches milestone, work in
flight on REST API, and updates to Wikimedia password storage
The Observability team has completed the migration of MediaWiki core
metrics to the Prometheus-capable library StatsLib and made significant
progress overall
<https://grafana.wikimedia.org/d/nCxX65cSk/mediawiki-statslib-migration?orgI…>
(tracking task: T343020 <https://phabricator.wikimedia.org/T343020>). This
marks a key milestone on the path towards using Prometheus as the standard
metrics infrastructure in Wikimedia production. The migration to Prometheus
will continue over the next year with the goal to be able to sunset
Graphite. Many thanks to the Observability team and everyone who has helped
with this migration so far!
The MediaWiki Interfaces team has been working on improving the experience
of REST API endpoint creators and callers through multiple related
initiatives:
- Ability to specify REST modules in an OpenApi-like JSON syntax
<https://phabricator.wikimedia.org/T366837>
- Ability to define JSON schema definitions for body param validation
<https://phabricator.wikimedia.org/T362108>
- Ability to generate request body specs from param settings
<https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1017343>
- Exposing a Swagger-UI view of MW REST endpoints
<https://phabricator.wikimedia.org/T362006>
Putting all this together, REST endpoints can be specified and defined in
ways that not only support better namespacing, versioning, and parameter
validation, but which also feed directly into generation of an OpenAPI spec
which can be viewed on-wiki in an interactive sandbox. Some of this work is
still being completed – but these changes should benefit both endpoint
creators and endpoint callers. The work has been done in a
backward-compatible way, which means we've just introduced the ability to
do these things. More work remains to actually realize the benefits of
these changes. Many thanks to the MediaWiki Interfaces team and Daniel
Kinzler for driving much of the vision for this work.
The MediaWiki platform team worked on the completion of the Less.php
upgrade work for Less.js 3.0 compatibility, with the release of Less.php 5.0.
The release notes are at
https://gerrit.wikimedia.org/g/mediawiki/libs/less.php/+/v5.0.0/CHANGES.md.
Before we can enable use of new CSS "slash" features in Less.php 5.0, a few
extensions and components have to first prepare themselves. Maintainers and
contributors are invited to help with this, details are at T368921
<https://phabricator.wikimedia.org/T368921>. Many thanks to Hannah,
Dringsim, Piotr, Timo and Bartosz for their work!
More highlights from work done to improve security, ease of use,
maintainability and overall code health:
Zabe updated Wikimedia’s password storage: All passwords are now encrypted
<https://phabricator.wikimedia.org/T150647> and we use the stronger Argon2
hashing algorithm <https://phabricator.wikimedia.org/T216682> instead of
PBKDF2, which together adds an extra layer of security. A big thanks to
Zabe for this important work & to the MediaWiki platform team for code
reviews!
Rdbms library: We shared about the efforts to improve consistency, security
and ease for getting database connections and performing common queries
already in the October
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports/October_2…>
and April
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports/April_202…>
MW Insights editions. Over the past weeks, work continued on removing or
deprecating methods <https://phabricator.wikimedia.org/T363839> that are no
longer needed after the introduction of the new APIs. To date, 19 methods
have been removed, the remaining are deprecated or marked internal.
The related work to update WMF-deployed extensions to use SelectQueryBuilder
<https://phabricator.wikimedia.org/T311866> was completed in May, and the
work to migrate WMF-deployed extensions to use expression builder
<https://phabricator.wikimedia.org/T350075> made substantial progress over
the past months! A huge thanks to Amir Sarabadani for leading on this work,
Umherirrender for taking on many updates to extensions, and everyone else
who helped make this happen.
TK999 refactored redirect storage to follow modern architecture standards (
T290639 <https://phabricator.wikimedia.org/T290639>) - many thanks for
working on this :-)
Umherirrender worked on removing inline namespaces across core and
extensions over the past months (example
<https://gerrit.wikimedia.org/r/c/mediawiki/extensions/OAuth/+/1042353>) -
many thanks for this impressive long tail of work to ensure consistent
usage of namespaced classes across MediaWiki. A big shout out also to
Danny712 for supporting this effort with code reviews!
The Wikimedia *interwiki-map on Meta* was migrated from a wikitext table to
a machine-readable JSON format (T365803
<https://phabricator.wikimedia.org/T365803>). The map is now maintained as
JSON at https://meta.wikimedia.org/wiki/Interwiki_map/list, with the former
page rendering this into a table for reading convenience, powered by a
Scribunto Lua module. Many thanks to Reedy for carrying out this work, and
to Pppery and Timo for supporting it!
Last, many thanks to the Kiwix team for their work on migrating from Mobile
Content Service (MSC) to its replacement, the Page Content Service
<https://www.mediawiki.org/wiki/Page_Content_Service> (PCS). This enabled
us to set the sunset deadline for the Mobile Content Service
<https://phabricator.wikimedia.org/T328036#9930794> for the end of July,
2024.
Outlook: We just started with the new annual plan
<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/…>
(July 2024-June 2025) and will share more about this work in the upcoming
Insights email.
Thanks all for reading!
Birgit
--
Birgit Müller (she/her)
Director of Product, MediaWiki and Developer Experiences
Wikimedia Foundation <https://wikimediafoundation.org/>
I am upgrading to version 1.42.1 and am getting the following error:
...cargo_tables_template_id key doesn't exist.
Running
D:\...\extensions\OATHAuth/maintenance/updateTOTPScratchTokensToArray.php...
An error occurred:
Error 1044: Access denied for user 'db_username'@'%' to database 'virtual'
Function: Wikimedia\Rdbms\DatabaseMySQL::doSelectDomain
Query: USE `virtual`
Notes:
$wgDBuser = is _not_ in the form of an email address (xxxxx(a)yyyyyy.zzz)
db_username (above is a replacement for the actual db username).
Any ideas on how to overcome this?
-Brian
Greetings, MediaWiki users and developers!
We are now accepting contributions for the 2024 MediaWiki Users and
Developers Conference [0], which will be held April 17-19 in Portland, OR,
USA. The deadline to submit a proposal is March 22. Sign up as soon as
possible at [1].
This will primarily be an in-person conference, however we will consider
remote presentations on a case-by-case basis.The first two days of the
conference will be reserved for presentations. The third day of the
conference will be a Create Camp, which will include tutorials, hands-on
presentations, and small group hacking sessions.
The MediaWiki Users and Developers Conference, formerly EMWCon, brings
together the community that makes up MediaWiki – those who develop for
MediaWiki, those who deploy MediaWiki, and those who use MediaWiki and are
enthusiastic about the software. MediaWiki is used every day in a variety
of contexts – educational projects, corporate knowledge bases, even online
hobbyist communities – all valuing MediaWiki for its flexibility and its
openness. By meeting together we can learn from our experiences and
continue to build a true community of support for MediaWiki.
Looking forward to seeing you in Portland!
- The MediaWiki Users and Developers Conference Organizing Committee:
James Hare - Conference Chair
Cindy Cicalese - Program Chair
Bryan Hilderbrand - Registration Chair
Jeffrey Wang - Social Chair
Ike Hecht - Sponsor Chair
Ryan Schmidt - Technology Chair
[0]
https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_20…
[1]
https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_20…
Hello,
I recently configured my MediaWiki instance to pull data from a mySQL server using the External Data connector. It was a bit tricky, and I couldn’t find any existing tutorials, so I decided to create one.
https://youtu.be/4LV0X5M5Kts
This page has the step-by-step instructions: https://mshell.net/wikidemo
I hope you find this helpful!
Matt
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 28,
2024.
1.40.4 is expected to be the last release for this branch.
This means that MediaWiki 1.40 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.41, which will be
supported until December 2024, or 1.42, which will be supported until June
2025.
Thanks!
[1] https://www.mediawiki.org/wiki/Version_lifecycle
I've installed, ConfirmAccount, but what I really need is a bigger
stick: remove all occurrences of the link "Request Creation", so I
don't have to deal with the email messages associated with
ConfirmAccount. It's a Special page, so it's not something I can edit.
I expect disabling that page to be temporary. If I need to, I can
create an account as an administrator, so it's not a total loss.
Please help.
--
_______________________________________________________________
Bob Smith - bsmith(a)sudleyplace.com
http://www.sudleyplace.com - http://www.nars2000.org
Hello all,
The Code of Conduct Committee is a team of five trusted individuals (plus
five auxiliary members) with diverse affiliations responsible for general
enforcement of the Code of conduct for Wikimedia technical spaces.
Committee members are in charge of processing complaints, discussing with
the parties affected, agreeing on resolutions, and following up on their
enforcement. For more on their duties and roles, see
https://www.mediawiki.org/wiki/Code_of_Conduct/Committee.
This is a call for community members interested in volunteering for
appointment to this committee. Volunteers serving in this role should be
experienced Wikimedians or have had experience serving in a similar
position before.
The current committee is doing the selection and will research and discuss
candidates. Six weeks before the beginning of the next Committee term, they
will publish their candidate slate (a list of candidates) on-wiki. The
community can provide feedback on these candidates, via private email to
the group choosing the next Committee. The feedback period will be two
weeks. The current Committee will then either finalize the slate, or update
the candidate slate in response to concerns raised. If the candidate slate
changes, there will be another two week feedback period covering the newly
proposed members. After the selections are finalized, there will be a
training period, after which the new Committee is appointed. The current
Committee continues to serve until the feedback, selection, and training
process is complete.
If you are interested in serving on this committee or like to nominate a
candidate, please write an email to techconductcandidates AT wikimedia.org
with details of your experience on the projects, your thoughts on the code
of conduct and the committee and what you hope to bring to the role and
whether you have a preference in being auxiliary or main member of the
committee. The committee consists of five main members plus five auxiliary
members and they will serve for a year; all applications are appreciated
and will be carefully considered. The deadline for applications is *the end
of day on June 25, 2024*.
Please feel free to pass this invitation along to any users who you think
may be qualified and interested.
Best,
Amir Sarabadani, on behalf of the Code of Conduct Committee
Hi All -
Welcome to the monthly MediaWiki Insights email!
We’re beginning this edition with a big thanks to Sportzpikachu, Bill
(Wbm1058), xtex, Suffusion of Yellow, TuukkHa, theknightwho, Akiel,
Maunikashekar, DreamRimmer, Seawolf35, Likibp, NicoleLBee, SIri and Weebney who
got their first patch in MW core or Wikimedia deployed extensions and
services merged during the month of May! Congratulations :-)
Goal accomplished: 20% increase in numbers of authors who have submitted
more than 5 patches to MediaWiki core
A key goal in this years’ annual plan of the Wikimedia Foundation is
to increase
the number of authors
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Contributor_reten…>
who have committed more than 5 patches to MediaWiki core. In May 2024, we
crossed the magic bar of a 20% increase (baseline = 70, the number of
authors who have submitted more than 5 patches to MediaWiki core between
July 2022 and June 2023).
At the end of May, we were at 86 people with more than 5 patches
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Contributor_reten…>
- which is a 22.85% growth!
The push to the finish line came at the MediaWiki track
<https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2024/MediaWiki_Track>
at the Wikimedia Hackathon in Tallinn
<https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2024>. Some people
contributed to MediaWiki core for the first time, other people came back to
MediaWiki after a pause. The Wikimedia train stats show an impressive
increase of patches for the week after the hackathon (481 patches in 70
repos by 106 authors
<https://www.mediawiki.org/wiki/MediaWiki_1.43/wmf.4/Changelog> vs 318
patches in 76 repos by 75 authors
<https://www.mediawiki.org/wiki/MediaWiki_1.43/wmf.3/Changelog> in the week
before the Hackathon), and about 200 out of the 481 patches were for
MediaWiki core alone. Deep appreciation for Jeena Huneidi, who was the train
conductor
<https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/Roles#Tra…>
that week! You can learn more about the MediaWiki work done during the
Hackathon under the corresponding Phabricator project
<https://phabricator.wikimedia.org/project/profile/7117/>.
We also continued to observe an impressive decrease in median (>30%) and
average time to first review data (>50%), and an increase in the number of
patches to MediaWiki core compared to last fiscal year. All of these data
points
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Contributor_reten…>
are the best that we have had in years and are strong indicators that our
development process around MediaWiki is improving.
The health of our platform relies on our ability to maintain the platform,
and a key part of that is to share knowledge and enable people in making
improvements to the core software.
A big thanks to all the people who contribute to MediaWiki core and invest
time in code review and consultancy! Turning the curve around from a
decrease to an increase for the first time in years is such a great
success, which was only possible thanks to all of you
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Contributor_reten…>.
<3
MediaWiki as a product: Reflections and questions
As shared in the previous MediaWiki Insights
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports/April_2024>
email, we wanted to come back with some reflections and insights on the
direction of MediaWiki after the presentations given at the Wikimedia
Hackathon
<https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2024/Program#Saturday,_4…!>
in May and the MediaWiki users and developers conference
<https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_Sp…>
in April. To get more information, you can go over the slides
<https://commons.wikimedia.org/wiki/File:MediaWiki_product_-_direction_and_p…>
as well as the notes in this ticket
<https://phabricator.wikimedia.org/T363972>.
The MediaWiki product strategy is anchored in the larger strategy of the
Wikimedia Foundation
<https://diff.wikimedia.org/2024/04/12/wikimedia-foundation-draft-annual-pla…>,
which is all about the question of how we can sustain the success of the
Wikimedia projects into the future – while the Internet around us is
changing.
MediaWiki, the software platform and interface that allows Wikipedia and
other projects to function, is at the heart of that question. What
decisions and platform improvements can we make to ensure that the
MediaWiki platform is sustainable and can support the creation, moderation,
storage, discovery, and consumption of open, multilingual content at scale
for the next decade?
This means, for example: the platform needs to scale for very high global
read traffic (billions of page views/month) and high global edit traffic
(millions of edits/month), which may coincide and spike when there is a current
event <https://en.wikipedia.org/wiki/Template:Current>. It means the
platform needs to support a large contributor base and the creation,
moderation and discovery of open content in more than 300 languages –
content is not only text, but also data, images, or compositions of
different types of content. Last, the platform needs to enable teams and
technical contributors in a way that we can balance platform and feature
needs, and in a way that the customization offering is curated and thus
manageable and useful to its users. The use cases and scale of Wikipedia
<https://commons.wikimedia.org/w/index.php?title=File%3AMediaWiki_product_-_…>
guide the design goal and platform mission.
Manual:What is MediaWiki?
<https://www.mediawiki.org/wiki/Manual:What_is_MediaWiki%3F> describes some
of that well: MediaWiki has been built to support and scale for Wikipedia’s
needs and use cases (and then all the Wikimedia projects) and decisions are
made with that in mind. The flip-side of this is that there are things
MediaWiki does not do so well - because it’s not designed for those. One
thing we need to get better at is providing clarity about that to users –
so that people can make informed decisions whether the software is right
for their use case. The release cycles and related communication present an
opportunity to do so. And one thing we need to ask ourselves is what our
core software architecture should look like and what core concepts the
platform needs to support inherently to effectively serve as the knowledge
production platform for Wikipedia’s scale and use cases. What can we learn
from the use cases served through the extension ecosystem? Are there
patterns in what people have tried to enable? Which of those patterns may
be something we should enable differently, and what may not be in scope?
The magnitude of the challenges we’re tackling is huge. We started this
journey by learning about people's experiences, challenges and hopes
<https://commons.wikimedia.org/w/index.php?title=File:MediaWiki_product_-_di…>,
and continue to talk and learn. Explorations around questions such as how
Wikipedia’s essential workflows are currently supported
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Artifacts/Unravel…>
through the MediaWiki software ecosystem, or what is our understanding of
the purpose of each of the mechanisms available to customize MediaWiki
<https://commons.wikimedia.org/wiki/File:MW_customization_interfaces_-_Prope…>
have likewise helped us gain a better sense for challenges and
opportunities of the platform. Last, it has been insightful to go back in
time and reflect on how it all started (and whether and how we lost focus
and track).
Turning lessons learned into actions
A key early decision has been to set a focus on platform sustainability: We
invested in contributor retention and growth
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Contributor_reten…>,
allocated a product manager focused on sustainability (Mateus Santos),
prioritized work on several multi-year initiatives
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports/February_…>
that are critical for platform sustainability and evolution, designed
sustainability goals for the Foundation’s next annual plan (Wiki
Experiences key results 5.1 and 5.4
<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/…>),
and are currently preparing for the handover of the release responsibility
to MediaWiki Engineering. There is a deep correlation between platform
sustainability and release cycles, and an opportunity to align better with
other infrastructure management tasks (e.g. PHP upgrades) and product
strategy.
As we’re making this transition, it is also time to “release” James
Forrester and Sam Reed from the release responsibility: A big shoutout to
James and Sam for all the work they have done around the releases over the
past years and many thanks for all their support, kindness and knowledge
transfer as they are handing things over! <3 The security releases will
continue to be handled by the Security team.
Building on the research from this year, we also plan to start exploring
how we can clarify the relationship of core and extensions better, what
should exist (or not) within core, extensions, or the interfaces between
them, and how that may translate into architectural needs and decisions.
This in itself is a big question and scope, so we’re trying to approach it
with small steps – and conduct more research and experiments first (KR
5.2).
As part of KR 5.3, we want to leverage Parsoid's capabilities which
implicitly models a page as a composition of well-structured fragments. We
aim to use this capability to derive speedy HTML updates on edits to
templates and pages, as well as unblock WikiFunctions' integration on wikis
whose page renderings are served by Parsoid.
Getting ready for next year’s work: A database to query dependencies in
MediaWiki and an overview on MediaWiki’s customisation interfaces
In an earlier MW Insights email
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports/January_2…>,
we talked about our work to explore how the MediaWiki software ecosystem
currently supports essential workflows on Wikipedia and Wikidata. While
we’re still working on another report about this exploration, we want to
share two other pieces of work that we believe to be very helpful for the
MediaWiki goals under the Foundation’s annual plan 2024/2025 (WE5.1-5.4)
<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/…>
:
Amir Sarabadani surprised us with a wonderful project at the Wikimedia
Hackathon: Huma – a bird’s eye view of MediaWiki is a postgreSQL database
that allows querying dependencies and usage of certain methods in
MediaWiki. Want to know which are the most implemented hooks in MediaWiki?
- ask Huma. Interested in cycle dependencies? - ask Huma. You can find more
information on the project on this page
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Artifacts/Huma:_B…>
.
MediaWiki’s customisation interfaces: Earlier this year, we started talking
about all the different ways that users can build software on top of
MediaWiki, and which technique is best suited for what purpose - from
templates to Toolforge and from extensions to gadgets. We tried to capture
our thoughts with sticky notes and arrows on the wall, to create a “feature
development map”. Daniel Kinzler then picked up the ball and started a
spreadsheet with all the interfaces we have for customization and
automation, and the capabilities and properties each of them offers. After
many improvements by engineers and product managers from MediaWiki
Engineering, we now have a concise chart that can serve as an overview of
the different customization mechanisms, and provide guidance on the
advantages and disadvantages of each approach. The chart is available as a
PDF on Commons
<https://commons.wikimedia.org/wiki/File:MW_customization_interfaces_-_Prope…>,
and as a spreadsheet on Google Drive
<https://docs.google.com/spreadsheets/d/10sUXrXylT8dlUcBgSJLlgutjqqA1llUh3UK…>
.
My apologies for the length of this email – there was a lot to share this
time! And please join me in thanking all the wonderful contributors and
code reviewers in MediaWiki core! :-)
Thanks all for reading!
Birgit
--
Birgit Müller (she/her)
Director of Product, MediaWiki and Developer Experiences
Wikimedia Foundation <https://wikimediafoundation.org/>