today, we removed the PNG image fallback for Math rendering in LTS release 1_39
By default, math images are fetched from Wikimedia's Restbase instance.
However, this instance will stop providing PNG images shortly.
Therefore, we recommend updating the Math extension if you expect that
your users have chosen to render formulae in PNG instead of SVG
images. According to
99.11% of all users should now be able to render SVG images.
If you render your math images locally
you can upgrade whenever you update your local mathoid instance to a
node version > 10. The current mathoid release (0.7.6) still supports
PNG output when configured.
for more details on the mathoid update procedure.
All the best
On Tue, Nov 22, 2022 at 9:33 PM Physikerwelt <wiki(a)physikerwelt.de> wrote:
> Dear all,
> The change is scheduled to take effect on most* wikis on December 1st,
> 22. From that time, the option to render in PNG mode will no longer be
> available from the user's preferences**.
> All the best
> *) See https://phabricator.wikimedia.org/T320517 for detailed
> deployment information.
> **) https://www.mediawiki.org/wiki/Special:Preferences#mw-prefsection-rendering…
> On Fri, Nov 18, 2022 at 10:20 PM Physikerwelt <wiki(a)physikerwelt.de> wrote:
> > Dear all,
> > As discussed in https://phabricator.wikimedia.org/T311620, the PNG
> > rendering mode will be removed shortly. Users who selected the PNG
> > rendering mode will automatically be transferred to the new default
> > rendering mode. Please spread this information to the interested
> > communities.
> > All the best
> > physikerwelt
This is a quick note to highlight that in six weeks' time, the REL1_40
branch will be created for MediaWiki core and each of the extensions and
skins in Wikimedia git, with some (the 'tarball') included as sub-modules
of MediaWiki itself. This is the first step in the release process for
MediaWiki 1.40, which should be out in May 2023, approximately six months
after MediaWiki 1.39.
The branches will reflect the code as of the last 'alpha' branch for the
release, 1.40.0-wmf.27, which will be deployed to Wikimedia wikis in the
week beginning 13 March 2023 for MediaWiki itself and those extensions
and skins available there.
After that point, patches that land in the main development branch of
MediaWiki and its bundled extensions and skins will be slated for the
MediaWiki 1.41 release unless specifically backported.
If you are working on a new feature that you wish to land for the release,
you now have a few days to finish your work and land it in the development
branch; feature changes should not be backported except in an urgent case.
If your work might not be complete in time, and yet should block release
for everyone else, please file a task against the `mw-1.40-release` project
If you have tickets that are already tagged for `mw-1.40-release`, please
finish them, untag them, or reach out to get them resolved in the next few
We hope to issue the first release candidate, 1.40.0-rc.0, two weeks after
the branch point, and if all goes well, to release MediaWiki 1.40.0 a few
weeks after that.
Tyler Cipriani (he/him)
Engineering Manager, Release Engineering
We are pleased to announce EMWCon 2023 . It will be held at the Hilton
Garden Inn Austin NW/Arboretum  in Austin, Texas on April 19th-21st.
Everyone who is attending is encouraged to stay at the Hilton, where we
have a special group rate of $129/night , this rate is available until
March 16th so please book early (and soon)! The booking is cancellable up
to 6:00pm on first night.
For those who cannot attend in person for any reason, this will be a
"hybrid" conference, with online/virtual capability via Hopin that is
intended to be as integrated into the conference as possible. All
presentations will be available on Hopin live and we are accepting talks
from remote speakers. There is no cost for online/virtual attendance.
About EMWCon: EMWCon is a three-day conference featuring discussions of
topics related to "Enterprise MediaWiki", i.e. the usage of MediaWiki
software by companies, governments, and other organizations. The intended
audience is anyone who uses, or would like to learn more about, MediaWiki.
There will be many opportunities to interact with others using and
developing MediaWiki including presentations, workshops, breakout rooms and
To register/signup for EMWCon please add your name here . To get tickets
for in-person attendance, see the Eventbrite page  which has an early
bird discount through March 19th. To submit a talk, please add your talk
proposal here , the deadline for talk submissions is April 3rd.
We hope to see you in Austin or on Hopin!
The EMWCon 2023 organizing committee
* Bryan Hilderbrand (General Chair)
* Jeffrey Wang (Local Chair)
* Yaron Koren (Program Chair)
* Ike Hecht (Sponsorship Chair)
If your code doesn't read or write to databases in MediaWiki, feel free to
ignore this email.
We have made changes to MediaWiki's Rdbms library that simplify and improve
how to get database connections and how to perform UPDATE queries. We
encourage you to adopt these and provide feedback here or via Phabricator.
== 1. Get a database connection ==
To get a connection to the primary database, you previously needed the
$lbFactory = MediaWikiServices::getInstance()->getDBLoadBalancerFactory();
$lbFactory->getMainLB()->getConnection( DB_PRIMARY );
And for a replica connection:
$lbFactory->getMainLB()->getConnection( DB_REPLICA );
You may now adopt the simpler $lbFactory->getPrimaryDatabase() and
In other words, instead of needing knowledge of the internal LoadBalancer,
its getConnection methods, and the DB_ constants, you only call
getPrimaryDatabase() or getReplicaDatabase().
We won’t deprecate LoadBalancer::getConnection() any time soon. If your
code depends on other LoadBalancer methods, feel free to keep your code
as-is. This change is aimed at the most common use case where you only need
a database connection.
The optional parameters have gotten more usable as well.
getPrimaryDatabase() only takes $domain, which means you no longer need to
skip over the non-applicable $groups parameter. getReplicaDatabase() takes
a string for $group (instead of an array in LB::getConnection).
If you maintain service classes that inject a LoadBalancer object, we
recommend transitioning to inject and type against LBFactory instead. This
removes exposure to LB altogether in most cases.
Currently, getPrimaryDatabase/getReplicaDatabase do not yet support
connection to external clusters (LB::getExternalLB). This is coming soon
We have been reducing complexity around LB/LBF for a while (T326274
<https://phabricator.wikimedia.org/T326274>). The distinction between these
is arbitrary in practice, each wears too many hats, and are not well
Most importantly, LB is mostly internal to the Rdbms library. Most
developers only need a connection to perform read or write queries. The
added coupling can lead to mistakes, misunderstandings, and can feel
overwhelming. The LB documentation includes jargon aimed at Rdbms
maintainer, such as references to internal methods like
isReadyForRoundOperations, setTempTablesOnlyMode, getAnyOpenConnection,
The getConnection() signature is fragile and has led to major outages due
to $domain being set incorrectly. E.g. if you need to connect to another
wiki, you have to set $domain in *both* getMainLB() and getConnection(),
otherwise *fireworks in production*. We keep this internally now to prevent
Lastly, this change makes it possible to add a narrow typehint dedicated to
read-only connections on replica databases, separate from primary database
connections (more below).
Adaption is being tracked in T330641
What is next:
getPrimaryDatabase() and getReplicaDatabase() don't support "external"
databases yet (e.g. x1 at WMF
<https://wikitech.wikimedia.org/wiki/MariaDB#Extension_storage>). This is
coming soon. Details and discussion at T330590
In addition to reducing service dependencies to the ILBFactory typehint, we
are working on an even narrower interface (that ILBFactory extends) called
which only has four methods. It’s marked @internal for now, but that will
change after we hammer out some details.
== 2. IReadableDatabase typehint for replica connections ==
When you typehint a parameter or class member to IDatabase where a replica
database is expected (DB_REPLICA), you may change it to the narrower
LBFactory::getReplicaDatabase returns IReadableDatabase.
MediaWiki developers have at times performed write queries on a replica
connection by mistake, which reached production. While we have effective
protections against data corruption, our only option in production is to
throw a fatal error, which leads to an outage. With this change we move
detection to the very start of the development cycle, verified fully by
static analysis in CI, regardless of test coverage!
The new interface also helps you to self-document in a standard way whether
your service class only reads or also writes to the database. And in IDEs
we will no longer autocomplete write methods on what are known to be
replica connection objects. It’ll also make the coupling between the rest
of MediaWiki and extension with the rdbms library looser
Note that the IDatabase::query() is not part of IReadableDatabase. This
method is discouraged as it executes raw SQL that may include write
queries. If you call this method, continue to typehint IDatabase until you
transition to safe methods like select() or SelectQueryBuilder.
== 3. Introducing UpdateQueryBuilder ==
In 2020, we introduced a chainable SelectQueryBuilder
for SELECT queries. To complement this, we now added a class called
UpdateQueryBuilder, for UPDATE queries. The following existing code uses
update() with unnamed positional parameters:
[ 'img_name' => 'foo' ],
[ 'img_name' => 'bar' ],
You may now use the fluent style like so:
->update( 'image' )
->set( [ 'img_name' => 'foo' ] )
->where( [ 'img_name' => 'bar' ])
->caller( __METHOD__ )
Similar to the SelectQueryBuilder, the fluent style is more readable. It
simplifies building of conditions, is less prone to mistakes, and is more
aligned with widely-used frameworks such as Doctrine (PHP) and Jooq (Java).
We have had at least two data corruption incidents in production due to
passing the wrong order of $set and $where condition (swapping them by
mistake). This reduces the chance of such data corruptions happening, which
alone was worth developing the builder for, before we get to the improved
Adaption is being tracked in T330640
What is next:
We will continue to develop query builders for DELETE and INSERT queries.
The work on migrating calls from ::select() to SelectQueryBuilder is
on-going (T311866 <https://phabricator.wikimedia.org/T311866>).
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation <https://wikimediafoundation.org/>
I have some array declarations in my LocalSettings.php from many years ago
that I am worried may not be compatible with PHP 8+. When I try to run
/maintenance/update.php in PHP 8.1 I get errors. It runs fine in PHP 7.4.3,
fortunately. However, is it okay to set arrays like this in PHP 8+?:
$wgSitemapNamespaces = array( 0, 100, 102 );
Thank you :)
teflpedia.com <- MediaWiki 1.39.1 recently upgraded
-----example from my LocalSettings.php-----
# Site Map see https://www.mediawiki.org/wiki/Manual:$wgSitemapNamespaces
#$wgSitemapNamespaces = array( 0, 2, 4, 12 ); # example, to site map
Main-0, User-2, Project-4, Help-12 namespace
$wgSitemapNamespaces = array( 0, 100, 102 ); # let's site map ONLY Main,
Essay, Lesson namespace
## Extra namespaces
$wgExtraNamespaces = "Lesson";
$wgExtraNamespaces = "Lesson_talk";
$wgExtraNamespaces = "Essay";
$wgExtraNamespaces = "Essay_talk";
$wgExtraNamespaces = "Debate";
$wgExtraNamespaces = "Debate_talk";
## Enable subpages in all namespaces
$wgNamespacesWithSubpages = array_fill(0, 200, true);
$wgNamespacesWithSubpages[NS_MAIN] = false; # per Duncan request Jan 11,
## Set default searching. Roger 2012.11.03, updated array syntax 2023.02.13
$wgNamespacesToBeSearchedDefault = [
NS_MAIN => true,
NS_TALK => false,
NS_USER => false,
NS_USER_TALK => false,
NS_PROJECT => false,
NS_PROJECT_TALK => false,
NS_IMAGE => false,
NS_IMAGE_TALK => false,
NS_MEDIAWIKI => false,
NS_MEDIAWIKI_TALK => false,
NS_TEMPLATE => false,
NS_TEMPLATE_TALK => false,
NS_HELP => false,
NS_HELP_TALK => false,
NS_CATEGORY => false,
NS_CATEGORY_TALK => false,
100 => true,
101 => false
The Tech Department at Wikimedia Foundation  invites you to a* special
event on February 09, 2023, at 1600 UTC* .
*Richard Evans, Electronics & Data Systems Engineer At NASA Glenn Research
Center *, will be presenting on *how MediaWiki is being used within NASA*
to help manage the testing of very large spacecraft to prove they can
survive the harsh conditions of launch, orbit, and re-entry. The management
platform is built from MediaWiki and several key extensions that provide
workflow support. This evolving platform plans to incorporate the
extensions that form the MediaWiki-powered Open CSP platform . This talk
will explain the architecture and benefits of the NASA platform and
motivate the need for Open CSP. We’ll also be recording the event to share
with those who can’t make it. You can join the event through Google Meet
Looking forward to seeing you there,
*--on behalf of the Tech Department, Wikimedia Foundation.*
*(For follow-ups, please reach out to *lnguyen(a)wikimedia.org.)
Erica Litrenta (she/her)
Senior Manager, Community Relations Specialists (Product)
we want to import and integrate some older MediaWiki databases (xml
export / import) and shut down some old instances.
For that we do want to move the content to separated namespaces.
Sadly these wikis were using different licenses.
Is there a way to change the license based on namespaces?