-
-
Notifications
You must be signed in to change notification settings - Fork 139
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] polyfill-intl-idn breaks on large hoster installation #278
Comments
Well, the extra checks being added are necessary: if the extension is loaded and provides the functions, defining the constants will still not make them work (as the function being called would be the one from the extension, not the one from the polyfill). If your project has to support runtimes providing ext-intl but with totally outdated ICU versions, the polyfill won't save you and you will have to deal with the fact that some features (for instance, the UTS46 variant) will be missing. PHP makes it impossible to polyfill incomplete implementations (we cannot replace functions coming from extensions as we cannot replace an already declared function). IMO, reverting the check would actually make things worse than today, as the feature will still not work but you won't be able to feature-detect it (maybe you did not realized before that the feature was not working for such setup even though the constant was defined). |
@bmack do the missing constants still work as expected when passed as values with the functions provided by this strange build of the extension? Are there also missing functions or does this only apply to constants? We could polyfill the constants if they work as expected when passed to the functions. |
Well, the discussion in #262 which made us add this check tells me that the |
Yes. I'm (personally) fine with locking to 1.17.0 for the time being until the hoster has sorted out their issues, as this polyfill should IMHO contain a "full replacement" and not a "partial replacement", which would make tests much more complicated - plus I don't even know how they compiled it in the first place (that's what makes it so hard for me to reproduce in general). Thanks for replying and supporting, I appreciate your time on this, but I'm pretty sure you have more important things to do. |
@bmack as said before, we can only polyfill missing functions, not incomplete implementations of functions. As PHP does not allow replacing existing functions, it is simply impossible to build such a polyfill in userland (and if we were to build a C extension to polyfill another C extension, that would be insane). Deciding that we delete the polyfill entirely because we can only solve the case of not having ext-intl but not the case of having an outdated ext-intl would not improve the ecosystem. Locking to 1.17.0 will probably not solve the issue for your case: the constant is defined in 1.17.0, but the feature still does not work when using |
Got some more details: We previously checked for the constant Line 148 in aa691e9
|
Well, calling the But we might want to use |
@stof so true! I hope it becomes clear, but just saying it again, I didn't expect this to be a "Hey, this is a BC break" discussion, I'm grateful for all the work you've but in there, so calling |
@nicolas-grekas should we update the Idn class to use a class constant for the |
That would be great. I can provide a PR (and test it on this hoster setup) if you agree on pushing this forward. |
Works for me, PR welcome. |
Correct, the |
We use the intl-idn package in TYPO3 CMS and it helps a lot! Thank you for providing such a package.
However there is one large TYPO3 hoster (having roughly 200.000 TYPO3 installations), where they have a messed up Server setup regarding to ICU version on their system. In short: They provide the php-intl extension, but do not define all constants as needed for PHP 7.2+. We had solved this issue in the past by a hard workaround, but with the update to polyfill-intl-idn 1.17.1 and 1.18.0 then (respective change) symfony/polyfill-intl-idn@3bff59e (or f968149#diff-eaa55ac0b04a1928e5455b4f48efe417R14-R17) our setups don't work on the hoster anymore, as they clearly have a misconfiguration.
Still, the previous solution when not checking on the
extension_loaded()
was more robust for these kind of weird setups.In any case, I'm (personally) fine if you decide to keep the
extension_loaded()
check in your library, but wanted to let you know that this actually is an issue for a lot of people. It would be great to know if you're able to fix it or planning to fix/revert the three lines or if we should find a workaround for ourselves in our project.The text was updated successfully, but these errors were encountered: