Hello,
I am currently running SPIP 4.4.25 with MySQL 8.0.46 on a cPanel/AlmaLinux server. cPanel now recommends upgrading MySQL from 8.0 to MySQL 8.4 LTS.
Before upgrading, I would like to confirm whether SPIP 4.4.25 has been tested with MySQL 8.4 and whether it is officially supported.
Are there any known compatibility issues or precautions specific to SPIP when upgrading from MySQL 8.0 to 8.4?
Thank you!
Hello @spipfollower there are no problems for this. Cf :
@Plumf MySQL != PHP 
I think it should work well, give it a try and please tell us if it’s ok in order we update Configuration requise - SPIP
@spipfollower Sorry for this hasty reply, which didn’t properly address your request. Thank @b_b
Thanks @b_b. I went ahead and tested it.
SPIP 4.4.25 is working successfully with MySQL 8.4.11 in my test environment.
My test configuration:
Instead of testing with a new empty installation, I used a local copy of a real production SPIP site with its production-derived database containing 84 tables, as well as its actual templates, plugins, IMG directory and content.
I successfully tested:
So I have tested both database reads and writes successfully against MySQL 8.4.11.
During preparation of the local environment, I encountered some issues related to the test environment itself, including cache directories, the PHP memory limit, Apache URL rewriting and GD WebP support. Once those were configured correctly, the problems disappeared. So far, I haven’t encountered a problem that appears to be caused by MySQL 8.4.
For transparency, I actively used AI assistance to help set up, troubleshoot and run this test environment and to structure the compatibility checks. The results reported here, however, are based on the actual behavior I observed from SPIP 4.4.25 running against MySQL 8.4.11, including successful reads, writes, publishing, image processing and multilingual article operations.
Therefore, my result so far is:
SPIP 4.4.25 + PHP 8.5.11 + MySQL 8.4.11: working successfully in this production-derived test environment.
I am nevertheless going to be conservative before upgrading the production MySQL server. I want first to investigate why the local SPIP copy is noticeably slower than the production site and test the other applications that use the same MySQL server. I also have WordPress sites and a Django application on that server, so I want to perform representative tests of those applications as well.
This is especially important in my case because I do not want to treat the production upgrade from MySQL 8.0 to 8.4 as something that I can simply undo if an unexpected application problem appears afterward.
I also noticed a few aspects of the SPIP private-interface design, particularly around some multilingual controls, that I think could be clearer or more intuitive. That is unrelated to MySQL 8.4 compatibility, however, so I think it is better discussed separately another time.
Thanks for encouraging me to test this. I hope these results are useful when considering whether the documented MySQL compatibility range can be updated.
A final update after my previous test: I have now completed the production upgrade as well.
The production server was upgraded through cPanel/WHM from MySQL 8.0.46 to MySQL 8.4.11, and the upgrade completed successfully.
The production environment is:
Before the upgrade I updated SPIP and its plugins, updated the other active applications on the server, created and verified a fresh full backup, and had already tested a production-derived copy of the SPIP site against MySQL 8.4.11.
After the production upgrade I tested the real site again, including the public site and administration area, and everything I have tested is working normally.
I also performed a full server reboot after the upgrade. MySQL 8.4.11 started normally after reboot, the SPIP site remained operational, and I found no MySQL ERROR, Fatal or Aborting entries for the upgrade/reboot date in the log check I performed.
One important compatibility detail: this server has many existing MySQL application accounts using mysql_native_password. MySQL 8.4 disables that authentication plugin by default, so cPanel/WHM preserved compatibility by explicitly enabling it. I plan to migrate active application database accounts gradually to caching_sha2_password as a separate maintenance project rather than mixing that migration with the database-engine upgrade.
So my final result is:
SPIP 4.4.25 is running successfully in production on MySQL 8.4.11.
Of course this is one production environment rather than a guarantee for every SPIP installation, plugin or server configuration, but I hope the test and production result are useful when considering an update to SPIP’s documented MySQL compatibility range.
And for transparency, as mentioned previously, I used AI assistance extensively during the testing, troubleshooting, documentation and upgrade preparation. The compatibility result itself is based on the behavior observed on the actual test and production systems.