On 12/16/25 1:14 PM, David C Rankin wrote:
On 12/10/25 10:11 AM, David C Rankin wrote:
On 12/10/25 9:56 AM, Andy Pieters wrote:
To me this looks more like a bug in the nextcloud rather than PHP
I did see a ticket being opened on nextcloud talking about this same thing, presume this was yourself?
Yes, that's the ticket I opened with Nextcloud:
https://help.nextcloud.com/t/nextcloud-32-call-to-undefined-function- oc- security-idn-to-utf8/237090
No response yet, but not two-days old yet. I'll keep you posted here if I get a solution there.
I'm going to bump this thread again. I've had no response in 8-days on the nextcloud support list. Usually they get back quicker if it's an issue that is more widespread or they have a fix for.
Is there any way the minor version update in php-legacy from 8.2 to 8.3 could be the culprit? Is this worth opening an issue with either nextcloud or php-legacy at gitlab, if for nothing else to track upstream progress?
Nextcloud 33 is out, so the lack of response on the support forum could be a "wait until 33 is installed and see if the same thing occurs". Which I can do. It's just the admin functions that are broken by the idn_to_utf8() issue. I can get to the data and normal user apps. And since I use the Arch nextcloud package, I can upgrade without relying on the nextcloud admin functions.
If any of the devs have a preference in course of action, let me know, otherwise, I'll just wait for the 33 package and see if the issue remains. (no hurry, holiday season is busy for everyone)
There was a nextcloud issue in 32.0.2, that has magically resolved in 32.0.3. The idn_to_utf8() undefined problem has now vanished. However, there are new errors with APIApp (an external app that uses docker that was included and enabled by default by nextcloud) - the help forum is full of questions about that. Simply disabling the apps takes care of that problem. The file integrity scan flags the .htaccess file and the normal work around of adding 'integrity.check.disabled' => true, to config.php, choosing rescan and then logging out/in and then removing 'integrity.check.disabled' => true, no longer resets the hash for the file. Anybody know a new workaround for that? I'll start a new thread on nextcloud support for that, it's an annoyance when the Admin security scan runs, but otherwise it's harmless. In the daisy-chain of php.ini files between the normal php install and the nextcloud web-app install, bcmath throws an error that it is already enabled. I've been through the php php.ini and php-fpm.ini and the nextcloud php.ini and config.php files and I can't determine which one nextcloud is complaining about or in which of those four configs is the proper place to ensure it is enabled and that nextcloud can see the extension is loaded, but only once?? Another annoyance, but otherwise harmless. If anybody has insight into the integrity scan hash reset for the .htaccess file or the bcmath already loaded issue, let me know. Otherwise this thread is done, I can access the admin settings again and idn_to_utf8() is defined again. -- David C. Rankin, J.D.,P.E.