Arch Linux

With PHP 8.1, many operations, including nextcloud-cron.timer and requests to CalDAV resources, report the following error (warning?):

Return type of OC\Memcache\Cache::offsetUnset($offset) should either be compatible with ArrayAccess::offsetUnset(mixed $offset): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice at /usr/share/webapps/nextcloud/lib/private/Memcache/Cache.php#93

This upstream commit seems related: https://github.com/nextcloud/server/commit/113756db30fcbffe9e90b54c29e78dee0676109f#diff-f8033a478e65baa105f6455ef20b0ef14e2bcbcc002ed5ea7602a6f3da331116

@wolegis: Thanks for the report.

The package with a patch for php 8.1 has been in [community-testing] for nearly a week [1] and the update to php 8.1 has been discussed on the arch-dev-public mailing list [2] for longer than that.
To mitigate problems such as this, please consider to help testing [3] in the future.

@yan12125: Thanks for the pointer. I'll try to backport this patch into the existing one!

[1] https://github.com/archlinux/svntogit-community/commit/c78893ca625b81a48d3201ac31dff70b2477133f#diff-3e341d2d9c67be01819b25b25d5e53ea3cdf3a38d28846cda85a195eb9b7203a
[2] https://lists.archlinux.org/pipermail/arch-dev-public/2021-December/030570.html
[3] https://wiki.archlinux.org/title/Arch_Testing_Team

Please check whether nextcloud 23.0.0-3 in [community] fixes your problems.

Thanks! Here comes the next error:

Return type of Pimple\Container::offsetUnset($id) should either be compatible with ArrayAccess::offsetUnset(mixed $offset): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice at /usr/share/webapps/nextcloud/3rdparty/pimple/pimple/src/Pimple/Container.php#143

Those pull requests seem related:
https://github.com/nextcloud/server/pull/29953
https://github.com/nextcloud/3rdparty/pull/905
https://github.com/silexphp/Pimple/pull/266

Also, pimple is mentioned at https://github.com/nextcloud/server/issues/29287#issuecomment-946632591. Maybe those dependencies should also be updated besides backporting patches from https://github.com/nextcloud/server/issues/29287 (Support PHP 8.1 - First batch) and https://github.com/nextcloud/server/pull/29862 (Support PHP 8.1 - Second batch).

The problem with upgrading a 3rdparty submodule is that that is not how we are building the package (it's built from a premade source tarball, so patches have to be backported unfortunately).

Both merge requests for php 8.1 support [1][2] are contained in the backported patch already.

However, the changes introduced by the pimple 3.5.0 upgrade [3] seem trivial enough to also backport into the existing patch.

[1] https://github.com/nextcloud/server/pull/29432
[2] https://github.com/nextcloud/server/pull/29862
[3] https://github.com/nextcloud/3rdparty/pull/905/files

Please check whether 23.0.0-4 in [community] fixes the problems (and/or introduces new ones).

Did anybody try to suppress deprecation warnings and notices? At least according to the PHP changelog those warnings are not fatal. E.g. change "error_reporting = E_ALL & ~E_DEPRECATED" in you php.ini, or simply set it to E_ERROR. (I was able to install and run nextcloud this way; so we might not need patches if warnings are ignored)

@Pierre: I'm not convinced suppressing the warnings is the way forward here, as they indicate other underlying issues that may lead to all sorts of problems if simply ignored. I do not think that is a fix we should endorse at all.

Additionally, if untreated, these warnings spam the application's log and make it really hard to figure out what's going on or lead to huge log files.

You are correct, this workaround is far from great. On the other hand I am not sure if the upstream patches are any better; adding "ReturnTypeWillChange" is more or less ignoring errors :-)

If you actually disable deprecation notices they wont be logged. It might be possible that Nextclouds re-enables those warnings and logs them anyway.

Thanks David! 23.0.0-4 works fine and I didn't got a warning/error after hours of normal usage.

> adding "ReturnTypeWillChange" is more or less ignoring errors :-)

Yeah that seems so. At least that keyword only ignores warnings/errors from specific functions instead of globally.

using uwsgi, I'm getting fatal errors -

`Jan 23 21:24:53 server uwsgi[81310]: [pid: 81310|app: -1|req: -1/1] 10.0.0.10 () {56 vars in 1015 bytes} [Sun Jan 23 21:24:53 2022] GET / => generated 0 bytes in 1 msecs (HTTP/2.0 500) 2 headers in 103 bytes (0 switches on core 0)
Jan 23 21:24:53 server uwsgi[81310]: PHP Fatal error: Failed opening required 'loud/index.php' (include_path='.:') in Unknown on line 0
Jan 23 21:24:53 server uwsgi[81310]: PHP Warning: Unknown: Failed to open stream: No such file or directory in Unknown on line 0`

I don't know if `PHP Fatal error: Failed opening required 'loud/index.php'` is just being truncated or if it's actually attempting open only `loud/index.html` instead of `nextcloud/index.php`.

I do see a bug report issued for uwsgi having issues with php8.1 as well. Could just ask likely be related to that more than this, but historically, I've really had to babysit nextcloud so I'm starting here.

@slip I believe this to be  FS#73470  (which is due to an incompatibility of uwsgi-plugin-php with php 8.1).

You're right. For what it's worth, Nextcloud is working. I received an email from it today about it not being reachable. So it's working, I just can't access it. Thanks.

I think I have just fixed uwsgi-plugin-php with 2.0.20-5. Please test and verify, then I may also close this ticket :)

Just updated my system and can confirm Nextcloud (in conjunction withg PHP 8.1) is now working again with uWSGI and uWSGI's PHP plugin. Kudos to David.

Nevertheless with respect to https://github.com/unbit/uwsgi/issues/2287 I'm concidering to switch to php-fpm.

Please check whether these patches broke UTF-8 compatibility.
It definitely broke my installation.

I use TbSync and DAV-4-TbSync to sync calendar, tasks and contacts between Thunderbird and my Nextcloud installation (Nextcloud 23.0.0-4, MariaDB 10.6.5-2, PHP 8.1.2-1). If I create a contact with name "šđčćž" (quite common letters in Slavic languages), it gets saved as "šđčćž". As this happens, the same contact in Thunderbird changes to "šđčćž".

This happens not only with contacts, but with files which I sync from my Android phone.

I also noticed that if I create a file named "šđčćž" in Nextcloud folder on my desktop which syncs with the server, I can not delete this file from the Web interface. When I choose "delete file" it appears to be deleted, but as soon as I refresh the page it there again. Even if I manually delete the file on my server (at /var/nextcloud/<username>/files/ directory) it's still visible in Web interface. Only after I remove it from "oc_filecache" table, it's no more visible in Web interface.

I have tested the same Nextcloud version as Docker image and it works fine. No such issue (although I tested it with default SQLite database).

Regards!

System data:
https://nextcloud.ambraspace.com/index.php/s/TeS7sZiNK6w2MTE
Password: FwNYoX5HPH

@ambra This might be related to your database setup though. Please make sure that your database uses the correct character set and collation (see https://wiki.archlinux.org/title/Nextcloud#MariaDB ).

Hi, David!
I'm using the same database since Nextcloud version 19 or even earlier, and I've never had such issue.

All tables use CHARSET=utf8mb4 COLLATE=utf8mb4_bin.
You can check that at the link I provided in my previous comment.

After going through the patches I didn't see anything that might cause the problem.
Might be upstream problem.
I saw this in the PHP changelog (8.0 -> 8.1)

htmlspecialchars(), htmlentities(), htmlspecialchars_decode(), html_entity_decode(), and get_html_translation_table() now use ENT_QUOTES | ENT_SUBSTITUTE rather than ENT_COMPAT by default. This means that ' is escaped to &#039; while previously nothing was done. Additionally, malformed UTF-8 will be replaced by a Unicode substitution character, instead of resulting in an empty string.

I will check this.

Yes, I reverted to PHP 8, and the problem is gone...

@ambra: Thanks for verifying it! Just wanted to make sure.

Thanks for mentioning that upstream as well. Let's hope they are able to find a fix for that soon.

A somehow bad news - Nextcloud 24, the upcoming version expected to officially support PHP 8.1, is delayed

https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule