Hey all,
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[0]. 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[1].
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
on Phabricator.[2]
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
weeks.
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
Wikimedia Foundation
[0]: <https://www.mediawiki.org/wiki/Bundled_extensions_and_skins>
[1]: <https://www.mediawiki.org/wiki/Backporting_fixes>
[2]: <https://phabricator.wikimedia.org/tag/mw-1.40-release/>
We are pleased to announce EMWCon 2023 [0]. It will be held at the Hilton
Garden Inn Austin NW/Arboretum [1] 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 [2], 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
hackathon sessions.
To register/signup for EMWCon please add your name here [3]. To get tickets
for in-person attendance, see the Eventbrite page [4] which has an early
bird discount through March 19th. To submit a talk, please add your talk
proposal here [5], the deadline for talk submissions is April 3rd.
We hope to see you in Austin or on Hopin!
Sincerely,
The EMWCon 2023 organizing committee
* Bryan Hilderbrand (General Chair)
* Jeffrey Wang (Local Chair)
* Yaron Koren (Program Chair)
* Ike Hecht (Sponsorship Chair)
[0] https://www.mediawiki.org/wiki/EMWCon_Spring_2023
[1]
https://www.hilton.com/en/hotels/ausaagi-hilton-garden-inn-austin-nw-arbore…
[2] https://group.hiltongardeninn.com/0w8ee1
[3] https://www.mediawiki.org/wiki/EMWCon_Spring_2023#Sign-up
[4] https://www.eventbrite.com/e/emwcon-spring-2023-tickets-511004527297
[5] https://www.mediawiki.org/wiki/EMWCon_Spring_2023#Talks
If your code doesn't read or write to databases in MediaWiki, feel free to
ignore this email.
Hello,
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 ==
What changed:
To get a connection to the primary database, you previously needed the
following:
$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
$lbFactory->getReplicaDatabase().
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
(see below).
Reasoning:
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
encapsulated internally.
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,
appendShutdownCPIndexAsQuery, etc.
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
future outages.
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).
Example adoption:
-
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/891357
-
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DiscussionTools/+/890…
Adaption is being tracked in T330641
<https://phabricator.wikimedia.org/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
<https://phabricator.wikimedia.org/T330590>.
In addition to reducing service dependencies to the ILBFactory typehint, we
are working on an even narrower interface (that ILBFactory extends) called
IConnectionProvider
<https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/…>
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 ==
What changed:
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
IReadableDatabas interface.
LBFactory::getReplicaDatabase returns IReadableDatabase.
Reasoning:
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
<https://en.wikipedia.org/wiki/Loose_coupling#In_programming>.
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.
Example adoption:
-
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/8…
== 3. Introducing UpdateQueryBuilder ==
What changed:
In 2020, we introduced a chainable SelectQueryBuilder
<https://www.mediawiki.org/wiki/Manual:Database_access#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:
$db->update(
'image',
[ 'img_name' => 'foo' ],
[ 'img_name' => 'bar' ],
__METHOD__
);
You may now use the fluent style like so:
$db->newUpdateQueryBuilder()
->update( 'image' )
->set( [ 'img_name' => 'foo' ] )
->where( [ 'img_name' => 'bar' ])
->caller( __METHOD__ )
->execute();
Reasoning:
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
ergonomics.
Example adoption:
-
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/889627/5/includes/Categor…
Adaption is being tracked in T330640
<https://phabricator.wikimedia.org/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>).
Thank you
--
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation <https://wikimediafoundation.org/>
I would like to announce the availability of MediaWiki 1.39.2.
This release primarily is to fix various issues around database upgrades
that users have reported on both MySQL/MariaDB and PostgreSQL.
In the case of MySQL/MariaDB, there may have been the chance of data loss
(as always, please backup before upgrading!), and page views may have
resulted in an error like "The revision #0 of the page named "x" does not
exist." This was seen only when upgrading in a bigger jump between versions
(for example 1.31 to 1.39). More information can be seen in
https://phabricator.wikimedia.org/T326071.
https://phabricator.wikimedia.org/T328169 has been filed to write a
maintenance script to fix the issues caused by these upgrades. It is
expected this will be included in a later point release.
Various patches aimed at support for PHP 8.0, 8.1, and 8.2 have been
back-ported. This should fix some log spam, and MediaWiki should work fully
on versions PHP 8.0 and 8.1.
Reports of bugs with PHP 8.0, 8.1, or 8.2 support are particularly welcome,
and fixes will be back-ported when possible. Please see
https://phabricator.wikimedia.org/tag/php_8.0_support/,
https://phabricator.wikimedia.org/tag/php_8.1_support/ and
https://phabricator.wikimedia.org/tag/php_8.2_support/ for the relevant
work boards.
The tarballs have already been uploaded as of this email; the git tag has
also already been pushed.
== Release notes ==
Full release notes for 1.39.2:
https://phabricator.wikimedia.org/diffusion/MW/browse/REL1_39/RELEASE-NOTES…https://www.mediawiki.org/wiki/Release_notes/1.39
== Changes since MediaWiki 1.39.1 ==
* Localisation updates.
* (T325872) ChangeTags: Remove table name from condition.
* (T324895) MWCallbackStream: Add explicit $stream property.
* (T297031, T326039) PostgresUpdater: Move setDefault ahead of
changeNullableField.
* (T321319) Produce HTML for invalid JSON.
* (T215466, T326071) MigrateActors: Write to revision table (Follow-up
24115a8).
* (T223027) ReservedUsernames config: Add reserved names from maintenance
scripts.
* (T325000, T324896, T307631) Updated OOUI from v0.44.3 to v0.44.5.
* Remove /images .htaccess rules that are no longer relevant.
* Disable php in .htaccess of images directory as a hardening measure.
* (T322583) Include missing message parameter in message.
* LocalFileTest: use encodeBlob/decodeBlob for img_metadata.
* DatabaseSqlite: fix null blobs.
* rdbms: avoid pg_escape_bytea() call-style deprecation notices.
* (T322278) Improve LocalisationCache post-merge validation check.
* (T324408, T326367) Updated wikimedia/remex-html from 3.0.2 to 3.0.3.
* (T322278) Fix the remaining Phan failures on PHP 8.1.
* (T322278, T326367) Respond to some messages from Phan on PHP 8.1.
* Fix phan error when Excimer is enabled.
* (T326021) Add matrix: to $wgUrlProtocols.
* (T314099) stream wrapper: Declare $context class property.
* (T314099) libs\jsminplus: Declare JSNode::$expression.
* (T314096) composer.json: Updated composer/spdx-licenses from 1.5.6 to
1.5.7.
* (T326472) Upgrading cssjanus/cssjanus (v2.1.0 => v2.1.1).
* (T308536) rdbms: Remove deprecation mark for $wgSharedDB.
* (T215466, T326071) installer: Split drop action out of the SQL patch for
actor migration.
* (T322603) SqliteMaintenance.php: Fix fatally broken instanceof check.
* (T326377) rdbms: Use DBConnRef in SelectQueryBuilder.
* api/en.json: api-help-datatype-expiry add missing 'may'.
* (T317329) OutputPage: Fix undefined ['host'] in ImagePreconnect code.
* (T328222) Pass empty string to strlen() if schema is null for
PostgresDatabase.
* (T289926) SpecialRevisionDelete: Set default of '' for wpReason.
* (T155582, T328503) Fix XML dumps for content types with non-string
getNativeData().
* (T326886) PoolCounterRedis: Fix wrong cast, locks weren't being released.
* (T314099) revisiondelete: Replace dynamic property Status::$itemStatuses
* (T327821) skin: Restore default 'value' attribute in makeSearchButton().
* (T329198) ParamValidator: Improve paramvalidator-help-multi-max message.
* (T329415) Clear the statsd data buffer regardless of StatsdServer config.
* (T292348) WikiImporter: do not fail if upload entry in dump lacks 'text'
tag.
* (T330049) UnregisteredLocalFile: Don't call MimeAnalyzer if no path.
* (T324894 TempFSFile: Use a WeakMap for reference tracking if available.
* (T295637) Add no to fallback chain of nb and nn.
**********************************************************************
Download:
https://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.2.tar.gzhttps://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.2.zip
Download without bundled extensions:
https://releases.wikimedia.org/mediawiki/1.39/mediawiki-core-1.39.2.tar.gzhttps://releases.wikimedia.org/mediawiki/1.39/mediawiki-core-1.39.2.zip
Patch to previous version (1.39.1):
https://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.2.patch.gzhttps://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.2.patch.zip
GPG signatures:
https://releases.wikimedia.org/mediawiki/1.39/mediawiki-core-1.39.2.tar.gz.…https://releases.wikimedia.org/mediawiki/1.39/mediawiki-core-1.39.2.zip.sighttps://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.2.tar.gz.sighttps://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.2.zip.sighttps://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.2.patch.gz.sighttps://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.2.patch.zip.sig
Public keys:
https://www.mediawiki.org/keys/keys.html
Hello,
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 :)
Roger
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[100] = "Lesson";
$wgExtraNamespaces[101] = "Lesson_talk";
$wgExtraNamespaces[102] = "Essay";
$wgExtraNamespaces[103] = "Essay_talk";
$wgExtraNamespaces[104] = "Debate";
$wgExtraNamespaces[105] = "Debate_talk";
## Enable subpages in all namespaces
$wgNamespacesWithSubpages = array_fill(0, 200, true);
$wgNamespacesWithSubpages[NS_MAIN] = false; # per Duncan request Jan 11,
2022
## 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
];
-------/example--------
The Tech Department at Wikimedia Foundation [1] invites you to a* special
event on February 09, 2023, at 1600 UTC* [2].
*Richard Evans, Electronics & Data Systems Engineer At NASA Glenn Research
Center *[3], 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 [4]. 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
[5].
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.)
[1] https://www.mediawiki.org/wiki/Wikimedia_Technology
[2] https://zonestamp.toolforge.org/1675958415
[3] https://www.wikidata.org/wiki/Q618728#sitelinks-wikipedia
[4] https://www.open-csp.org/Main_Page
[5]
https://stream.meet.google.com/stream/ce81307c-cdb7-4a5e-9697-65c423f27614
--
________________________________
Erica Litrenta (she/her)
Senior Manager, Community Relations Specialists (Product)
Wikimedia Foundation
Hi everybody,
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?
Best regards,
Dennis
Hi.
I want auto numeration to work again, so I copied and pasted the gadget
code listed under
https://www.mediawiki.org/wiki/Snippets/Auto-number_headings
in the three (MediaWiki:Gadgets-definitions did not exit with any gadget
registration before) files mentioned there.
Unfortunately it does not work.
Can anyone help?
Thanks,
Steffi