Bug #87953

SiteMatcher Warning: Use of undefined constant INTL_IDNA_VARIANT_UTS46

Added by Markus Pircher over 1 year ago. Updated 3 months ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Link Handling, Site Handling & Routing
Start date:
2019-03-19
Due date:
% Done:

100%

TYPO3 Version:
9
PHP Version:
7.2
Tags:
9.5.7
Complexity:
Is Regression:
Sprint Focus:

Description

With bugfix https://review.typo3.org/c/Packages/TYPO3.CMS/+/60232 SiteMatcher using idn_to_ascii().

On our system Typo3 9.5-dev not work with installed intl.
Our Server run with CPanel on CentOS 6, and only an old version of Intl is installed, and the constant INTL_IDNA_VARIANT_UTS46 not exist.

Bildschirmfoto 2019-03-20 um 08.59.59.png View (26.5 KB) Markus Pircher, 2019-03-20 09:00


Related issues

Related to TYPO3 Core - Bug #87090: Site module > Umlauts in domains not working with the new url handling / routing Closed 2018-12-06
Related to TYPO3 Core - Bug #87843: Unicode characters as entry point in site configurations Closed 2019-03-05
Related to TYPO3 Core - Task #90634: Allow latest guzzle versions Closed 2020-03-04

Associated revisions

Revision 0feb1eec (diff)
Added by Benni Mack over 1 year ago

[BUGFIX] Make php-intl work with older ICU versions

On old OS with ICU < 4.6, the constant INTL_IDNA_VARIANT_UTS46
is not available, even if php-intl is installed.

Therefore, a wrapper is created in HttpUtility to check
if the constant is available, then uses INTL_IDNA_VARIANT_UTS46
otherwise the 2003 version of the HttpUtility.

Also see the section about INTL_IDNA_VARIANT_UTS46 within
https://www.php.net/manual/en/intl.constants.php

Resolves: #87953
Releases: master, 9.5
Change-Id: I594c0ffd9afa115de595b0c027bf2474c3abfafb
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/60710
Reviewed-by: Sven Juergens <>
Reviewed-by: Kevin Meckl <>
Reviewed-by: Timo Poppinga <>
Reviewed-by: Andreas Fernandez <>
Tested-by: TYPO3com <>
Tested-by: Timo Poppinga <>
Tested-by: Andreas Fernandez <>

Revision 3a2b54a1 (diff)
Added by Benni Mack over 1 year ago

[BUGFIX] Make php-intl work with older ICU versions

On old OS with ICU < 4.6, the constant INTL_IDNA_VARIANT_UTS46
is not available, even if php-intl is installed.

Therefore, a wrapper is created in HttpUtility to check
if the constant is available, then uses INTL_IDNA_VARIANT_UTS46
otherwise the 2003 version of the HttpUtility.

Also see the section about INTL_IDNA_VARIANT_UTS46 within
https://www.php.net/manual/en/intl.constants.php

Resolves: #87953
Releases: master, 9.5
Change-Id: I594c0ffd9afa115de595b0c027bf2474c3abfafb
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/60711
Reviewed-by: Sven Juergens <>
Reviewed-by: Kevin Meckl <>
Reviewed-by: Timo Poppinga <>
Reviewed-by: Andreas Fernandez <>
Tested-by: TYPO3com <>
Tested-by: Timo Poppinga <>
Tested-by: Andreas Fernandez <>

Revision 59d5159a (diff)
Added by Benni Mack 11 months ago

[BUGFIX] Mark guzzlehttp/guzzle >= 6.5.0 as conflict

Due to the INTL/ICU bug, which we
have seen on various places, Guzzle, which
does not cover our edge cases yet, ran
in the same issue as our Core versions earlier
in 2019.

See
https://github.com/guzzle/guzzle/issues/2448
https://github.com/guzzle/guzzle/pull/2454

For the time being, lets mark guzzle as
incompatible until Guzzle has solved the issue
and released a new version, so we can loosen
the conflict constraint.

Related: #87953
Resolves: #89904
Releases: master, 9.5, 8.7
Change-Id: If64fb9472d046f020c850cd0551beeaf78796b60
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/62606
Tested-by: TYPO3com <>
Tested-by: Oliver Hader <>
Reviewed-by: Oliver Hader <>

Revision 4a8e8001 (diff)
Added by Benni Mack 11 months ago

[BUGFIX] Mark guzzlehttp/guzzle >= 6.5.0 as conflict

Due to the INTL/ICU bug, which we
have seen on various places, Guzzle, which
does not cover our edge cases yet, ran
in the same issue as our Core versions earlier
in 2019.

See
https://github.com/guzzle/guzzle/issues/2448
https://github.com/guzzle/guzzle/pull/2454

For the time being, lets mark guzzle as
incompatible until Guzzle has solved the issue
and released a new version, so we can loosen
the conflict constraint.

Related: #87953
Resolves: #89904
Releases: master, 9.5, 8.7
Change-Id: If64fb9472d046f020c850cd0551beeaf78796b60
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/62612
Tested-by: TYPO3com <>
Tested-by: Oliver Hader <>
Reviewed-by: Oliver Hader <>

Revision bb11a3e0 (diff)
Added by Benni Mack 11 months ago

[BUGFIX] Mark guzzlehttp/guzzle >= 6.5.0 as conflict

Due to the INTL/ICU bug, which we
have seen on various places, Guzzle, which
does not cover our edge cases yet, ran
in the same issue as our Core versions earlier
in 2019.

See
https://github.com/guzzle/guzzle/issues/2448
https://github.com/guzzle/guzzle/pull/2454

For the time being, lets mark guzzle as
incompatible until Guzzle has solved the issue
and released a new version, so we can loosen
the conflict constraint.

Related: #87953
Resolves: #89904
Releases: master, 9.5, 8.7
Change-Id: If64fb9472d046f020c850cd0551beeaf78796b60
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/62613
Tested-by: TYPO3com <>
Tested-by: Oliver Hader <>
Reviewed-by: Oliver Hader <>

History

#1 Updated by Benni Mack over 1 year ago

Hey Markus,

thanks for the report. We've provided the symfony/polyfill-intl-idn package with it. Is it possible that you set up the project via composer and forgot to trigger a "composer update" after fetching it via composer? Can you check if a folder "vendor/symfony/polyfill-intl-idn" exists in your installation?

#2 Updated by Benni Mack over 1 year ago

  • Status changed from New to Needs Feedback

#3 Updated by Markus Pircher over 1 year ago

The polyfill is installed, but is not active because the native intl version exists.

With a blank PHP this work:
idn_to_ascii('localhost', IDNA_DEFAULT, INTL_IDNA_VARIANT_2003);
but it's give me an message:
"PHP Deprecated: idn_to_ascii(): INTL_IDNA_VARIANT_2003 is deprecated"

If i define the INTL_IDNA_VARIANT_UTS46 manually, with 1, idn_to_ascii() returns false.

Is probably an edge case with old OS and new PHP version.

#4 Updated by Benni Mack over 1 year ago

ha, my best guess is that the compiled intl version does not (yet) support the new variant - very strange.

Can you give me details on the installed intl version (from phpinfo())?

#6 Updated by Oliver Hader over 1 year ago

  • Related to Bug #87090: Site module > Umlauts in domains not working with the new url handling / routing added

#7 Updated by Oliver Hader over 1 year ago

  • Related to Bug #87843: Unicode characters as entry point in site configurations added

#8 Updated by Gerrit Code Review over 1 year ago

  • Status changed from Needs Feedback to Under Review

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/60710

#9 Updated by Gerrit Code Review over 1 year ago

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/60710

#10 Updated by Gerrit Code Review over 1 year ago

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/60710

#11 Updated by Gerrit Code Review over 1 year ago

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/60710

#12 Updated by Gerrit Code Review over 1 year ago

Patch set 1 for branch 9.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/60711

#13 Updated by Benni Mack over 1 year ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100

#14 Updated by Nikolas Hagelstein over 1 year ago

Note:

Some Hosters e.g. Mittwald do run new PHP versions with old intl/icu.

E.g.:
PHP 7.2 + ICU 4.4.1
PHP 7.3 + ICU 4.4.1

This will make you end up running it a "intl_idna_variant_2003 is deprecated" - Exception if you apply that patch.
This is because idn_to_ascii is deprecated in PHP 7.2

To suppress the php deprecation notice change:

return idn_to_ascii($domain);
to
return @idn_to_ascii($domain);

Hope that helps

#15 Updated by Benni Mack over 1 year ago

  • Status changed from Resolved to Closed

#16 Updated by Martin Basgier over 1 year ago

  • Tags set to 9.5.7

Running TYPO3 9.5.7 on a Mittwald machine, this problem is not resolved it just throws another error now as already predicted here:

As already described in comment #14 (thx) the error/ warning message just gets exchanged in the latest TYPO3 version and now warns:
"intl_idna_variant_2003 is deprecated"
This is because idn_to_ascii is deprecated in PHP 7.2

To suppress the php deprecation notice change in typo3/sysext/core/Classes/Utility/HttpUtility.php line 198:

return idn_to_ascii($domain);
to
return @idn_to_ascii($domain);

Nevertheless these instructions require manual patching of TYPO3 core files, which is not recommended to do to avoid problems with future updates.
Therefore the question, can this please be fixed, either by Mittwald updating their ICU version or by a workaround being included in the next TYPO3 9.x update?

P.S.: I would consider this bug report as not closed, as it is only partially fixed. I hope you agree.

#17 Updated by Nikolas Hagelstein over 1 year ago

Martin Basgier wrote:

Running TYPO3 9.5.7 on a Mittwald machine, this problem is not resolved it just throws another error now as already predicted here:

U can just suppress deprecated notices resulting in exceptions by setting:
$GLOBALS['TYPO3_CONF_VARS']['SYS']['exceptionalErrors'] = 8191;
(deprecation is 8192)

Regarding Mittwald:
I v a ticket open and guys r working at that problem.

#18 Updated by Martin Basgier over 1 year ago

Nikolas Hagelstein wrote:

Martin Basgier wrote:

Running TYPO3 9.5.7 on a Mittwald machine, this problem is not resolved it just throws another error now as already predicted here:

U can just suppress deprecated notices resulting in exceptions by setting:
$GLOBALS['TYPO3_CONF_VARS']['SYS']['exceptionalErrors'] = 8191;
(deprecation is 8192)

Regarding Mittwald:
I v a ticket open and guys r working at that problem.

Thanks for the additional information. I would be very interested once you hear back from Mittwald, what is their planned course of action. They position themself (beneath others) as TYPO3 Hoster and now they are trying to patch their way around outdated libraries.... Looking forward for any update on this. TY :)

#19 Updated by Attila Glück over 1 year ago

I can confirm this issue by Mittwald

#20 Updated by Webtech AG over 1 year ago

I also can firm this issue by Mittwald. By default for TYPO3 V9.5 there is PHP V7.2 and ICU V4.4.1 installed.

#21 Updated by Marc Willmann over 1 year ago

I second that. Also Mttwald, TYPO3 9.5.7, but PHP 7.3.2

#22 Updated by Markus Klein 7 months ago

  • Related to Task #90634: Allow latest guzzle versions added

#23 Updated by Josef Glatz 3 months ago

Just for the records for other Mittwald customers

We have an "older" Agentur Server package (managed v-server) where we have multiple p-Accounts at Mittwald.

As of today I only get an actual ICU Lib version IF I DON't use PHP-FPM with APCu. I have to switch "back" to FastCGI PHP implementation to get an actual ICU lib version. A precise point in time cannot be communicated when these are also available in such a Mittwald package.

#24 Updated by Jan Delius 3 months ago

Josef Glatz wrote:

Just for the records for other Mittwald customers

We have an "older" Agentur Server package (managed v-server) where we have multiple p-Accounts at Mittwald.

As of today I only get an actual ICU Lib version IF I DON't use PHP-FPM with APCu. I have to switch "back" to FastCGI PHP implementation to get an actual ICU lib version. A precise point in time cannot be communicated when these are also available in such a Mittwald package.

I can confirm that this setting works as a workaround, even if it is not the best solution.

Also available in: Atom PDF