Problem with MySQL during update of 2.3.5

[deedw]

I have an older installation 2.3.5 and wanted to update to 2.5 at new years eve. When I do this I see the upgrade page and at the end it says:

Versionsabhängige Funktionen:

2.4-alpha2 - Enable full Unicode support for MySQL
Move MySQL databases from MyIsam and UTF8 to InnoDB and utf8mb4, enabling full unicode input. Warning: Make a database backup before running this!

Soll ich die aufgeführten Funktionen ausführen?
Ja, bitte ausführen Nein, das werde ich manuell erledigen

If I klick Yes, it says that the blog is running with version 2.5. If I visit the blog I see the upgrade page again and this is a cycle. If I click on "No" I get a "Internal Server Error 500" and the blog is dead.

I tried it two times with the same result. Then I tried the update from 2.3.5 to 2.4 since the step is smaller but it shows the same behaviour.

I have no idea, how to solve this. I guess it wants to change something in the MySQL db but somehow does not succeed (even if the updater tells me that everything is updated). Or do I need to change something manually in the db? Is it described how I change it?

I searched in the forum for "Enable full Unicode support for MySQL" and "Move MySQL databases from MyIsam" but no results appeared. So either I'm the first with this problem or everyone else knew what to do.

Best regards
Dee

[onli]

Hi Dee
Do you know which MySQL version that server is using?

To decide whether the upgrader should be shown, serendipity compares $serendipity['versionInstalled'] from serendipity_config_local.inc.php with what is hardcoded as $serendipity['version'] in serendipity_config.inc.php. One option would be to do the upgrade again, click yes, then check the content of the serendipity_config_local.inc.php and set the correct value there if it's stuck on the old version (e.g. '2.5.0').

If $serendipity['versionInstalled'] is the new value but the upgrader is still appearing, then something must prevent the program from running, so that it is using the old cached page, maybe from smarty? Disabling the integrated cache (in configuration) before the upgrade might help, as could deleting the content of templates_c/ after the upgrade (for nuking the smarty cache). Then maybe the real error gets visible.

If I click on "No" I get a "Internal Server Error 500" and the blog is dead.

On 500 errors there will always be an error message with stacktrace in the PHP error log. That message could help.

Or do I need to change something manually in the db? Is it described how I change it?

The upgrader task calls `serendipity_upgradeUTF8_UTF8mb4` in include/functions_upgrader.inc.php. If all columns in the database are marked as some form of UTF-8, it does, for all tables as $table:

Code: Select all

ALTER TABLE `' . $table . '` ENGINE=InnoDB
ALTER TABLE `' . $table . '` ROW_FORMAT=DYNAMIC

and then

Code: Select all

ALTER TABLE `' . $table . '` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci'

You could do this conversion manually before the upgrade, if the database tables even use utf-8 so far. If not the upgrade task does nothing, then the error is elsewhere.

[deedw]

so that it is using the old cached page, maybe from smarty? Disabling the integrated cache (in configuration) before the upgrade might help, as could deleting the content of templates_c/ after the upgrade (for nuking the smarty cache).

I think, that was the problem. After waiting for your answer and the next morning (now) I reloaded my blog and everything looked fine now.

I will upgrade from 2.4.0 to 2.5.0 now and check if this works as well. Maybe I do not need a special waiting period since the db changes were introduced in 2.4.0.

Thanks anyway for your fast answers!

Best regards
Dee

[deedw]

After updating from 2.4.0 to 2.5.0 I stuck in the same loop again, but this time I waited a bit longer. When I hit F5 I didn't see my blog but "500 Internal Server Error".

I deleted the files in template_c but that does not seem to change anything.

On 500 errors there will always be an error message with stacktrace in the PHP error log. That message could help.

I don't know where to find the logs. I think logging is active but I do not see any matching logs via FTP. There seems to be a linked folder by my provider with content but I cannot look into it. I ask him if he has any insights.

Till then I will go back to the working 2.4.0 copy.

Best regards
Dee

[onli]

Progress :)

Serendipity 2.5 had quite some changes for PHP support, I assume one of those is incompatible with the setup. Two options: AS you were planning, ask the hoster for the php error log (manitu has it in their backend, uberspace has to activate it via a console command iirc, other hosters might make it accessible only via the support), or jump to Serendipity 2.6-beta1 or even the current github master (~2.6-beta2). It has a bunch more fixes for PHP 8.4 that might help here, and I do use the beta1 in my blog, it's stable enough (apart from one display issue in the backend that is patched in master).

Which PHP version are you using?

[deedw]

Which PHP version are you using?

PHP Version 7.4.33

[onli]

Ah. In theory supported, but we might have missed something. Would be good to switch to a Version of PHP 8. Serendipity 2.4 is the perfect starting point for that - it was made to run PHP 7.4 or 8.0. Serendipity 2.5 then added support for PHP 8.2, and PHP 8.4 is supported from 2.6-beta1 on. I wrote it down in https://github.com/s9y/Serendipity/wiki ... h-to-PHP-8

Your hoster might offer different PHP 8.x options. If 8.0 is gone upgrading to 2.5 and then switching the PHP version to 8.2 might make the error go away, if you want to try something before support responds :)