All changes for an upgrade, starting with a stable version of the MLF 2.4 branch, are stored in a database transaction. This ensures, that the upgrade will succeed of will fail completely without leaving the forum in an unusable interim state.
Because of the index size issue with utf8mb4 in MySQL < 5.7(.7) we need to ensure the database server to fulfill the index size for text columns to be able to store more than 767 Bytes. This was introduced with MySQL 5.7.7 (respective with MariaDB 10.2.2). Cancel the upgrade if this minimum requirement is not met.
Different from the now official upgrade script, that starts with version 2.4.19.1, this script also allows version 2.4.19 as starting point. This shouldn't be a problem, because there was no database specific change between 2.4.19 and 2.4.19.1.
The file will contain separate blocks for every version, one can start an upgrade from. The file will be renamed finally but will be a separate way for now.
The first repeat of setting of the column size (varchar(255)) is necessary to make the rest of the query (CHARSET SET and COLLATE) working.
The second query in the update procedure ensures the correct charset for the case of an update starting from version 2.4.99.1.
This fixes issues with upgrades of forum scripts from 2.4.x-versions to any 2.5-version, when there was a testing installation of a 2.5-development version, that created these tables before.
Often such testing installations with a following downgrade to a stable version results in remaining, orphaned tables, that breaks the update script in a later run, when it tries to create the tables again.
I put the queries to drop and create the tables into a transaction. Thatswhy I needed to introduce the function mysqli_multi_query to run all four queries per table at once.
* Update MathJax
- MathJax updated to version 3
- Loading of mathjax resources prevented, if unnecessary (e.g. at main page)
* CDN
- CDN to recommended one changed, cf. https://docs.mathjax.org/en/latest/web/start.html
The charset has to be corrected before the index gets added. The code manipulates the upgrade section for version 2.4.99.2. The identical database query is also part of the upgrade to version 20220517.1. I was not able to produce an error when altering the column definition again with and to the same settings. So I have to assume, that the script will not break.
