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.
