Business General

Review of MediaWiki 1.39

Review of MediaWiki 1.39

Although MediaWiki is only used by 0.1% of the websites on the web, and 63% of wiki-style websites.  By contrast, WordPress has a 43% market share and 60% of the blog-type websites.  On the surface, it might seem that MediaWiki is “not worth it”, but in reality, it depends on what you want your website to do.

Let’s say that you want to create an online casino website, like Slots Real Money.  Obviously, the main part of your website is going to be the actual product, online casino apps.  But when running an online site, there are also other parts.

One part is “advertising” to tell your customers about the news and greatest additions to your website.  Those kind of news items are ongoing, always changing, the site includes a new article at regular intervals.

But other parts of the website are not always changing.  This would include FAQ pages, history of the website pages, and instruction pages.  Although with an online casino website, one would expect only qualified editors to add, remove, and edit the pages, but in other types of websites a group of people work on articles, adding, removing, and editing content.  The end result is that the articles are improved over time, but are always there.  For those types of articles, Wikipedia is the best choice.

The current release of MediaWiki is 1.37.2.  The current LTS release is 1.35.6.  MediaWiki 1.38.x is expected to be released in May 2022 (this month), and MediaWiki LTS 1.39.x is expected to be released in November 2022 (6 months in the future).  So why am I reviewing MediaWiki 1.39.x if 1.38.x has not even been released yet?  MediaWiki 1.39.x is the next LTS release (long-term release, valid for 3 years), and it is the one that is currently being used by Wikipedia and other MediaWiki official sites.

Unless you are a Plugin Developer, for most people, it is best to stick with LTS releases of MediaWiki.  So if you currently using MediaWiki 1.35.x or even if you are planning to create a new website within the next year and a half, you need to decide between sticking with MediaWiki 1.35.x LTS or moving to 1.39.x LTS.

PHP 8.0 and MediaWiki

This is one of the most important changes that is happening with MediaWiki 1.39, the ability to use MediaWiki with PHP 8.0.  PHP 8.0 was released in Nov 2020, 2 1/2 years ago.  PHP is now at version 8.1.5 which was released in April 2022.  It is time for MediaWiki to brace for the future and support PHP 8.0, but PHP had major changes from PHP 7.4, so it took a lot of work to get MediaWiki upgraded to run flawlessly with PHP 8.0.  If you take a look at the release notes for MediaWiki, you can get an idea of just how much work went into this one general-sounding item.

The only major problem right now is that the CirrusSearch Extension does not work with PHP 8.0, and since ElasticSearch does not work with PHP 8.0.  ElasticSearch is a third-party application that MediaWiki has no control over.  So if you don’t use CirrusSearch, it is safe to use PHP 8.0 with MediaWiki 1.39.x.  If you do use CirrusSearch, then you will need to stick with PHP 7.4 for the time being.

MySQL 8.0 and MediaWiki

I have been using MySQL 8.0 with MediaWiki for several versions of MediaWiki, but with the current release of 1.39.x, I discovered an issue.  Actually, this is an issue that appeared in 1.35.x, but since I skipped over that LTS version and stayed with 1.31.x, I did not notice this issue until recently.

I use MySQL 8.0 with a character set of utf8mb4 and a collation of either utf8mb4_0900_as_ci  (accent sensitive and cap insensitive) or utf8mb4_0900_ai_ci (accent  insensitive and caps insensitive).  I use MySQL’s built-in search capabilities to handle capitalization differences and accent differences in article title searching instead of using CirrusSearch.  From MediaWiki 1.35.x forwards, MediaWiki sets all 255 character length fields to VARBINARY(255) instead of VARCHAR(255).

I did some research to try to figure out why MediaWiki would do this.  Why wouldn’t they just let the database handle this as the database was designed to do.  I found two arguments for this change.  One was that different collations produce different results.

Two different languages can have the same characters, but have different dictionary orders in their respective language.  So depending on what a person sets their database collation to affect the final search result order.  So the developers of MediaWiki decided it would be best to force everybody to use binary search, so no matter what your database collation is set to, the same search results will always appear.

But that is a stupid argument.  The whole point of a database is to do searching, so why would MediaWiki take away the whole reason for using a database in the first place?  It makes no sense, in my opinion.  The only “argument” I could find is that PostGreSQL (the other database system MediaWiki supports) only has VARCHAR of 1 byte, so it essentially treats all characters as binary or VARCHAR(255) BINARY (in MySQL format).   But why should I have to deal with an inferior database system, because other people choose to use PostgreSQL?

The second argument that I heard is that the original utf8 was 3 bytes long instead of 4 bytes long, so Chinese characters and emoji characters were getting chopped off.  This was true in MySQL 5.4, but this is not true in MySQL 8.0.  The character set utf8 is 3 bytes and utf8mb4 is 4 bytes long.  In MySQL 8.0, utf8 (3 bytes) is actually deprecated and it will be removed in future releases.

There is also the problem of other people using “other databases” in addition to MediaWiki and their data is bound by the restrictions of the other database system.  But again, just because somebody else is using an inferior database system, why should I be bound by those conditions.

But hope is not all lost, I can safely say that if you change your personal database to use VARCHAR(255) (do not add the word BINARY in) instead of VARBINARY(255), MediaWiki works find with no problems.  In fact, it actually runs as one would expect it to run.  The problem is that you have to manually change the following files:

  • ./maintenance/tables-generated.sql
  • ./maintenance/archives/*binary*.sql
  • ./includes/installer/MysqlInstaller.php
  • ./includes/installer/MysqlUpdater.php

And make sure that you make backup copies, so when you install patches these files will not be overwritten.  I submitted a features request to MediaWiki and it is 6 months until 1.39.x is released, so it is possible that by the time 1.39.x is released, the installer will allow a person to choose between VARCHAR and VARBINARY as well as choosing which database collation they want to use.  But then Ukraine and Russia might become best friends … ah, fantasy world, isn’t it great!

Third party vendor application

I have not done a complete check, but it looks as if all of the third-party vendor application that MediaWiki used in the core application has been upgraded to their most recent versions.

Database and Configuration changes

MediaWiki did the following word changes.

  • DB_MASTER is now DB_PRIMARY (from 1.38)
  • DB_SLAVE is now DB_REPLICA (from 1.35)
  • *blacklist* is now *Prohibited*

Most extensions have been automatically updated, but if you are trying to use a not-so-common extension that does not seem to work, the problem might be related to this.  There are also other changes to hooks and MediaWiki library functions that have changed, so check the online documentation.

About the author

Donna Miller

Donna is one of the oldest contributors of Gruntstuff and she has a unique perspective with regards to Science which makes her write news from the Science field. She aims to empower the readers with the delivery of apt factual analysis of various news pieces from Science. Donna has 3.5 years of experience in news-based content creation, and she is now an expert at it. She loves journalism, and that is the reason, she moved from a web content writer to a News writer, and she is loving it. She is a fun-loving woman who has very good connections with every team member. She makes the working environment cheerful which improves the team’s work productivity.

Add Comment

Click here to post a comment