Fatal Error: Call to undefined function idna_maps_not_std3

[Sesquipedalian]

Rather than the SMF version number in the files, look at the Unicode version number in ./Sources/Unicode/Metadata.php. If that says you are using Unicode 16, then you are up to date.

[MobileCS]

Thank you, it does show Unicode 16.

[Sesquipedalian]

Good. You probably won't see the error again, then. The Unicode update process checks whether an update is even needed (and aborts if not) before it ever gets to the part where it checks whether the files are writable. My guess is that the process failed a few times on your server due to unwritable files, but in your more recent attempts to deal with it you left the files writable long enough to let it complete successfully and now it won't give you any more errors.

[Sesquipedalian]

The unicode tables are now updated straight from the source.  Part of the weekly maintenance task.

But the unicode folks made a huge change in direction in a recent revision (#33) of unicode 6 - while the smf code is operating under the prior rules. 

I'm sure your knowledge in this area goes way beyond mine but I can't wrap my head around why the issue as described didn't take out every SMF forum on the planet.

I'm sure your knowledge in this area goes way beyond mine but I can't wrap my head around why the issue as described didn't take out every SMF forum on the planet.

I'm actually at the other end of that spectrum...  I'm unclear how it's taking out sites at all.  The issue is specific to Punycode usage, and even then to a specific subset of characters.  I could see that possibly affecting some posts with Punycode links, etc. 

But take down a site?  Maybe if folks are using Punycode in their boardurls?  I haven't applied the fix to any of my test environments and they're all fine.

The issue will only arise on servers that do not have PHP's intl extension installed. That extension provides a number of important functions for handling Unicode characters, but not all servers have it installed. A big part of the reason that SMF downloads and compiles Unicode data files is to provide fallback support for those servers. (There are other reasons, too, but those are not relevant here.)

In particular, the intl extension provides the idn_to_ascii and idn_to_utf8 functions that allow PHP to handle URLs with domain names containing non-ASCII characters. Because we know that SMF will often be installed on servers that don't have that extension, we include the Punycode class to provide fallback for those two functions on those servers.

The problem happens because the Punycode class in SMF 2.1.6 assumes that a function named idna_maps_not_std3 will exist in SMF's Unicode data files. But because the underlying data that the idna_maps_not_std3 function is built from was removed in Unicode 16, the function doesn't get created when the new data files are compiled. So when the Punycode class tries to call it, an error about an undefined function occurs.

The fix coming in SMF 2.1.7 updates the Punycode class to remove the call to this function and instead implements the Unicode Consortium's recommended new way of handling the job that the now-removed data was meant to handle. We've also made a tweak to the way the the Unicode data files are compiled so that if a situation like this happens again (i.e. a future Unicode version removing some previously expected data), the function for dealing with that data will still be created even if it has empty content.

[MobileCS]

I'm still getting this message even though I'm up to date.

Code Select Expand

A new version of Unicode is available, but SMF could not update to it. Please make sure /www/example.com/httpdocs/forum/Sources/Unicode and all the files in it are writable. SMF will try to update its Unicode data files again automatically.
I do see a ReadMe.txt file in /tmp/Unicode/ucd/ - nothing else.

Code Select Expand

$ more ReadMe.txt
# Unicode Character Database
# Date: 2024-08-25
# © 2024 Unicode®, Inc.
# Unicode and the Unicode Logo are registered trademarks of Unicode, Inc. in the U.S. and other countries.
# For terms of use and license, see https://www.unicode.org/terms_of_use.html
#
# For documentation, see the following:
# NamesList.html
# UAX #38, "Unicode Han Database (Unihan)"
# UAX #44, "Unicode Character Database"
# UTS #51, "Unicode Emoji"
# UAX #57, "Unicode Egyptian Hieroglyph Database"
#
# The UAXes and UTS #51 can be accessed at https://www.unicode.org/versions/Unicode16.0.0/

This directory contains final data files
for the Unicode Character Database, for Version 16.0.0 of the Unicode Standard.

[shawnb61]

I'm still getting this message even though I'm up to date.

It needs to go thru the motions & download & inspect the remote files, etc.  So I'd bet that you're going to see that error once a week, whenever the folders are protected.

[un_vizitator]

a quicker and easier fix is to enable "intl" extensions in the php selector from hosting control panel

[Sesquipedalian]

a quicker and easier fix is to enable "intl" extensions in the php selector from hosting control panel

That is the ideal solution. Unfortunately, not all forum admins have the ability to do so.

[MobileCS]

I could enable "intl", but I'm trying to keep the PHP memory footprint as low as possible. That extension will add 10-20mb per process, which adds up quick if you have hundreds of processes running.