Hi all,
at the end of last week we released OOUI v0.52.0.
It will roll out on the normal train tomorrow, Tuesday, 17 June 2025.
This release contains several breaking changes and highlights since v0.51.0:
Breaking changes:
- We dropped support for PHP < 8.1
- Custom OOUI\Exception class was removed entirely. Rely on the
default exception handler instead.
- Dialog: Remove Dialog.static.escapable
- SelectFileInputWidget: Remove alias for SelectFileWidget.
SelectFileWidget got superseded by SelectFileInputWidget with dropped
IE11 support a while back.
Additionally
- OOUI is now fully supporting dark mode with a number of fixes in
different widgets, most complex fix provided to DropdownInputWidget
- DropdownInputWidget also received a fix for missing accessibility
labels on mobile
- And PopupToolGroup won't close anymore if the scrollbar is used
Thanks to Func, Taavi Väänänen, Zoë, Umherirrender and
SomeRandomDeveloper for their volunteer contributions since the last
minor release.
You can find details on additional new features, code-level, styling
and interaction design amendments, and all improvements since v0.51.0
in the full changelog[0].
If you have any further queries or need help dealing with breaking
changes, please let me know.
As always, interactive demos[1] and library documentation is available
on mediawiki.org[2], there is comprehensive generated code-level
documentation and interactive demos and tutorials hosted on
doc.wikimedia.org[3].
OOUI version: 0.52.0
MediaWiki version: 1.45.0-wmf.6
Date of deployment to production: Regular train, starting Tuesday 17 June
[0] - https://gerrit.wikimedia.org/g/oojs/ui/+/v0.52.0/History.md
[1] - https://doc.wikimedia.org/oojs-ui/master/demos/#widgets-mediawiki-vector-ltr
[2] - https://www.mediawiki.org/wiki/OOUI
[3] - https://doc.wikimedia.org/oojs-ui/master/
Best,
Volker
Hey all,
I'd like to highlight that, as of yesterday, MediaWiki code (and much more) no
longer supports PHP 7.4 in its development branch.
MediaWiki already stopped officially supporting PHP 7.4 back in the MediaWiki
1.42 release a year ago[0] following the support policy for PHP[1], but as
Wikimedia production was still running on 7.4, the development branches for
most things continued to be tested with 7.4. As of this week, Wikimedia SRE
completed the removal of the last traced use of PHP 7.4[2], and so we were
able to decommission CI support[3] and land the official support change[4]
from April 2024[5].
In practice, this should have no effect on anyone running a current or recent
MediaWiki installation. People still running old versions of MediaWiki on PHP
7.4 or PHP 8.0 will have to upgrade their (out-of-support[6]) PHP version
when they next upgrade MediaWiki, which we encourage. The only supported
version of MediaWiki that can be run on PHP before 8.1.0 is MediaWiki 1.39,
which goes end-of-life in six months' time, November 2025.
Developers will have to support fewer quirks and issues, and we can unwind some
unnecessary scaffolding, oddities where features had to be adjusted in release
branches. Most importantly, we will be unblocked in several areas where
upstream libraries and tools had long-ago stopped supporting PHP 7.4.
As part of this, Wikimedia CI for MediaWiki itself, as well as all extensions,
skins, libraries, and tools has been adjusted to test PHP 8.1–8.3 (or as
appropriate). Wikimedia CI no longer has the facility to test in PHP 7.4. Work
to support PHP 8.4 continues, and for those interested, there is a Phabricator
board to track known issues[7].
This has been a long time coming, and I want to thank the very large number of
people at Wikimedia across the MediaWiki group, SRE, and product teams, as well
as many volunteers & others in the developer community, for their perseverance
to get us to this point.
[0] - <https://www.mediawiki.org/wiki/Compatibility>
[1] - <https://www.mediawiki.org/wiki/Support_policy_for_PHP>
[2] - <https://phabricator.wikimedia.org/T319432>
[3] - <https://gerrit.wikimedia.org/r/c/integration/config/+/1127083>
[4] - <https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1128015>
[5] - <https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1017958>
[6] - <https://www.php.net/supported-versions>
[7] - <https://phabricator.wikimedia.org/project/view/6953/>
Yours
--
James D. Forrester (he/him or they/themself)
Wikimedia Foundation
This week's 1.45.0-wmf.5 version of MediaWiki is blocked[0] at group1.
We can't proceed until the following issue is resolved:
* T396790: TypeError:
GrowthExperiments\NewcomerTasks\ConfigurationLoader\CommunityConfigurationLoader::loadTaskTypes():
Return value must be of type array,
MediaWiki\Extension\CommunityConfiguration\Validation\ValidationStatus
returned
- https://phabricator.wikimedia.org/T367334
Once this issue is resolved, the train can proceed to all wikis.
Thank you for any help!
-- Your slightly rumpled train crew
[0]. https://phabricator.wikimedia.org/T392175
Hi all,
With MediaWiki at the WMF moving to Kubernetes, it's now time to start
running manual maintenance scripts there. Any time you would previously SSH
to a mwmaint host and run mwscript, follow these steps instead. The old way
will continue working for a little while, but it will be going away.
What's familiar:
Starting a maintenance script looks like this:
rzl@deploy2002:~$ mwscript-k8s --comment="T341553" -- Version.php
--wiki=enwiki
Any options for the mwscript-k8s tool, as described below, go before the --.
After the --, the first argument is the script name; everything else is
passed to the script. This is the same as you're used to passing to
mwscript.
What's different:
- Run mwscript-k8s on a deployment host, not the maintenance host. Either
deployment host will work; your job will automatically run in whichever
data center is active, so you no longer need to change hosts when there’s a
switchover.
- You don't need a tmux. By default the tool launches your maintenance
script and exits immediately, without waiting for your job to finish. If
you log out of the deployment host, your job keeps running on the
Kubernetes cluster.
- Kubernetes saves the maintenance script's output for seven days after
completion. By default, mwscript-k8s prints a kubectl command that you (or
anyone else) can paste and run to monitor the output or save it to a file.
- As a convenience, you can pass -f (--follow) to mwscript-k8s to immediately
begin tailing the script output. If you like, you can do this inside a tmux
and keep the same workflow as before. Either way, you can safely disconnect
and your script will continue running on Kubernetes.
rzl@deploy2002:~$ mwscript-k8s -f -- Version.php --wiki=testwiki
[...]
MediaWiki version: 1.43.0-wmf.24 LTS (built: 22:35, 23 September 2024)
- For scripts that take input on stdin, you can pass --attach to
mwscript-k8s, either interactively or in a pipeline.
rzl@deploy2002:~$ mwscript-k8s --attach -- shell.php --wiki=testwiki
[...]
Psy Shell v0.12.3 (PHP 7.4.33 — cli) by Justin Hileman
> $wmgRealm
= "production"
>
rzl@deploy2002:~$ cat example_url.txt | mwscript-k8s --attach --
purgeList.php
[...]
Purging 1 urls
Done!
- Your maintenance script runs in a Docker container which will not outlive
it, so it can't save persistent files to disk. Ensure your script logs its
important output to stdout, or persists it in a database or other remote
storage.
- The --comment flag sets an optional (but encouraged) descriptive label,
such as a task number.
- Using standard kubectl commands[1][2], you can check the status, and view
the output, of your running jobs or anyone else's. (Example: `kube_env
mw-script codfw; kubectl get pod -l username=rzl`)
[1]: https://wikitech.wikimedia.org/wiki/Kubernetes/Kubectl
[2]: https://kubernetes.io/docs/reference/kubectl/quick-reference/
What's not supported yet:
- Maintenance scripts launched automatically on a timer. We're working on
migrating them -- for now, this is for one-off scripts launched by hand.
- If your job is interrupted (e.g. by hardware problems), Kubernetes can
automatically move it to another machine and restart it, babysitting it
until it completes. But we only want to do that if your job is safe to
restart. So by default, if your job is interrupted, it will stay stopped
until you restart it yourself. Soon, we'll add an option to declare "this
is idempotent, please restart it as needed" and that design is recommended
for new scripts.
- No support yet for mwscriptwikiset, foreachwiki, foreachwikiindblist,
etc, but we'll add similar functionality as flags to mwscript_k8s.
Your feedback:
Let me know by email or IRC, or on Phab (T341553
<https://phabricator.wikimedia.org/T341553>). If mwscript-k8s doesn't work
for you, for now you can fall back to using the mwmaint hosts as before --
but they will be going away. Please report any problems sooner rather than
later, so that we can ensure the new system meets your needs before that
happens.
Thanks,
Reuven, for Service Ops SRE
Hello all!
The Search Platform Team usually holds an open meeting on the first
Wednesday of each month. Come talk to us about anything related to
Wikimedia search, Wikidata Query Service (WDQS), Wikimedia Commons Query
Service (WCQS), etc.!
Feel free to add your items to the Etherpad Agenda for the next meeting.
Details for our next meeting:
Date: Wednesday, June 4, 2025
Time: 15:00-16:00 UTC / 08:00 PST / 11:00 EST / 17:00 CET
Etherpad: https://etherpad.wikimedia.org/p/Search_Platform_Office_Hours
Google Meet link: https://meet.google.com/vgj-bbeb-uyi
Join by phone: https://tel.meet/vgj-bbeb-uyi?pin=8118110806927
Have fun and see you soon!
Guillaume
*Guillaume Lederrey* (he/him)
Engineering Manager
Wikimedia Foundation <https://wikimediafoundation.org/>