Why OJS's REAME.md doesn't inform compatibility with MariaDB?

Hi everyone,
OJS’s README.md informs compatibility with MySQL and PostgreSQL, but doesn’t never informed compatibility with MariaDB. Including it works very well on MariaDB!

Application Version: OJS 3.3.0-8

System Requirements
Recommended server requirements:

  • PHP >= 7.3
  • MySQL >= 4.1 or PostgreSQL >= 9.5
  • Apache >= 1.3.2x or >= 2.0.4x or Microsoft IIS 6
  • Operating system: Any OS that supports the above software, including
    Linux, BSD, Solaris, Mac OS X, Windows

Why it doesn’t also inform compatibility with MariaDB ?

Thanks. :slightly_smiling_face:

That’s because:

a) MariaDB is not part of development/testing cycles; and

b) Theoretically, MariaDB is a “drop-in” replacement for MySQL. In other words, if an app works with MySQL, it’s expected that it works with MariaDB with no changes at all.

My suggestion: set up a test environment and test with a copy of your data.

Personally, I’ve made a couple of installations using MariaDB and OJS works just fine in such cases. But, of course, your mileage may vary.


Using MariaDB in production for 50 different journals. No problem at all.

1 Like

The problem here is upgrading from 3.2 to 3.3 and the absolute need to change the file type from MyISAM to InnoDB for the upgrade to work. Should these statements be in the UPGRADE.md file and elsewhere?

AND as a prerequisite it seems that the 3.2 to 3.3 jump requires every OLD OJS table to be converted to InnoDB format. Can someone confirm this please? Thanks! radjr

1 Like

Actually I think maybe we should change the database driver type from MyIsam to InnoDB before we upgrade to 3.2 from 2.4.8.x.

Can someone confirm that it is OK to change those tables BEFORE the upgrade and on working 2.4.x servers? Thanks!

MyIsam was a default one in older versions of MaridDB and MySQL. Yes, it should be changed when upgrading to 3.3, because of the introduction of foreign constraints. Think it should be fine but I haven’t experimented with such old OJS versions.

By the way (spoiler), starting from the future 3.4 release, it should be easier to control compatibility with different databases because of adopting Laravel’s Query Builder and MariaDB is in the support list: https://laravel.com/docs/9.x/database

1 Like

Thanks. I have added it to my running list of upgrade items. My working list is below! Anyone want to make additional items on the 2.4.x to 3.2 to 3.3 upgrade list?

Install notes for upgrading OJS. NOTE you have to jump to 3.2 then to 3.3.

  1. Must install PHP version 7.4.
  2. Must make PHP 7.4 as default (through direct admin)
  3. Must install PUTS in Apache - Had interserver do this.
  4. All files must be chown’d to radjr1 or whomever the user is running the OJS code.
  5. Must install DOM-XML CentOS / Fedora / Red Hat: yum install php74w-xml
  6. Php must be installed and configured for JSON.
  7. SSL must be running for Plugins gallery and other features to load. System makes https calls.
    Check with this command: wget https://pkp.sfu.ca/ojs/xml/plugins.xml`
  8. Must path TAR correctly for OJS to grab plugin updates. Need to edit config.php TAR is used do decompress downloaded files from the PKP site → Plugins!
  9. Must copy PUBLIC directory from old OJS to NEW OJS folder. Otherwise your journal and site data vanishes.
  10. Right before running the upgrade, you need to go through all the tables and change the table type from MyIsam to InnoDB. Otherwise you get foreign key errors during the upgrade from 3.2.x to 3.3.x.
  11. In MyPhpAdmin, change the Server Connection Collation to utf8_general_ci, config.inc.php should match
  12. Because of open_base_dir restrictions, move tar and other CLI commands needed into a root
    13: File Permissions!! Must be set so that user(on a VPS as a reseller acct) that is running the PHP has access to all files and rights to write the appropriate directories.

Centos / Fedora / Red Hat:
yum update
yum install php74w-xml
systemctl restart httpd


TAR config Run which tar or whereis tar



Collation existing utf_general_ci is what is showing in DATABASES on phpMyAdmin

ALL tables must be InnoDB.

And to confirm I used MyPhpAdmin to go in and change the database type from MyIsam to InnoBD on our production server and there were NO issues. In fact, the server was a bit faster.

1 Like

Another gem that was missing until we hit the limit:

php -d memory_limit=2048M tools/upgrade.php upgrade

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 69632 bytes) in /h ome/radjr1/domains/ojs2.wmpllc.org/public_html/ojs/lib/pkp/lib/vendor/doctrine/dbal/lib/Doctrine/DB AL/Driver/PDOStatement.php on line 115