[Solved] 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 :)

[deedw]

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.

Not perfect. After updating to PHP 8.0.30, Serendipity 7.4.0 showed only "Internal Server Error 500". The hoster told me that the reason is "blog/plugins/serendipity_event_nl2br/serendipity_event_nl2br.php" which has an error.

Nonetheless I tried the update to 2.5.0. After hitting the upgrade button and everything went fine (and deleting the template_c content) the blog still showed "Internal Server Error 500". We try to find out what's going wrong.

Is there anything known with serendipity_event_nl2br.php and PHP 8?

Best regards
Dee

[onli]

Nothing I'm aware of. I do use it myself on onli-blogging.de, though with PHP 8.2 and in nl2p mode. The hoster didn't share the exact error message with you?

[deedw]

Nothing I'm aware of. I do use it myself on onli-blogging.de, though with PHP 8.2 and in nl2p mode. The hoster didn't share the exact error message with you?

No, not yet. I can ask him.

[onli]

Please :) Ideal would be both, but I guess most important is the error you run into now. Then we can probably fix it.

[deedw]

Here's the php stack trace message:

Code: Select all

[24-Feb-2026 16:10:00 Europe/Berlin] PHP Fatal error:  Uncaught TypeError: in_array(): Argument #2 ($haystack) must be of type array, bool given in /hosts/deesaster.org/blog/plugins/serendipity_event_nl2br/serendipity_event_nl2br.php:737
Stack trace:
#0 /hosts/deesaster.org/blog/plugins/serendipity_event_nl2br/serendipity_event_nl2br.php(737): in_array('tr', false)
#1 /hosts/deesaster.org/blog/plugins/serendipity_event_nl2br/serendipity_event_nl2br.php(314): serendipity_event_nl2br->nl2p('\n<h3>Tag 9 \xE2\x80\x93 ...')
#2 /hosts/deesaster.org/blog/include/plugin_api.inc.php(1188): serendipity_event_nl2br->event_hook('frontend_displa...', Object(serendipity_property_bag), Array, Array)
#3 /hosts/deesaster.org/blog/include/functions_entries.inc.php(1202): serendipity_plugin_api::hook_event('frontend_displa...', Array, Array)
#4 /hosts/deesaster.org/blog/include/genpage.inc.php(53): serendipity_printEntries(Array, 1)
#5 /hosts/deesaster.org/blog/include/functions_routing.inc.php(389): include('/hosts/deesaste...')
#6 /hosts/deesaster.org/blog/index.php(75): serveEntry(Array)
#7 {main}
  thrown in /hosts/deesaster.org/blog/plugins/serendipity_event_nl2br/serendipity_event_nl2br.php on line 737

We downgraded to PHP 7.4.33 now so that my blog works again.

One idea was to deactivate the plugin and update the blog to 2.5.0. Unfortunately two problems arise: 1. I heaviliy rely on this plugin. If I remove it I only have a big wall of text since I don't used breaks between paragraphs. 2. Nonetheless, I removed the plugin and reinstalled it. And it broke the layout: https://www.deesaster.org/blog/index.php?/archives/2962 There is no space above headline and too much space after headlines and images. I wonder why this happened.

[onli]

The plugin has two modes of operation, nl2br and nl2p. I assume you used nl2p before - line 737 is part of the nl2p function. When you uninstalled the plugin it probably reset the configuration, and now your blogs uses nl2br mode. Change it in the plugin configuration, set "Use P-Tags" to "Yes". Then the blog should look correct again.

For the error you saw with PHP 8, there are multiple possible fixes. The one to try first: In line 260, there begins this if:

Code: Select all

if (count($isolate) < 1) {
    $isolate = false;
}

Change it to:

Code: Select all

if (count($isolate) < 1) {
    $isolate = array();
}

That's the likely source of the bool the error message complains about. That code path depends on the plugin configuration, that is why this bug stayed hidden I assume. It might even stay hidden now if you upgraded to PHP 8, since the plugin configuration got reset.

Alternatively, you could make sure in the failing if that it works on arrays. Line 736 start like this:

Code: Select all

elseif($tag && !$isolation_flag && $this->is_starttag($textarray[$i]) 
                && (in_array($tag, $this->isolation_block_elements) || in_array($tag, $this->isolationtags) ) )

Change it to

Code: Select all

elseif($tag && !$isolation_flag && $this->is_starttag($textarray[$i]) 
                && (is_array($this->isolation_block_elements) && in_array($tag, $this->isolation_block_elements)) || (is_array($this->isolationtags) && in_array($tag, $this->isolationtags)) ) 

I will apply the latter fix to the github master already, but it would be interesting to know whether the first one helps in your situation, if the error occurs again when you upgrade to PHP 8.

[deedw]

I changed it to "array()". I do not see this error anymore in the php.log. But now I see something different:

Code: Select all

[25-Feb-2026 08:31:23 Europe/Berlin] PHP Fatal error:  Uncaught Error: Class 'IntlDateFormatter' not found in /hosts/deesaster.org/blog/bundled-libs/php81_bc/strftime/src/php-8.1-strftime.php:60
Stack trace:
#0 /hosts/deesaster.org/blog/bundled-libs/php81_bc/strftime/src/php-8.1-strftime.php(201): PHP81_BC\{closure}(Object(DateTime), '%A')
#1 [internal function]: PHP81_BC\{closure}(Array)
#2 /hosts/deesaster.org/blog/bundled-libs/php81_bc/strftime/src/php-8.1-strftime.php(180): preg_replace_callback('/(?<!%)%([_#-]?...', Object(Closure), '%A, %e. %B %Y')
#3 /hosts/deesaster.org/blog/include/functions.inc.php(143): PHP81_BC\strftime('%A, %e. %B %Y', Object(DateTime))
#4 /hosts/deesaster.org/blog/include/functions.inc.php(191): serendipity_strftime('%A, %e. %B %Y', 1770090420, true, false)
#5 /hosts/deesaster.org/blog/include/functions_smarty.inc.php(750): serendipity_formatTime('%A, %e. %B %Y', '1770090420', true, false)
#6 /hosts/deesaster.org/blog/templates_c/2k11/15/fb/26/15fb26c56eb1c62c48970d9fe802108a5de5e666_0.file.entries.tpl.php(51): serendipity_smarty_fo in /hosts/deesaster.org/blog/bundled-libs/php81_bc/strftime/src/php-8.1-strftime.php on line 60

[onli]

And was that under PHP 7.4, where it worked before, or did you switch back to PHP 8, the bug occurred and changing line 261 to array() fixed it? Edit: Doesn't matter anymore, I could reproduce the bug. Yes, changing false to array() in line 261 fixes that problem. I committed that fix as well to the github master (currently planned as 2.6-beta2).

The new error you see is because of https://packagist.org/packages/php81_bc/strftime. It needs the php-intl extension to be activated.