View Issue Details

IDProjectCategoryView StatusLast Update
0027484mantisbtmigrationpublic2020-12-06 08:04
ReporterWiwi Assigned Todregad  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionno change required 
PlatformMySQL 8.0.22 + PHP7.4OSUbuntuOS Version20.04.1 LTS
Product Version2.24.3 
Summary0027484: Cannot upgrade Mantis with PHP7.4
Description

Dear dev team,

After an Ubuntu release upgrade from 18.04.1 LTS to 20.04.1 LTS, my SQL server was upgraded from 5.7.32 to 8.0.22 version.
The PHP was also upgraded from 7.3 to 7.4 version.
My existing mantis website (2.22.1 - DB 209) works fine with the new environment :) but if i try to upgrade Mantis to a more recent version, I get an INTERNAL APPLICATION ERROR during the mantis DB upgrade :( :

Call to a member function BindTimeStamp() on null\n/var/www/mantis-bc/admin/schema.php: 69:

        • installer_db_now()\n/var/www/mantis-bc/config/config_inc.php: 2:
        • include( <string>'/var/www/mantis-bc/admin/schema.php' )\n/var/www/mantis-bc/core.php: 105:
        • require_once( <string>'/var/www/mantis-bc/config/config_inc.php' )\n/var/www/mantis-bc/admin/install.php: 34:

Any clue about this BindTimeStamp function called by installer_db_now() ?
Issue can be related with custom fields usage ?
Any suggestion is welcome...

Thanks in advance.

Steps To Reproduce

Mantis website migration from (2.22.1 - DB 209) to last version with Ubuntu 20.04.1 LTS + mySQL 8.0.22 version + PHP 7.4

Additional Information

Tested first with last stable 2.24.3 release (but I'm afraid this version is not compatible with PHP7.4)
Also tested with 2.25.0-dev version and same result

TagsNo tags attached.

Activities

dregad

dregad

2020-11-11 11:44

developer   ~0064641

For the record, there are no known compatibility issues with PHP 7.4. I'm running Ubuntu 20.04 LTS myself without any issues on my dev box.

BindTimeStamp() is an ADOdb function, which is the library we use to provide a database abstraction layer.

The key here, is that the function is being called on null, which means that the database was not initialized (global variable $g_db is null, but it should be an ADOConnection object).

Looking at the provided stack trace, assuming I'm reading it properly, it would appear that schema.php is being loaded from your config_inc.php file:

/var/www/mantis-bc/config/config_inc.php: 2:

        • include( <string>'/var/www/mantis-bc/admin/schema.php' )

This would explain the error because at the time the config file is included, the database has not yet been initialized in MantisBT core. Can you confirm this ?

Wiwi

Wiwi

2020-11-20 07:08

reporter   ~0064669

Thanks for you reply.
In fact, the loaded schema.php is my own PHP code of secret strings decryption to access the DB.
I don't like to put secret information in configuration files, I prefer to decrypt them from environment parameters with a homemade PHP function using crypting algorithms.
It was a bad idea to give the name "schema.php" for my file....
This was not a problem in the version I was using before, but it's the cause of the problem now.
After a few changes, I can finally migrate the DB to the latest version. It wasn't a bug but a consequence of my PHP file name.
The ticket can be closed. Thanks for your support.