-

Wed, 09 Feb 2022 12:32:06 +0100

adminsforum@hubzilla.org

KlausR wrote the following post Wed, 09 Feb 2022 12:32:05 +0100

Problems after Update to HZ 7.0.2

After the update with util/udall to HZ 7.0.2 I can no longer access Hubzilla on my server
#^https://hub.cloudlet.at/

Maybe an error occurred during my update or maybe it is a systemic error.
May I ask you to check on your servers, if an update is possible without any problems?

show all 29 comments

Wed, 09 Feb 2022 12:37:26 +0100

Hans van Zijst

hans@social.woefdram.nl

I ran into that problem too, yes. I had to change 2 function definitions in Zotlabs/Web/SessionHandler.php, lines 18 and 90. PHP7.3 doesn't like a definition with "|something" behind it.

On line 18 I changed

function read ($id) : string|false {

into

function read ($id) : string {

and did the same on line 90.

I'm not a programmer, I'm not sure if I screw other things up here, but at least it works again.

Wed, 09 Feb 2022 13:15:34 +0100

Tanja

tanja@hz.lazyteddy.eu

Fixed.
@KlausR You can get back to the new version by checking out the master branch with git checkout master.

Wed, 09 Feb 2022 13:26:30 +0100 last edited: Wed, 09 Feb 2022 13:29:45 +0100

Marshall Sutherland

dwatney@hub.farthinghalearms.com

I woke up to a 500 error on my server, too.

Edit: and was able to roll back to 7.0.1 as well. I guess I had better disable my auto-upgrade job.

Wed, 09 Feb 2022 13:35:13 +0100

Tanja

tanja@hz.lazyteddy.eu

@Marshall Sutherland I didn't get a 500 error though, just a blank page. Maybe this is some other problem?

Wed, 09 Feb 2022 14:07:58 +0100

Mario Vavti

mario@hub.somaton.com

@Tanja a blank page is mostly an error 500/

Wed, 09 Feb 2022 14:11:21 +0100

Marshall Sutherland

dwatney@hub.farthinghalearms.com

in my regular browser, I got the typical blank page. UptimeRobot report 500.

Wed, 09 Feb 2022 15:10:51 +0100

Marshall Sutherland

dwatney@hub.farthinghalearms.com

Checking the logs, I found a few hundred of these before my rollback:

PHP Parse error: syntax error, unexpected '|', expecting ';' or '{' in /var/www/hub.farthinghalearms.com/Zotlabs/Web/SessionHandler.php on line 18

Wed, 09 Feb 2022 15:40:38 +0100

Tanja

tanja@hz.lazyteddy.eu

@Marshall Sutherland Mario just fixed this; if you update again, it should work. It did for me.

Wed, 09 Feb 2022 15:41:01 +0100

Tanja

tanja@hz.lazyteddy.eu

@Mario Vavti I see. Thanks.

Wed, 09 Feb 2022 15:53:19 +0100

Hans van Zijst

hans@social.woefdram.nl

@Tanja

I ran into the same problem. I didn't modify anything, though; I went back to 7.0.1 and reported the problem.

That was probably the better idea, indeed. But a while ago Mario warned me against rolling back to older releases, so I tried my own stubborn way first, which seemed to work.

But indeed, it was fixed in the new commit. Thanks @Mario Vavti!

Wed, 09 Feb 2022 16:19:31 +0100

Witcraft (Hubzilla)

witcraft@hubzilla.fediversum.de

@Mario Vavti After the update, special characters are broken in titles, posts, and comments (e.g. German Umlaute, portuguese special letters) - Has the DB collation changed?

Wed, 09 Feb 2022 16:36:32 +0100

Witcraft (Hubzilla)

witcraft@hubzilla.fediversum.de

My DB is set to utf8mb4_general_ci - I would not remember that I manipulated it. So what would I have to do to fix it...?

Wed, 09 Feb 2022 16:42:48 +0100

Mario Vavti

mario@hub.somaton.com

@Witcraft

My DB is set to utf8mb4_general_ci

That is the collation, not the charset...

Wed, 09 Feb 2022 16:48:34 +0100

Witcraft (Hubzilla)

witcraft@hubzilla.fediversum.de

I am not sure whether this is due to netcup webhosting standard configuration - Which is rather common, at least hereabouts).

Just an idea: Maybe it makes sense to detect / check against the current status of the DB when updating to a "fixed" charset connection mode (or modifying the DB altogether) - Obviously, there are setups that do not match the assumption that charset are standard, causing problems. Also, I am not sure if my database goes more and more inconsistent with every new entry...?

Wed, 09 Feb 2022 16:51:48 +0100

Witcraft (Hubzilla)

witcraft@hubzilla.fediversum.de

@Mario Vavti

That is the collation, not the charset...

OK - So what should I do to fix it?

Wed, 09 Feb 2022 16:54:51 +0100

Witcraft (Hubzilla)

witcraft@hubzilla.fediversum.de

Not sure why but individual tables seem to have a different collation: utf8mb4_0900_ai_ci

Wed, 09 Feb 2022 16:58:53 +0100

Mario Vavti

mario@hub.somaton.com

Hm... I did not expect this change to be a problem. We had issues in the past where the default charset of mysql servers suddenly changed after a system upgrade. This commit should have fixed this situation....

Wed, 09 Feb 2022 17:11:33 +0100

Witcraft (Hubzilla)

witcraft@hubzilla.fediversum.de

@Mario Vavti

We had issues in the past where the default charset of mysql servers suddenly changed after a system upgrade. This commit should have fixed this situation....

It probably did. Appearently, for whatever reason, did un-fix my situation... :laughing:

Wed, 09 Feb 2022 17:35:17 +0100

Mario Vavti

mario@hub.somaton.com

@Witcraft

Not sure why but individual tables seem to have a different collation: utf8mb4_0900_ai_ci

The commit did not do anything with the collation. And all tables should have been created with CHARSET=utf8mb4

See here: #^https://framagit.org/hubzilla/core/-/blob/dev/install/schema_mysql.sql

Wed, 09 Feb 2022 17:41:36 +0100

Mario Vavti

mario@hub.somaton.com

Anyway, @Witcraft i guess there is two possibilities for your problem: either fixing the content or reverting the change for you (that would mean making the charset configurable). I guess new created content works as expected? Does commenting out the code which we added in the commit fix the issue for existing content again?

Wed, 09 Feb 2022 17:46:51 +0100

Marshall Sutherland

dwatney@hub.farthinghalearms.com

I'm working with a fresh update

Wed, 09 Feb 2022 17:56:01 +0100

Mario Vavti

mario@hub.somaton.com

@Witcraft the database is not corrupted. Just the character set changed for you for some reason.

Thu, 10 Feb 2022 07:56:37 +0100

Witcraft (Hubzilla)

witcraft@hubzilla.fediversum.de

Update:

What I found out so far with the kind support of @Grouchy (not sure if this is relevant for other shared webhost users thinking about updating?):

My DB server legitimates with character set cp1252 West European (latin1) - fixed. This cannot be changed since this is a shared webhost provider with a shared DB-Server, so whatever Hubzilla did during installation, it appearently did not hack netcup to change the char set of the DB server. Just a shot into the dark, but maybe Hubzilla detected that character set when installing with pre-7.0.2, and by 7.0.2 no longer regards the server setting but just writes utf8mb4 content after the update with the above commit...

The Hubzilla DB I created with the Hubzilla DB user is set to collation utf8mb4_general_ci, wheras all tables in it where set to utf8mb4_0900_ai_ci (I am pretty sure did not mess with it, so I am not sure that HZ created them with uft8mb4 on installation). But @Mario Vavti wrote that this is about char, not collation (which I have no influence on).

Thu, 10 Feb 2022 08:55:30 +0100

Mario Vavti

mario@hub.somaton.com

@Witcraft

My DB server legitimates with character set cp1252 West European (latin1) - fixed.

So, does changing line 31 in include/dba/dba_pdo.php from $dsn .= ';charset=utf8mb4' to $dsn .= ';charset=latin1' fix your issue?

Thu, 10 Feb 2022 15:15:40 +0100

Witcraft (Hubzilla)

witcraft@hubzilla.fediversum.de

Not really:
Pre-update posts are displayed correctly, but now some of the after-update posts just do not show any content at all.

Thu, 10 Feb 2022 15:32:30 +0100

Mario Vavti

mario@hub.somaton.com

@Witcraft well, yes... You will have to fix some of them manually...

Thu, 10 Feb 2022 20:35:30 +0100

Mario Vavti

mario@hub.somaton.com

@Witcraft i will soon release version 7.0.3 which will allow you to override the charset in .htconfig.php

WARNING: this info applies to @Witcraft only!
Please revert all manual code changes and add the following line to .htconfig.php $db_charset = 'latin1'; prior to the update to 7.0.3. The latter only applies if you decide to change your charset back to latin1.

In case you decide to keep your charset at utf8mb4 and wish to fix your existing data, there is this article which looks promising. Just make sure to backup your data before trying this.

Thu, 10 Feb 2022 22:38:27 +0100

Witcraft (Hubzilla)

witcraft@hubzilla.fediversum.de

@Mario Vavti

WARNING: this info applies to @Witcraft only!
Please revert all manual code changes and add the following line to .htconfig.php $db_charset = 'latin1'; prior to the update to 7.0.3. The latter only applies if you decide to change your charset back to latin1.

In case you decide to keep your charset at utf8mb4 and wish to fix your existing data, there is this article which looks promising. Just make sure to backup your data before trying this.

Thank you for hinting me to solutions - I will dig into it.

Thu, 10 Feb 2022 23:17:27 +0100

Witcraft (Hubzilla)

witcraft@hubzilla.fediversum.de

I had a look into it. In step 2, I am supposed to "Make everything UTF-8 everywhere." by editing a .conf-file. Unfortunately, I have no access to the server conf file on my shared webhosting. So I will need a different solution. But in general, the method 2 (exporting DB, changing collation and charset in the file, re-importing the file to the DB) is what I found in other sources and guidances as well. I will see if I can make sense of it and report back.