Hi all,
On Thursday we will be issuing a security and maintenance release to all
supported branches of MediaWiki.
The new releases will be:
- 1.39.7
- 1.40.3
- 1.41.1
This will resolve two security issues in MediaWiki core, along with bug
fixes included for maintenance reasons. This includes various patches for
PHP 8.0, 8.1, 8.2 and 8.3 support.
This release may or may not be made with a CVE number formally attached,
due to the recent delays in receiving them from MITRE.
We will make the fixes available in the respective release branches and
master in git. Tarballs will be available for the above mentioned point
releases as well.
A summary of some of the security fixes that have gone into non-bundled
MediaWiki extensions will also follow later.
As a reminder, MediaWiki 1.35 became end of life (EOL) in December 2023.
It is strongly recommended to upgrade to either 1.39 (the next LTS after
1.35), which will be supported until November 2025, 1.40, which will be
supported until June 2024, or 1.41, which will be supported until December
2024.
[1] https://www.mediawiki.org/wiki/Version_lifecycle
Dear Wikimedians,
We hope this message finds you well and that you are in good spirits. We
are the Let’s Connect working group
<https://meta.wikimedia.org/wiki/Grants:Knowledge_Sharing/Connect/Team>- a
team of movement contributors/organizers who are liaison representatives of 7/8
regions <https://meta.wikimedia.org/wiki/Wikimedia_regions>. We are
connecting with you to see if you are interested in and/or know about the
peer-to-peer program, Let’s Connect
<https://meta.wikimedia.org/wiki/Grants:Knowledge_Sharing/Connect>!
The program creates an open and safe learning space for any Wikimedian who is
part of an organized group to share and learn different skills
(organizational/interpersonal / grant related / learning & evaluation ...)
with other peers to add value and contribute collectively to the community.
The purpose is to further develop skills, share knowledge and promote human
connections and mutual support between different groups and communities, in
alignment with the Movement Strategy
<https://meta.wikimedia.org/wiki/Movement_Strategy>.
Every month, we host 2-3 live 2-hour learning clinics
<https://meta.wikimedia.org/wiki/Grants:Knowledge_Sharing/Connect#Live_learn…>
with
interesting topics selected by our team and our interested sharers. Our
live learning sessions have up to 4 interpreters translating the clinic for
our participants. Our main languages are Spanish | Arabic | French |
Portuguese. If there is a specific language you would like to see in the
calls, we are happy to see how we can accommodate it.
Let’s Connect is directed at Wikimedians in all regions that are part of
organized groups (this can range from a group of individuals that are not
formally organized user groups, chapters and mission-aligned
organizations). Please see our Meta page for more criteria
<https://meta.wikimedia.org/wiki/Grants:Knowledge_Sharing/Connect#Who_is_Let…>.
To participate as a sharer, you can register in this initial registration
form
<https://docs.google.com/forms/d/e/1FAIpQLSdiea87tSYmB2-1XHn_u8RLe7efMJifJBz…>
where
you can register your learning and sharing interests and state if you want
to share your knowledge through Learning Clinics.
Below, you will find our team of 8 who are excited to meet with you if you
are interested. Please email our team at letsconnect(a)wikimedia.org if you
have any questions :)
We look forward to hearing from you.
Best,
The Let’s Connect Working Group
Hi All, welcome to the monthly MediaWiki Insights email!
Like last time
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports/January_2…>,
we’re starting this email by celebrating volunteer contributors who got
their first patch merged in MW core, WMF deployed extensions or services
over the past month:
A big thanks to GergesShamon and Agent Isai for their contributions!
Welcome :-)
Many thanks also to the reviewers - volunteers and staff - of patches by
new contributors. Your support is invaluable for helping people contribute
to MediaWiki effectively and make it a fun first experience!
The focus of this edition of the monthly MW Insights email lies on our
multi-year initiatives: Migration of MediaWiki from bare metal to Kubernetes
<https://wikitech.wikimedia.org/wiki/MediaWiki_On_Kubernetes> in Wikimedia
Production, Parser Unification
<https://www.mediawiki.org/wiki/Parsoid/Parser_Unification> and RESTBase
deprecation <https://phabricator.wikimedia.org/project/profile/6289/>.
These initiatives involve many people and projects, require orchestrated
efforts and coordination, and will help us in many different ways. Another
thing that these initiatives have in common is that we’re getting closer to
being able to benefit from these efforts :-).
Project Snapshots: Milestones reached on 3 multi-year projects
MediaWiki on Kubernetes migration is 75% complete, completing migration of
all internal traffic, all scheduled jobs and reaches 50% global traffic
milestone!
Often shortened as mw-on-k8s, MediaWiki on Kubernetes is a multi-year
effort to move all of the MediaWiki deployments running on WMF production
infrastructure to the new WikiKube platform.
The migration is underway and very recently a new milestone was hit where
the WikiKube platform now serves 50% of end user requests
<https://phabricator.wikimedia.org/T290536>. At half mark, having more
percentage of traffic on WikiKube, Service Operations is working with
Release Engineering to make changes to monitoring tools to surface any
issues during deployments to continue with further ramps. Also, almost the
entirety of what is called internal traffic
<https://phabricator.wikimedia.org/T333120>, that is traffic that is
generated by applications running in the infrastructure and reaching out to
MediaWiki for various purposes is migrated to WikiKube. A special mention
should go to MediaWiki Jobs fully migrated just a week ago
<https://phabricator.wikimedia.org/T349796>. Feel free to follow the higher
umbrella task <https://phabricator.wikimedia.org/T290536> and/or
MediaWiki_On_Kubernetes
on Wikitech <https://wikitech.wikimedia.org/wiki/MediaWiki_On_Kubernetes>.
This migration will unleash the ability to deploy multiple versions of code
simultaneously. Also, this will help enhance platform capabilities to build
dockerized isolated environments for coding, testing and even production
debugging.
MediaWiki on Kubernetes will allow us to deprecate and eventually remove a
lot of our in-house developed code. Another benefit is that we will be able
to react to sudden traffic spikes, like newsworthy events better, as the
flexing up and down is a matter of configuration change. This enables
efficient placement of workloads, packing workloads in a more
environmentally friendly way, increasing hardware utilization.
It takes a village to get this far: A big thanks to the Service Operations
team (Clément Goubert, Giuseppe Lavagetto, Alexandros Kosiaris, Kamila
Součková, Hugh Nowlan, Effie Mouzeli, Reuven Lazarus, Jannis Mayboom and
Kavitha Appakayala) for their leadership on this project, the Release
Engineering team (specifically: Dan Duvall, Jeena Huneidi, Tyler Cipriani
and Ahmon Dancy) for their work on Blubber
<https://wikitech.wikimedia.org/wiki/Blubber>, the Deployment Pipeline
<https://wikitech.wikimedia.org/wiki/Deployment_pipeline> and Scap
<https://wikitech.wikimedia.org/wiki/Scap>, Dom Walden from Quality and
Test Engineering for crafting and executing a plan to test the first
deployment of MediaWiki on Kubernetes, and everyone else who has
contributed in the one way or the other! <3
More milestones:
We’re seeing the first lights at the end of the tunnel of another
multi-year initiative: The *parser unification*
<https://www.mediawiki.org/wiki/Parsoid/Parser_Unification>. One week
ago, Parsoid
Read Views was rolled out to first wikis: Parsoid is now the default read
views renderer on the Foundations’ Office Wiki and Wikitech
DiscussionTools. This early experimentation allows us to find issues in a
limited space, which will help us evaluate readiness of the feature
and increase
our confidence for future rollouts
<http://mediawiki.org/wiki/Parsoid/Parser_Unification/Confidence_Framework>.
A huge thanks to Subbu Sastry, Mateus Santos, CScott, Isabelle
Hubert-Pallatin, Arlo Breault, Shannon Bailey, Yiannis Giannelos and Sérgio
Lopes for making this work! Many thanks also to Daniel Kinzler: His work on
the RESTBase deprecation directly helped us get to this milestone :-)
*RESTBase deprecation*: We have been continuously working on decoupling
services from RESTBase, aiming for the modernisation and sustainability of
Wikimedia products in our services platform. The MediaWiki Interfaces team
finished up reimplementation of Reading Lists endpoints in MW REST API
<https://phabricator.wikimedia.org/T348491> and are now confirming with
affected callers <https://phabricator.wikimedia.org/T357478> that the new
endpoints meet their needs before rerouting calls
<https://phabricator.wikimedia.org/T348493> and retiring old code
<https://phabricator.wikimedia.org/T348494>. The overall effort
<https://phabricator.wikimedia.org/T336693> will not only move us forward
on RESTBase retirement, but also reduce the total amount of code we have to
maintain. Many thanks to Bill Pirkle, Atieno Njira, Wendy Quarshie, and
Daniel Kinzler for making this work! We also fully turned off Parsoid cache
storage in RESTBase - clients will get outputs direct from MediaWiki and
the cache will be handled by ParserCache. Next, we will re-route clients
directly to MediaWiki and fully remove Parsoid from RESTBase (T344944
<https://phabricator.wikimedia.org/T344944>). The Page Content Service
(PCS) will also handle its own cache
<https://phabricator.wikimedia.org/T348995> and we are ready to test the
new capabilities in staging soon. Many thanks to Yiannis Giannelos and the
Content Transform team and to Daniel Kinzler for his efforts and support on
decoupling Parsoid from RESTBase!
All of these multi-year initiatives help us increase sustainability and
maintainability of the platform, streamline engineering and developer
workflows, and unlock the path for new and improved platform capabilities
and product opportunities.
Outlook: Knowledge Platform in the annual plan 2024/2025
The Wikimedia Foundation has recently published the draft objectives by the
Product & Technology department
<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/…>
for the next annual plan on Meta, alongside an introduction by Selena
Deckelmann and a few questions that we’re exploring
<https://meta.wikimedia.org/wiki/Talk:Wikimedia_Foundation_Annual_Plan/2024-…>.
Your input on these questions is very welcome!
The draft objectives include “Knowledge Platform I” - centered around
MediaWiki platform evolution and “Knowledge Platform II” - centered around
developer/engineering services and workflows. The objectives show only the
high-level direction for next year. The draft “key results” (currently work
in progress) will give a better idea of what areas of work we’re thinking
about. We’ll be publishing these in March and share the link + invitation
for feedback with this list again.
Thanks all for reading,
Birgit
--
Birgit Müller (she/her)
Director of Product, MediaWiki and Developer Experiences
Wikimedia Foundation <https://wikimediafoundation.org/>
I'm looking for help getting Semantic Mediawiki ImportData to work in MediaWiki 1.39.5, SemanticMedia 4.1.3
My CSV job starts successfully, but then I get an error in runJobs.php
"Error: Call to undefined method WikiPage::doEditContent()"
We are pleased to announce the first MediaWiki Users and Developers Conference [0], the successor to EMWCon.
The conference will be held in Portland, Oregon, from April 17–19 at the Jupiter NEXT Hotel [1].
The MediaWiki Users and Developers Conference 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.
Registration is open now. [2] Register soon to take advantage of the early bird discount!
See the conference page for local accommodations. [3] Everyone who is attending is encouraged to stay at either of these hotels, where we have negotiated group rates.
If you have ideas for the program, add them to the wiki page. [4] While this will primarily be an in-person conference, we will consider remote presentations on a case-by-case basis.
Looking forward to seeing you in Portland!
Best regards,
the MediaWiki Users and Developers Conference Organizing Team
[0] https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_20…
[1] https://www.jupiterhotel.com/the-next
[2] https://www.eventbrite.com/e/mediawiki-users-and-developers-conference-spri…
[3] https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_20…
[4] https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_20…
Hi All,
Happy 2024 and welcome to the monthly MediaWiki Insights email!
We’re starting this year with celebrating contributors who got their first
patch merged in MW core, WMF deployed extensions or services in the months
of December and January:
A big thanks to Doğu Abaris, apasternak, Abador, Mehdi Zidani,
Oudedutchman, Cyn, Dominic mayers, and Houseblaster for their
contributions! Welcome :-)
Enable more people to know MediaWiki and contribute effectively
As shared in the previous MW insights email
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports/November_…>,
we have been thinking about ways to improve first time MediaWiki (core)
contributors’ experience. One key part of that is knowing who is new to be
able to say hi (and thank you). Bartosz created a script
<https://gitlab.wikimedia.org/matmarex/gerrit-new-contributors/-/blob/master…>
to find new MediaWiki contributors for a given month that got their first
patch merged (see above!). Another key part is code review for patches
submitted by (new) volunteer contributors. We’re currently thinking about
how we could organize code review for volunteer-submitted patches better
across MediaWiki Engineering and want to give a shared MW-Engineering
Gerrit dashboard a try, with primary focus on the components the group is
responsible for.
We ran a WMF-internal MediaWiki CodeJam event
<https://www.mediawiki.org/wiki/MediaWiki_Code_Jam#Results> in December,
with 54 participants (16 from the MW team) and 21 Phabricator tickets
completed. Areas of improvement included MediaWiki itself and multiple
essential extensions. See the project page for details!
Two notable “side projects” of the CodeJam: To support new contributors,
Timo has created a series of tutorials
<https://www.mediawiki.org/wiki/User:Krinkle/MediaWiki_Introduction_2023>
going over core MediaWiki concepts. The videos are also available on
youtube (part I: MediaWiki core concepts
<https://www.youtube.com/watch?v=-JnIjpRvgNY>, part II: Wikipedia’s
extensions <https://www.youtube.com/watch?v=4xYbqbabTwI>).
A "Quick" MW install
<https://www.mediawiki.org/wiki/Local_development_quickstart> was created
to make it possible to install MediaWiki in 3 steps and under 5 minutes.
See this ticket for the evaluation
<https://phabricator.wikimedia.org/T348899> on how this worked out for
testers during code jam. Thanks to Alex Paskulin, Timo Tijhof and Kosta
Harlan for their work <3
The materials as well as lessons learned from this first MW code jam will
help us run a second edition for everyone who’s interested, possibly ahead
of, and at the Wikimedia Hackathon
<https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2024>.
Project snapshot: Virtual domains, great namespaceisation, and first MW
Engineering cross-sub-team quarterly planning
We finalized the Q3 plan (= Jan-March) for MediaWiki Engineering in early
January. This is the first time where we applied a “cross-sub-team”
planning approach across MediaWiki Engineering & engaged as a group on
gathering proposals and then prioritized these. A few examples for high
priority work:
- Evolve central login to meet requirements of a changing environment
(“SUL3”): T348388 <https://phabricator.wikimedia.org/T348388>
- Support upgrade of WMF production from PHP 7.4 to 8.1: T319432
<https://phabricator.wikimedia.org/T319432>
- Continue work to move off RESTBase
<https://phabricator.wikimedia.org/project/profile/6289/>
- Continue work on exploring how essential workflows on the Wikimedia
projects are currently supported through the MediaWiki software ecosystem
(see below)
- Prepare MW-platform team owned components
<https://phabricator.wikimedia.org/T355377> for compatibility with the
upcoming Temporary Accounts for Unregistered Editors
<https://www.mediawiki.org/wiki/Help:Temporary_accounts> project.
We’ve already checked the box on preparing auth components
<https://phabricator.wikimedia.org/T326925> (OATHAuth and WebAuthn) for
compatibility - many thanks to Piotr and Gergö for their work on this!
Other highlights:
- We’ve made progress towards supporting Less 3.13
<https://phabricator.wikimedia.org/T288498> behavior: A series of bugs
were fixed in Less v2.5.3 to pave the way to enable new Less.js
capabilities to be used in the frontend.
- The Content Transform team has moved functionality out of Parsoid and
into Cite extension <https://phabricator.wikimedia.org/T354215>, which
allows both Parsoid and the default parser to use the same underlying
functionality and reduce maintenance burdens.
- To support SRE’s work, MediaWiki metrics were migrated from Graphite
to Prometheus. This is an ongoing effort with more upcoming work.
- Cleanup continued in dropping deprecated unused config variables
<https://phabricator.wikimedia.org/T166010> (also known as the great
namespaceisation effort).
- Virtual domains are now working well in MediaWiki core
<https://phabricator.wikimedia.org/T353948> and are supported in the
updater and installer.
- A minor task was to update the JavaScript syntax checker for gadgets
and user scripts for ES6 and ES7
<https://phabricator.wikimedia.org/T75714>.
- Database: Amir Sarabadani presented
<https://commons.wikimedia.org/wiki/File:Major_changes_to_MediaWiki%27s_rdbm…>
about changes done to the RDBMS library at SMW Con (video available
<https://www.youtube.com/watch?v=q0mjNEJP5Fo>). DBAccessObjectUtils is being
redesigned <https://phabricator.wikimedia.org/T354194>, including major
deprecation of indirect calls to IDBAccessObject constants.
How essential workflows are served through the MediaWiki software ecosystem
As part of developing a product strategy for MediaWiki, one research
question is how the MediaWiki software ecosystem currently supports
essential workflows on the Wikimedia projects. We also wanted to understand
commonalities and differences in how these workflows and use cases are
supported on different wikis - for example, Wikipedia A vs Wikipedia B,
Wikipedia A vs Wikidata, or Wikipedia A vs translatewiki.net - etc.
Moriel has been leading this work, in collaboration with many engineers
across different areas of expertise. A first outcome has now been
published: Unraveling Complexity: Mapping MediaWiki Software Components
into User-Driven Workflows
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Artifacts/Unravel…>
The next outcome is already in the making, with focus on exploring how
specific use cases are supported (differently) on 3 different Wikimedia
projects. The goal is to identify where conceptual behaviors diverge and
converge between the wikis, pinpointing base and common behaviors versus
those unique to specific cases. This brings us in the interesting fields of
software behavior on use cases such as: “An unregistered (not yet
temporary) user edits existing wikitext content (fixing typo) on desktop.”
Read the write-up above to learn more about why, and stay tuned for the
next outcome of this exploration, which will talk through some of the
findings in this multi-wiki modeling approach.
Thanks all for reading!
Birgit
--
Birgit Müller (she/her)
Director of Product, MediaWiki and Developer Experiences
Wikimedia Foundation <https://wikimediafoundation.org/>
Hi.
I am an operator of a small wiki. The log of the wiki is not preserved currently.
The wiki is running on a container which is on a Hashicorp Nomad node. You can assume it as just a docker container.
For a monetary reason, I want to use a free plan of a logging stack cloud service, for example Grafana Loki or OpenObserve.
I set up the mediawiki used monolog so that logs flowed to stdout, and let Vector[1] agent on a machine collected it and sent to the OpenObserve cloud. I wanted logs are not stored in the storage, because I did not want logrotate.d.
But for some reason, storage became closely full, I've disabled the whole logging system. I've not inspected it.
Before re-enable the logging system or inspect it, I hope to know how people deploy the log system. If you have some experience, please reply to this or review my approach.
Regards.
1: https://vector.dev/
Hello,
For many years, some classes in MediaWiki implemented the IDBAccessObject
interface (which only provides several public constants) and then would
call them indirectly (e.g. self::READ_NORMAL). Since these constants were
public, other parts of MediaWiki started to call them through the
implementing class as well (e.g. calling User::READ_LATEST).
This is inconsistent with the access pattern of other constants in
MediaWiki. it's also confusing (e.g. it's unclear to a newcomer why
UserFactory is implementing IDBAccessObject) and it's prone to clashes
(e.g. BagOStuff class has a clashing constant).
Since it's not possible to trigger a deprecation warning in such cases, It
can't follow the usual stable interface policy path [1] and here is the
email to wikitech-l as required by the policy.
In three weeks we will remove indirect access to these constants by
removing IDBAccessObject from implementation. This will take effect from
1.42 release.
Classes that won't have those constants anymore are including but not
limited to:
* User
* WikiPage (and its subclasses)
* File (and its subclasses)
* Title
* ActorStore
* RevisionStore
* UserOptionsManager
* And more.
To find such cases in extensions you maintain, you can search for
"(?<!IDBAccessObject)::READ_" (regex) and check if the constant being used
is an indirect call to IDBAccessObject. Be careful that there might be some
false positives such as custom defined constants, constants referring to
BagOStuff ones and similar cases like that.
We have already removed all cases in core and extensions deployed to
Wikimedia production.
You can follow the work and see examples of how the migration is done in
extensions (for example gerrit:993112
<https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Echo/+/993112>) in
T354194 <https://phabricator.wikimedia.org/T354194>.
[1] From the policy
<https://www.mediawiki.org/wiki/Stable_interface_policy#Hard_deprecation>:
"If it is not reasonably possible for the deprecated code to emit
deprecation warnings, hard deprecation can be applied by announcing the
removal on wikitech-l in a timely manner."
Thank you and sorry for the inconvenience,
--
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation <https://wikimediafoundation.org/>