Summary:
The Cloud Services implementation of Superset
(https://superset.wmcloud.org) is currently unsupported by WMF staff. We
would welcome a volunteer stepping up to maintain it, but without a new
home the service will be shut down at the end of March.
If you would like to take on ownership of this service, please reach out
to WMCS staffor comment on the phabricator task[1]. The day-to-day
maintenance load is minimal, but someone will need to keep track up
updates, security concerns and a potential future of defense against AI
scraping.
Background:
There has always been demand from researchers and volunteers to run
one-off queries against Wikimedia datasets. Quarry.wmcloud.org was built
and launched by the WMF more than 10 years ago. Originally a one-person
skunkworks project, it quickly caught on in popularity as one of the
most trafficked services run by Wikimedia Cloud Services.
A few years ago, we launched superset.wmcloud.org[0] as an intended
Quarry replacement. We soon learned that despite being a less polished,
home-made tool, Quarry provides many features that Superset does not,
and most users resisted migration away from it. Superset has only a
handful of active users.
At this point, Superset is essentially unsupported by WMF staff. As part
of ongoing efforts to improve our support for Toolforge and other more
popular services we will be either shutting it off or transferring
ownership of Superset in a few weeks[1].
[0] https://phabricator.wikimedia.org/T169452
[1] https://phabricator.wikimedia.org/T416373
Thumbnails shown on-wiki are already quantized to a set of standard sizes
(if a non-standard size is requested, the next-larger standard size is
used, and scaled to the requested size by the browser). We have recently
extended the set of standard sizes, and are now moving to only allow
standard sizes to be used. Regular editing and viewing will not be impacted
by this change at all.
* What isn't changing?
Thumbnails served on wiki (via the "thumb" argument to File:, and via the
Media API) will continue to behave as they do now - if you request a
non-standard size, the next-larger standard size will be provided, and
scaled in-browser if appropriate.
* What is changing?
Requests for non-standard thumbnail sizes using other methods (e.g.
constructing an upload.wikimedia.org URL with a non-standard thumbnail
size) will be blocked by our CDN. These are already being rate-limited for
requests that we assess are not coming from a web-browser.
During this quarter, we will be broadening the scope of the existing
rate-limiting and making it increasingly strict, with the aim being to
refuse such requests entirely by the end of March 2026.
* Why are WMF doing this?
Historically, we have generated thumbnails of whatever size was requested;
this has been a drain on our thumbnailing infrastructure and cost us in
network bandwidth and storage volume. With the increasing prevalence of
highly aggressive scrapers, this has become an intolerable burden on our
network, infrastructure, and staff, who have spent a lot of time over the
holiday period working hard to keep the wikis available for people to read
in the face of automated abuse.
* What do I need to do?
Most likely, nothing: we have already tracked down some of the more
widely-deployed sources of nonstandard thumbnail requests (e.g. Popups
extension) and fixed them. If you own or operate something that requests
thumbnails by constructing a thumbnail URI directly, then now is the time
to either use the Media API instead or to make sure you only request
standard thumbnail sizes.
* What are the standard thumbnail sizes?
They are: 20px, 40px, 60px, 120px, 250px, 330px, 500px, 960px, 1280px,
1920px, 3840px
They are defined in config as $wgThumbnailSteps -
https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/…
And also documented on MetaWiki -
https://www.mediawiki.org/wiki/Common_thumbnail_sizes
To help fix the existing instances, please see
https://phabricator.wikimedia.org/T414805 for search-links, and examples of
how to fix them.
Best
--
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation <https://wikimediafoundation.org/>
Hello everyone
If you don't use etherpad, you can ignore this message.
We will *delete all pads after 1st March 2026*! If you need any of your
pads, please make a local backup. We will not be able to recover the data
after 1st March.
The pad cleanup helps to reduce the size of the database and the footprint
on our infrastructure. After the cleanup, etherpad can still be used for
real-time collaboration but please do not expect long term storage.
Additional cleanups might happen after that unannounced.
See also https://phabricator.wikimedia.org/T415237 for more information.
Greetings and thank you
Jelto
Earlier today (2026-03-30), all unmerged Gerrit patches to `mediawiki/core` that were both attached to a Phabricator task & were 2+ years old appear to have been abandoned _en masse_: [0]
There was a small amount of discussion after-the-fact in IRC (#wikimedia-releng): [1]
I am emailing wikitech-l to announce this myself, as it does not seem like this was done by the folks involved in making/actioning this decision. Speaking personally, I am saddened that it is apparently the case that there was no prior communication about today's action to the Wikimedia technical community, and that there was no (or, at least, no _recent_) consultation with the wider technical community prior to this highly impactful mass-action taking place.
From the current Gerrit search results at [2] (as viewed while typing this email - I'm not sure if Gerrit's search allows for filtering by the time a patch was abandoned), it appears that this action may have affected ~500-530 individual patches.
There was a Phabricator task filed in May 2025 that proposed the automatic abandonment of old changes; however, at the time of this action being taken, there had been no comments on that task since May 2025. [3]
Speaking personally again -- I wish that this hadn't happened. I wish there had been (wider, and more recent) community consultation. I wish that - at the very least - the voices expressing concern in the 'auto-abandonment' task [3] had been listened and responded to. That they weren't saddens me greatly: why should people take the time to express their concerns regarding suggested wide-scale changes such as this, if such concerns won't even be acknowledged prior to this sort of mass-action being taken?
Given (e.g.) the thesis quoted in Tyler Cipriani's comment at [4], I am also especially concerned about what this sort of action may mean for the future health of MediaWiki & other Wikimedia software projects.
I do now hope that these changes can be mass-restored, in the same way that they were mass-abandoned; at least, until further community discussion on the matter can take place. (But that, I recognise, is an opinion that not everyone may necessarily share.)
---
[0] https://sal.toolforge.org/log/QS3ePp0B8tZ8Ohr0YH3W
[1] https://wm-bot.wmcloud.org/browser/index.php?start=03%2F30%2F2026&end=03%2F…)
[2] https://gerrit.wikimedia.org/r/q/project:mediawiki/core+is:abandoned+before…
[3] https://phabricator.wikimedia.org/T393376
[4] https://phabricator.wikimedia.org/T393376#10831729
---
-- a smart kitten
https://phabricator.wikimedia.org/p/A_smart_kitten/
Hi all,
Tomorrow we will be issuing a security and maintenance release to all
supported branches of MediaWiki.
The new releases will be:
- 1.43.7
- 1.44.4
- 1.45.2
This will also resolve security issues in bundled extensions, along with
bug fixes included for maintenance reasons.
These security issues also affect many unsupported versions of MediaWiki.
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.39 became EOL in December 2025 and MediaWiki
1.42 became EOL in June 2025.
More information on these timelines can be viewed on the version lifecycle
page at [1].
[1] https://www.mediawiki.org/wiki/Version_lifecycle