could we suffer from issues on PHP 8 due to other libraries changing such global state too ? Or is PHP 8 turning that into a no-op ?

@stof I don't think so, we will suffer from the same issue.

a solution could be to implement a method by our self that check the status of the entity loader and use this instead of checking the version.
note: libxml_disable_entity_loader is used in 5 components

could we suffer from issues on PHP 8 due to other libraries changing such global state too ?

Yes, this change only buys us some time. The main problem is that php 8 triggers a seprecation without offering us an alternative.

Or is PHP 8 turning that into a no-op ?

As far as I understood it, the functionality is the same.

@jderusse The PR title tells quite the opposite of what this PR is doing. 😉

Yes, this change only buys us some time. The main problem is that php 8 triggers a seprecation without offering us an alternative.

Then this should be reported to PHP before the release of PHP 8. Deprecating an API without an alternative is not OK.

Yes, this change only buys us some time. The main problem is that php 8 triggers a seprecation without offering us an alternative.

Then this should be reported to PHP before the release of PHP 8. Deprecating an API without an alternative is not OK.

This is deprecated, because nobody should call it in PHP >= 8.
BUT if somebody call it, you have to revert the call, and you can't do it without triggering a deprecation.

This is deprecated, because nobody should call it in PHP >= 8.
BUT if somebody call it, you have to revert the call, and you can't do it without triggering a deprecation.

That's precisely the issue. As it is deprecated without being a no-op, it still affects the global state for everyone. And so shared libraries (which cannot know what else is running in the project) cannot assume the global state and so are forced to keep calling the deprecated API. And that makes the deprecation warning an issue.
In practice, Symfony on PHP 8 is still not reliably working even after this PR, because it assumes that no other code is using the deprecated API.

Bug opened https://bugs.php.net/bug.php?id=80357

Bug opened https://bugs.php.net/bug.php?id=80357

Thank you. 😃

I changed the patch to

1. let previous code about libxml_disable_entity_loader(true)

Disabling entity loaded is not needed sin libXml 2.9 (this is the reason on the deprecation in PHP 8 by the way).
We don't have to disable it on our side (whether or not it's previously disabled, it won't changed our code).

2. Silent deprecation triggered by libxml_disable_entity_loader(false)

FALSE is default value, and Symfony need it (cf #39040). Given we can't do it without triggering a deprecation we shoud silent it, as suggested in https://bugs.php.net/bug.php?id=80357

3. Stop calling libxml_disable_entity_loader(false) after PHP 9

Because the method is deprecated in 8.0 and we are still calling it with @ sign, we should prevent calling it afterward.

So, it's silencing now according to the feedback we've received? Well okay, let's silence the error then.

I don't know if PHP 8 will fix the issue, I the meantime, I suggest this patch that check if the entity loader is disabled by trying to validate a wellknown document

PHP won't fix the issue as PHP 8 is now released. Let's merge this one then.

Thank you @jderusse.

There may be more places that require a fix, i.e.

• https://github.com/symfony/config/blob/5.x/Util/XmlUtils.php#L55
• https://github.com/symfony/dom-crawler/blob/5.x/Crawler.php#L233

These 2 lines are about disabling the entity_loader which is not needed, because disabled by default since LIBXML_VERSION 2.9

This PR is about enabling the entity_loader in case somebody disabled it.