I am happy to announce the belated availability of the general release of
MediaWiki 1.35!
Tarballs have already been uploaded, and the git tag has been pushed.
Thanks to everyone who helped out with this release, especially thanks to
those who tested out the release candidates and provided feedback, as well
as the developers who worked hard to get several important fixes merged in
time for the 1.35 final release. To see what's changed in 1.35, see the
release notes below.
Please note that the PHP version requirement has been raised from 7.2.9 in
MediaWiki 1.34 (and 7.0 in MediaWiki 1.31), to 7.3.19.
MediaWiki 1.35 is an LTS and is due to be supported until the end of
September 2023.
As a reminder, 1.31 is due to become end of life in June 2021. 1.34 is due
to become end of life in November 2020.
As per the pre-release announcement, 1.35.0 also includes some security
fixes that weren't in the release candidates, which came out yesterday for
the ther supported MediaWiki branches.
Known/outstanding issues:
* VisualEditor and Parsoid are now bundled in the tarball and no longer
need a separate Node.js service. The documentation for this still may still
require some updates. Please report any bugs [2] if this affects you.
* (T259685) Zeroconf (zero-configuration) VisualEditor/Parsoid doesn't work
using SQLite as the database backend for MediaWiki. This is due to the lack
of write concurrency in SQLite. If you wish to use this feature, it is
recommended to use MySQL/MariaDB rather than SQLite.
* Watchlist expiry (behind the $wgWatchlistExpiry flag) is currently still
experimental. It should become stable in a later point release. Please
report any issues/bugs [3].
== Security fixes ==
* (T232568, CVE-2020-25813) SECURITY: SpecialUserrights: If a viewer lacks
`hideuser`, ignore hidden users.
* (T255918, CVE-2020-25812) SECURITY: Unescaped message used in HTML on
Special:Contributions.
* (T256171, CVE-2020-25815) SECURITY: Unescaped message used in HTML within
LogEventsList.
* (T258763, CVE-2020-17367, CVE-2020-17368) SECURITY: Prevent invoking
firejail's --output functionality.
* (T86738, CVE-2020-25814) SECURITY: mediawiki.jqueryMsg: Sanitize URLs and
'style' attribute.
* (T115888, CVE-2020-25828) SECURITY: mediawiki.js: Escape HTML in
mw.message( ... ).parse().
* (T260485, CVE-2020-25869) SECURITY: ActorMigration: Load user from the
correct database.
* (T260485, CVE-2020-25869) SECURITY: ensure actor ID from correct wiki is
used.
* (T251661, CVE-2020-25827) SECURITY: TOTP throttle not enforced cross-wiki.
== Links to all mentioned tasks ==
* https://phabricator.wikimedia.org/T232568
* https://phabricator.wikimedia.org/T255918
* https://phabricator.wikimedia.org/T256171
* https://phabricator.wikimedia.org/T258763
* https://phabricator.wikimedia.org/T86738
* https://phabricator.wikimedia.org/T115888
* https://phabricator.wikimedia.org/T260485
* https://phabricator.wikimedia.org/T251661
=== Changes since MediaWiki 1.35.0-rc.3 ===
* (T261258) Remove checks for ancient ImageMagick versions in BitmapHandler.
* (T260232) Don't include null page ids in query list for category dumps.
* (T260009) Check existing watchitem when saving action=watch.
* (T259055) Correct success messages for action=watch.
* mediawiki.page.ready: Simpler tablesorter/makeCollapsible call.
* mediawiki.page.ready: Fix skin override config flags, wrong way round.
* (T262175, T248512) Remove requirement for ApiWatchlistTrait to be in
ApiBase.
* (T259053, T260434) Watchlist: Fix updateWatchLink removing css class when
action=watch.
* (T261901, T261476) mediawiki.notification: Don't close notif when
clicking <select> element.
* (T251506) Sanitizer: Truncate IDs to a reasonable length.
* (T259452) Parsoid updated to v0.12.0.
* (T261970) watch.ajax: Add expiry support to watchpage.mw event.
* (T262900) Fix failure of rebuildLocalisationCache.php due to
ResourceLoader hook.
* (T263014) Hard deprecate File::userCan() with $user=null.
* (T262547) Use localized success message after watching via action=watch.
* (T201491) Fix typo 'Watchlst' in `apihelp-edit-param-watchlistexpiry`.
* (T261081) Installer: consistently reset Language objects.
* (T250449, T250450) Installer: consistently reset Language objects.
* Explicitly wrap some XML calls in libxml_disable_entity_loader().
* (T262934) Ensure dropdown label is always on its own line.
* (T246855) resourceloader: Use a local HookRunner.
* (T263604) Have findBadBlobs.php require Maintenance.php rather than
cleanupTable.inc.
* (T263606) Set fake time, to avoid flaky tests.
* (T261325) Add FindMissingActors script.
* (T262364) shell: Don't blacklist /run/firejail.
* (T263655) NewPagesPager: Ignore nonexistent namespaces.
* Update specialPageAliases and magicWords for Egyptian Arabic (arz).
* (T261347) ParserOutput: don't throw on bad editsection.
* (T255918, CVE-2020-25812) SECURITY: Unescaped message used in HTML on
Special:Contributions.
* (T256171, CVE-2020-25815) SECURITY: Unescaped message used in HTML within
LogEventsList.
* (T258763, CVE-2020-17367, CVE-2020-17368) SECURITY: Prevent invoking
firejail's --output functionality.
* (T86738, CVE-2020-25814) SECURITY: mediawiki.jqueryMsg: Sanitize URLs and
'style' attribute.
* (T115888, CVE-2020-25828) SECURITY: mediawiki.js: Escape HTML in
mw.message( ... ).parse().
* (T260485, CVE-2020-25869) SECURITY: ActorMigration: Load user from the
correct database.
* (T260485, CVE-2020-25869) SECURITY: ensure actor ID from correct wiki is
used.
* Add Finnish special page aliases.
* Fix GuzzleHttpRequest request headers.
* Fix description for pruneFileCache.php.
* emptyUserGroup.php: handle more than 5000 users.
* Make ApiSandbox copyable URL absolute.
* (T261087) Add a link from a deleted page to that page's logs.
Open Bugs:
[1] https://phabricator.wikimedia.org/project/board/4035/
Bug report form:
[2]
https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?tags=MW-1.35-…
[3]
https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?tags=MW-1.35-…
**********************************************************************
Download:
https://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.0.tar.gz
Download without bundled extensions:
https://releases.wikimedia.org/mediawiki/1.35/mediawiki-core-1.35.0.tar.gz
Patch to previous version (1.35.0-rc.3):
https://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.0.patch.gz
GPG signatures:
https://releases.wikimedia.org/mediawiki/1.35/mediawiki-core-1.35.0.tar.gz.…https://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.0.tar.gz.sighttps://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.0.patch.gz.sig
Public keys:
https://www.mediawiki.org/keys/keys.html
Release Notes
https://www.mediawiki.org/wiki/Release_notes/1.35
Hi,
There is a new episode of the MediaWiki podcast "Between the Brackets",
featuring an interview with Richard Heigl and Markus Glaser, two of the
founders/executives of the MediaWiki development and consulting company
Hallo Welt, which is best known for producing the BlueSpice MediaWiki
distribution. You can listen to the episode here:
https://betweenthebrackets.libsyn.com/episode-71-richard-heigl-and-markus-g…
-Yaron
Hi All,
I have recently upgraded mediawiki to version 1.34.4 (from 1.24) in a
fresh directory and found that SyntaxHighlight extension is not working
well.
There is no color applied for all the langs I tried (especialy ksh
one).
I guess there is a link with the Python version used.
Both Python V2.7.9 and V3.4.2 are available on the server.
Her are the specs :
OS: Linux Distribution
Hosting: OVH Shared hosting
PHP version: 7.3.20 (cgi-fcgi)
Mediawiki version: 1.34.4
SyntaxHighlight: 2.0 (embended)
Does anybody have a clue ?
Regards
I am assisting in getting an older install of mediawiki updated. They used
a custom php file to define the Geshi highlighting, however when updating
this appears to have been broken, Is there any way to define custom
language highlighting?
Thanks
Hello,
It has been a while since I gave an update on the state of abstracting
schema and schema changes in mediawiki
<https://phabricator.wikimedia.org/T191231>. So here's a really long one.
So far around half of the mediawiki core tables have been migrated to
abstract schema (plus lots of extensions lika Wikibase, Babel, Linter,
BetaFeatures, etc.). Special thanks to Tgr for reviewing most of the
patches and Sam Reed and James Forrester for doing the extensions.
With the growing number of schemas being abstracted, this is going to
affect your development if you work on schema and schema changes in core or
any of the extensions. So If you do, please read Manual:Schema changes
<https://www.mediawiki.org/wiki/Manual:Schema_changes> in mediawiki.org
You might think that abstraction is just migrating SQL to JSON but it's
much more, we are making the database schema of mediawiki much more
consistent, We are basically addressing several long standing issues like
T164898 <https://phabricator.wikimedia.org/T164898> and T42626
<https://phabricator.wikimedia.org/T42626> as well.
*Improvement aspects*
First aspect is drifts between different DBMSes. Sqlite schema is being
produced by regex replacement (this code
<https://github.com/wikimedia/mediawiki/blob/c477bcf2c5c482d3189ec3579c5dee4…>)
which is less than great but at least it comes from one place. For
Postgres, its schema and MySQL/Sqlite has drifted so drastically, that
fixing it so far required 76 schema changes fixing issues ranging from
missing indexes to missing PKs, extra AUTO_INCREMENT where it shouldn't be,
missing DEFAULT values, drifting data types and much more. You can follow
the fixes of Postgres in here <https://phabricator.wikimedia.org/T164898>.
The second aspect is the inconsistency in the schema itself. How do we
model strings? VARCHAR? VARBINARY()? VARCHAR() BINARY? (all three are
different things). You'd be surprised how inconsistent our MySQL is. So
far, we are migrating all VARCHAR() BINARY fields to VARBINARY() (so far
ten schema changes).
Another inconsistency is timestamps. In MySQL, around half of them are
BINARY(14) and the other half VARBINARY(14) (but in Postgres all are
TIMESTAMPTZ), there is even a ticket
<https://phabricator.wikimedia.org/T42626> about it. It makes sense to
migrate all of them to BINARY(14) but not all timestamps are 14 characters,
e.g. expiry fields accept "infinity" as value and it's a valid timestamp in
Postgres ¯\_(ツ)_/¯ When you turn an expiry field to BINARY(14), "infinity"
becomes " infinity" and as the result mediawiki doesn't recognize it
as infinity ("infinity" != " infinity"). There are several ways to
move forward handling expiry fields, you can follow the discussion in this
gerrit patch <https://gerrit.wikimedia.org/r/c/mediawiki/core/+/631936>.
Another fun aspect: Booleans. MySQL doesn't have boolean, it translates
them to TINYINT(1) but other DBMSes don't have TINYINT, they have SMALLINT
and BOOL though (and we mostly use SMALLINT for them), we decided to go
with SMALLINT for these cases (which is different than what Doctrine DBAL
does, it uses BOOL, so we introduced our own custom type for booleans).
Last but not least: ENUMs. MySQL and Postgres support that but Sqlite
doesn't. Doctrine DBAL doesn't support ENUM at all (as it's an
anti-pattern) while core has eight fields that are ENUM. There's an RFC to
discourage using it in general. Feel free to comment on it.
<https://phabricator.wikimedia.org/T119173>
A miscellaneous note: The directories that hold the archive of sql patches
of schema change are exploding (some of the sql patches are even orphan but
we can't find them because there are so many of them). So I started a RFC
to clean that mess up: Drop support for database upgrade older than two LTS
releases <https://phabricator.wikimedia.org/T259771>
*What's next?*
- We continue to migrate more tables, hopefully we will get two third
of them by the end of the year (fingers crossed). You can follow the
progress in its ticket <https://phabricator.wikimedia.org/T230428>.
- We will support abstract schema changes, really soon, like in a
couple of weeks. Basically you start a json file containing snapshots of
before and after of a table and then a maintenance script will produce the
needed sql patches for you for different schemas. This will increase the
developer productivity drastically, since 1- Schema change sql files become
more reliable and consistent and less prone to errors like adding the
column to the wrong table in some DBMSes
<https://gerrit.wikimedia.org/r/c/mediawiki/core/+/328377/22/maintenance/mss…>
2- You don't need to know Postgres or Sqlite peculiarities to make patches
against it. The reason you need to proved the whole table for adding like
an index is that sqlite doesn't support all types of ALTER TABLES, you have
to create temporary tables, move the data around and then rename and drop
in some cases, producing beautiful sql patches like this
<https://gerrit.wikimedia.org/r/c/mediawiki/core/+/630341/1/maintenance/sqli…>
- We work on improving the script that reports drifts between core and
our production. I have already made it work with abstract schemas as well,
I will continue working on it to report even smaller differences like field
size, type, etc. Which is now much easier thanks to the abstract schema.
Slowly we will migrate that script to production (as part of SRE scripts)
and we will do automated reports and automated drift fixes (on small
wikis). You can follow the work on this ticket.
<https://phabricator.wikimedia.org/T104459> So far, this script is being
run manually but found more than thousand and thousands of drifts across
the cluster and all are fixed thanks to our amazing DBAs (look at the
ticket)
*How can I help?*
Glad you asked! You can follow the abstract-schema
<https://gerrit.wikimedia.org/r/q/hashtag:%22abstract-schema%22+(status:open…>
hashtag in gerrit and review patches or you can make them yourself (get
yourself familiar using the documentations
<https://www.mediawiki.org/wiki/Manual:Schema_changes>). If you maintain an
extension feel free to migrate its table(s) (and track it in this ticket
<https://phabricator.wikimedia.org/T259374>). If you use Postgres for
mediawiki, please help us with testing the improvements for Postgres.
Thanks for reading this long email!
Best
--
Amir (he/him)
Hello,
If you're not maintaining a mediawiki instance or don't work with
mediawiki's installer/updater, feel free to ignore this email (sorry for
spam).
The aforementioned RFC has reached phase 3, which means we need to reach
out to stakeholders and since this RFC is going to impact third party
installations, hence this email.
Currently and in theory, mediawiki supports upgrading from 1.2 (released in
2004) to its current version but if this RFC is approved, you wouldn't be
able to upgrade from versions older than two LTS releases. So for example
for upgrading to 1.35, you can't upgrade to it from 1.26 or lower, 1.26 was
released in end of 2015 and EOL'd in end of 2016, if you want to upgrade
from 1.26, you have to first upgrade to 1.34 and then you would be able to
upgrade to 1.35 [Note that this is an example, 1.35 is already released and
thus not affected by this RFC, this is going to affect future releases].
Here's the RFC: https://phabricator.wikimedia.org/T259771 Feel free to
chime in and spread the word to other stakeholders.
Thanks
--
Amir (he/him)