Automatic update from 3.6.2 to 3.6.3 fails

I tried to update my dev env from 3.6.2 to 3.6.3 using the automatic updater. For some reason the update process stops at the “Perform Update” phase with the message “Not a downgrade!”.
The “NEXT” button is grayed.

I tried several times with Firefox and Chromium.

To be able to restart the automatic updater, I had to clear the maintenancemode value “Update process” (not cleared in half an hour as implied) and to remove the tmp_uploaded_update folder.

One time the update seemed to succeed and I upgraded the db as suggested. Then after a couple of minutes phpList was back in 3.6.2.

My environment is:
OpenSuse Leap 15.2
Apache 2.4.46
php 7.4.13
MariaDB 10.4.17

The automatic update succeeded in another dev env with php 7.2.10. The config.php files are identical.

The error_log of the failed update stops at the third:
[PHP Notice: Constant HASH_ALGO already defined in /opt/lampp/htdocs/tiedotteet/config/config.php on line 293
[PHP Stack trace:
[PHP 1. {main}() /opt/lampp/htdocs/tiedotteet/updater/index.php:0
[PHP 2. updater->addMaintenanceMode() /opt/lampp/htdocs/tiedotteet/updater/index.php:913
[PHP 3. updater->getConnection() /opt/lampp/htdocs/tiedotteet/updater/index.php:371
[PHP 4. include() /opt/lampp/htdocs/tiedotteet/updater/index.php:305
[PHP 5. define() /opt/lampp/htdocs/tiedotteet/config/config.php:293

In the successfull update, the error_log continues with:
PHP Notice: Constant UPLOADIMAGES_DIR already defined in /opt/lampp/htdocs/tiedotteet/config/config.php on line 28
PHP Stack trace:
PHP 1. {main}() /opt/lampp/htdocs/tiedotteet/updater/index.php:0
PHP 2. updater->removeMaintenanceMode() /opt/lampp/htdocs/tiedotteet/updater/index.php:987
PHP 3. updater->getConnection() /opt/lampp/htdocs/tiedotteet/updater/index.php:395
PHP 4. include() /opt/lampp/htdocs/tiedotteet/updater/index.php:305
PHP 5. define() /opt/lampp/htdocs/tiedotteet/config/config.php:28

Both error_log files contain (line 225):
PHP Notice: Undefined index: update_in_progress in /opt/lampp/htdocs/tiedotteet/updater/index.php on line 360
PHP Stack trace:
PHP 1. {main}() /opt/lampp/htdocs/tiedotteet/updater/index.php:0
PHP 2. updater->addMaintenanceMode() /opt/lampp/htdocs/tiedotteet/updater/index.php:913

It looks like the problem is somehow related to the php version. Firefox versions are identical. Apache version is 2.4.34 and MariaDb 10.1.36.

Now I figured out the reason for failure. It wasn’t related to the PHP version at all.

I saw the following error in the browser console:

Uncaught SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data

The response contained a bunch of php notices like Constant UPLOADIMAGES_DIR already defined …
Because of this the JSON data got corrupted.

Then I found that my php.ini in this environment had DISPLAY_ERRORS = On. In the environment where the update succeeded the DISPLAY_ERRORS was Off.

After changing DISPLAY_ERRORS to Off, the update succeeded.

The updater should disable DISPLAY_ERRORS.

There were a couple new exceptions in the browser log:

Uncaught TypeError: steps[stepActionMap[step]] is undefined

Uncaught TypeError: $(…).dialog is not a function line 2 > injectedScript:1
jQuery 14
line 2 > injectedScript:1:14

You should correct this in the config.php file, where you have multiple define statements for some constants.

but the DEFINEs occur only once in the installed config.php. The problem arises when the updater includes the config.php again, as seen in the stack trace above. Otherwise I should see the same notices whenever I run phpList.
This can easily be reproduced,if you have log_errors enabled and run the updater.
I ran the updater in another dev env, where display_errors=off and log_errors=on. Now the update succeeded and the error_log contained all those “already defined” notices.

Probably most phpList users do not have display_errors=on in the php.ini of there environments. My production setting is off, of course.
I’m developing and maintaining a web shop, where I’ve integrated phpList using the restapi3. So, I always test a new update first. In this particular php 7.4 dev env I happened to have display_errors=on as the system setting.

@veltsu Yes you are right, I had not realised that the updater was including the config file more than once. I can see why that has been done but think that is is a poor approach. You can raise a bug on GitHub GitHub - phpList/updater: Automatic Updater for phpList for this but I’m not sure that the original developer is involved any longer.

Well, include_once has been available since php4 :blush:
I raised an issue about updater disabling display_errors.
Anyway, now we know what happens if display_errors is enabled.