Hi all,
On Monday we will be issuing a security and maintenance release to all
supported branches of MediaWiki.
The new releases will be:
- 1.39.13
- 1.42.7
- 1.43.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.35 became end of life (EOL) in December 2023,
MediaWiki 1.40 became EOL in June 2024 and MediaWiki 1.41 became EOL in
December 2024.
MediaWiki 1.42 becomes EOL at the end of June 2025.
MediaWiki 1.39 (the old LTS before 1.43) becomes EOL in November 2025.
It is strongly recommended to upgrade to 1.43 (the next LTS after 1.39),
which will be supported until December 2027.
[1] https://www.mediawiki.org/wiki/Version_lifecycle
Hello,
this is not an answer to Martini, but
just a comment that I was using too Windows Xp
until the summer of 2018 (if I'm not mistaken, then I switched
to Linux, first Centos, and when it wasn't anymore possible
to keep it, Ubuntu).
I considered Windows Xp a completely successful product
for which no further development / technological progress
was really justified (except perhaps security patches)
and for sure the subsequent versions of Windows were not, which as far
as I know were indeed absolutely redundant and terrible.
(luckily I've never had to deal with them, I have now on another
partition of my system Windows 11 just for a specific feature on
a specific software which I use occasionally, but I'm really irritated
by the news widget, now disabled, and the policy to mix Internet search
results with local results).
So in my opinion (that's just my opinion) there isn't really a reason,
except for the use of specific software, to use Windows after Windows Xp especially
considering that at least after 2010 Linux was already a perfect viable
replacement also for Windows users, as I've found with Centos desktop.
In short I stand completely with Martini, with the exception to
recommend to give a try to the "Linux branch", which could be considered
(in my opinion) the genuine development of Windows Xp, by contrast
to the subsequent Microsoft's operating systems.
The alternative to that (to just keep using a system outdated of decades)
would be to enforce such a policy at a global level, requiring IT
companies to never replace their major product's versions with
new versions and to maintain all of them simultaneously.
I think this makes sense only from an historical-documentary point of view
so specific agencies should be appointed for this purpose by
state bodies as long as there is an interest by the broad
public for it ...
best
(Thomas)
---- On Thu, 26 Jun 2025 08:45:14 +0100 Tim Starling < mailto:tstarling@wikimedia.org > wrote ---
On 26/6/25 12:57, Leonid G via
Wikitech-l wrote:
All these years I’m using a Windows XP laptop with Firefox
52.9.0
(32-bit) on it, and am quite happy with it (won’t change
the system).
I'm sure you are happy with it, but it's insecure, and it won't
work forever.
But
since two weeks most pictures and map links are not
showing up properly. Here
are the screenshots as an example of one page in three
languages and an example
of a picture file:
https://drive.google.com/file/d/1fYqWSfaJ18Zperk4-9XtwWqPBPZWv4ZL/view?usp=…
Try right-clicking on one of the broken images, then click "open
image in new tab", and switch to the new tab, and see if there is
any error.
I note that the JPEGs seem to be broken whereas the PNGs seem to
work. I would be surprised if that's our fault. Maybe your libjpeg
is corrupted due to it being on a very old hard drive. You could
try reinstalling Windows.
Was a coding algorithm at Wikipedia changed or support for older
browsers disabled? According to this ( https://www.mediawiki.org/wiki/Template:Compatibility_browser )
my browser is still supported. If it has been caused by
mistake, then could you
please turn it back on?
No, I don't think so, although dropping grade C support for your
browser has recently been discussed at https://phabricator.wikimedia.org/T380576
-- Tim Starling
_______________________________________________
Wikitech-l mailing list -- mailto:wikitech-l@lists.wikimedia.org
To unsubscribe send an email to mailto:wikitech-l-leave@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
Greetings!
The Wikimedia Technical Documentation team
<https://www.mediawiki.org/wiki/Wikimedia_Technical_Documentation_Team> has
built several new tools to help you write with confidence, and identify
opportunities to improve docs.
Write with confidence: use automated documentation linting to check your
prose
Writing good technical documentation can be difficult! To make it easier,
we built documentation linting tools that provide sentence-level
suggestions to help simplify your prose, avoid confusing language, and
align your writing with the documentation style guide
<https://www.mediawiki.org/wiki/Documentation/Style_guide>.
-
Visit https://techdoc-linter.toolforge.org/ to use the documentation
linter as a stand-alone tool (works with mediawiki.org and Wikitech
pages)
-
Get doc suggestions in your local text editor or IDE
<https://gitlab.wikimedia.org/repos/technical-documentation/documentation-li…>
-
Run the doc linter on your project in a GitLab CI job
<https://gitlab.wikimedia.org/repos/technical-documentation/documentation-li…>
-
Learn more about the documentation linting tools
<https://www.mediawiki.org/wiki/Documentation/Tools/Linting>
We hope these tools help you feel empowered and more confident in your
ability to write high-quality technical documentation.
Identify opportunities to improve docs: get metrics to direct your efforts
Measuring the quality of technical documentation is complicated, and the
volume of content can make it hard to know where to focus your efforts.
Readers often navigate docs as groupings of related pages, so analyzing
metrics across pages can provide valuable insights. To help with this, we
built tools that provide metrics for collections of technical documentation:
-
The technical documentation dashboard
<https://www.mediawiki.org/wiki/Documentation/Tools/Documentation_metrics_da…>
displays aggregate data for collections of pages on mediawiki.org,
Wikitech, and Meta-Wiki. Use it to get a unified view of doc statistics
across pages, and drill down to view data for individual pages.
-
The metrics generator
<https://www.mediawiki.org/wiki/Documentation/Tools/Metrics_generator>
provides specialized metrics for collections of technical documentation on
mediawiki.org. Use it to assess key quality indicators of tech docs, and
identify pages to focus on.
We hope these tools make it easier to prioritize and measure documentation
improvements across multiple technical wiki pages. Try using the metrics
generator and technical documentation dashboard to identify pages to
improve, then run the linting tools on those pages to get writing
suggestions.
Tell us what you think!
These tools are experimental and have much room to grow. Please give us
your feedback! We'd especially like to hear about:
-
How do you use these tools, and how do they help you?
-
What other types of tooling or data would help you contribute to
improving Wikimedia technical documentation?
Provide feedback at https://www.mediawiki.org/wiki/Talk:Documentation and
join #wikimedia-techdocs on IRC for discussion. Thank you for caring about
technical documentation!
-Tricia, on behalf of the Wikimedia Technical Documentation team
With the introduction of function calls with named arguments in PHP
8.0, function parameter names are now a part of its signature:
renaming a parameter is a potential compatibility break. We need to
decide how that affects our stable interface policy.
Based on some informal discussions, the leading proposal is:
*parameter names are not stable, unless documented otherwise*.
Comments on this are welcome on Phabricator:
https://phabricator.wikimedia.org/T397789 (votes with tokens on that
task are also welcome, since we don't currently have a formal process
for changing the stable interface policy, and I'd like to be sure that
this actually has general approval).
Links for reference:
https://www.php.net/manual/en/functions.arguments.php#functions.named-argum…https://www.mediawiki.org/wiki/Stable_interface_policy
--
Bartosz Dziewoński
Hello,
We are pleased to announce that version 3.0 of the MediaWiki distribution
Docker image Canasta has been released, which includes MediaWiki 1.43.
(Canasta only supports LTS MediaWiki versions, so the version included
before was 1.39.) Other improvements and additions in this new Canasta
version include:
- Much of the code was split off into a separate Docker image,
"CanastaBase", making it much easier to create a Canasta-based MediaWiki
distribution that holds a different set of extensions and skins (or other
changes).
- The Postfix utility was added, allowing for email support out-of-the-box.
- Direct usage of the "Recommended Revisions" listings (
https://www.mediawiki.org/wiki/Recommended_Revisions) for the set of
extensions and skins, which is hopefully a further step toward a
standardization of these listings as a sort of best practices resource.
You can read more about, and download, Canasta here:
https://canasta.wiki/
You can also read more about it on mediawiki.org:
https://www.mediawiki.org/wiki/Canasta
-Yaron and the other Canasta developers
--
WikiWorks · MediaWiki Consulting · http://wikiworks.com
Codex v2.2.0[1] has just been released and will ride the deployment train
next week. In a previous release, we made some deprecating changes in
several components and, with v2.2.0, you will start to see deprecation
warnings in the console related to these changes. Please check your code if
you're using the following components and props:
- Dialog: use the `useCloseButton` prop to turn on the close button instead
of the `closeButtonLabel` prop. Only use `closeButtonLabel` if you need to
customize the close button's aria-label.
- Field and Label: use the `optional` prop to show the "(optional)" flag
instead of the `optionalFlag` prop. Only use `optionalFlag` if you need to
customize the optional flag text.
- Message: use the `allowUserDismiss` prop to show the dismiss button
instead of the `dismissButtonLabel` prop. Only use `dismissButtonLabel` if
you need to customize the dismiss button's aria-label.
- SearchInput and TypeaheadSearch: use the `useButton` prop to show the
search button instead of the `buttonLabel` prop. Only use `buttonLabel` if
you need to customize the search button text.
Visit https://doc.wikimedia.org/codex/latest/components/overview.html to
view documentation for each component, including further explanation of the
props.
The deprecated functionality will be removed in the next major version, for
which there is currently no plan or timeline, but we recommend making these
changes now so the future 3.0.0 release is easier.
Thanks for your attention,
Anne Tomasevich, on behalf of the Design System Team
[1] https://www.npmjs.com/package/@wikimedia/codex
--
Anne Tomasevich (she/her)
Staff Software Engineer, Design System
Wikimedia Foundation
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