[DependencyInjection] Ensure deprecation detection does not trigger a PHP error #62544
+25
−1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
7fccf18 to
e74ddd9
Compare
ea76884 to
31de844
Compare
stof
reviewed
Dec 1, 2025
src/Symfony/Component/DependencyInjection/Tests/Compiler/ResolveClassPassTest.php
Outdated
Show resolved
Hide resolved
reviewtypo3org
pushed a commit
to TYPO3/typo3
that referenced
this pull request
Dec 1, 2025
Symfony DI added [1] a non-optional `class_exists()` check in `Symfony\Component\DependencyInjection\Compiler\ResolveClassPass` for the versions >=7.4 (including 8.0), which is no longer guarded by a previous `$definition instanceof ChildDefinition` condition. This causes PHP errors when classes are (tried to be) autoloaded, that implement interfaces which are not available (because they use them as an optional dependency, like optional EXT:reports integration). The change was initially implemented as a breaking change, but was intended to be lifted to be only a deprecation later [2]. This relaxation works for classes that are not available at all, but not for classes that are available from a autoloader perspective, but whose static dependencies are not and are therefore not loadable. As a solution we revert to the old class resolution algorithm from v7.3 and enqueue this overwrite for the upstream class resolution compiler pass, which makes the upstream compiler pass a no-op. An upstream fix is hopefully added later on via: symfony/symfony#62544 [1] symfony/symfony#61215 [2] symfony/symfony#62544 Releases: main, 13.4, 12.4 Resolves: #108349 Change-Id: I5d55bfdc21caf4aece95f662e21918dd3494ad58 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/91943 Tested-by: Benjamin Franzke <ben@bnf.dev> Reviewed-by: Benjamin Franzke <ben@bnf.dev> Tested-by: Moritz Ngo <moritz.ngo@kandoh.de> Tested-by: core-ci <typo3@b13.com> Reviewed-by: Moritz Ngo <moritz.ngo@kandoh.de>
reviewtypo3org
pushed a commit
to TYPO3/typo3
that referenced
this pull request
Dec 1, 2025
Symfony DI added [1] a non-optional `class_exists()` check in `Symfony\Component\DependencyInjection\Compiler\ResolveClassPass` for the versions >=7.4 (including 8.0), which is no longer guarded by a previous `$definition instanceof ChildDefinition` condition. This causes PHP errors when classes are (tried to be) autoloaded, that implement interfaces which are not available (because they use them as an optional dependency, like optional EXT:reports integration). The change was initially implemented as a breaking change, but was intended to be lifted to be only a deprecation later [2]. This relaxation works for classes that are not available at all, but not for classes that are available from a autoloader perspective, but whose static dependencies are not and are therefore not loadable. As a solution we revert to the old class resolution algorithm from v7.3 and enqueue this overwrite for the upstream class resolution compiler pass, which makes the upstream compiler pass a no-op. An upstream fix is hopefully added later on via: symfony/symfony#62544 [1] symfony/symfony#61215 [2] symfony/symfony#62544 Releases: main, 13.4, 12.4 Resolves: #108349 Change-Id: I5d55bfdc21caf4aece95f662e21918dd3494ad58 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/91941 Tested-by: Moritz Ngo <moritz.ngo@kandoh.de> Reviewed-by: Benjamin Franzke <ben@bnf.dev> Tested-by: core-ci <typo3@b13.com> Reviewed-by: Moritz Ngo <moritz.ngo@kandoh.de> Tested-by: Benjamin Franzke <ben@bnf.dev>
reviewtypo3org
pushed a commit
to TYPO3/typo3
that referenced
this pull request
Dec 1, 2025
Symfony DI added [1] a non-optional `class_exists()` check in `Symfony\Component\DependencyInjection\Compiler\ResolveClassPass` for the versions >=7.4 (including 8.0), which is no longer guarded by a previous `$definition instanceof ChildDefinition` condition. This causes PHP errors when classes are (tried to be) autoloaded, that implement interfaces which are not available (because they use them as an optional dependency, like optional EXT:reports integration). The change was initially implemented as a breaking change, but was intended to be lifted to be only a deprecation later [2]. This relaxation works for classes that are not available at all, but not for classes that are available from a autoloader perspective, but whose static dependencies are not and are therefore not loadable. As a solution we revert to the old class resolution algorithm from v7.3 and enqueue this overwrite for the upstream class resolution compiler pass, which makes the upstream compiler pass a no-op. An upstream fix is hopefully added later on via: symfony/symfony#62544 [1] symfony/symfony#61215 [2] symfony/symfony#62544 Releases: main, 13.4, 12.4 Resolves: #108349 Change-Id: I5d55bfdc21caf4aece95f662e21918dd3494ad58 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/91926 Tested-by: Achim Fritz <af@achimfritz.de> Reviewed-by: Benjamin Franzke <ben@bnf.dev> Tested-by: core-ci <typo3@b13.com> Tested-by: Markus Klein <markus.klein@typo3.org> Reviewed-by: Markus Klein <markus.klein@typo3.org> Tested-by: Stefan Bürk <stefan@buerk.tech> Tested-by: Stephan Großberndt <stephan.grossberndt@typo3.org> Reviewed-by: Stefan Bürk <stefan@buerk.tech> Tested-by: Benjamin Franzke <ben@bnf.dev>
TYPO3IncTeam
pushed a commit
to TYPO3-CMS/core
that referenced
this pull request
Dec 1, 2025
Symfony DI added [1] a non-optional `class_exists()` check in `Symfony\Component\DependencyInjection\Compiler\ResolveClassPass` for the versions >=7.4 (including 8.0), which is no longer guarded by a previous `$definition instanceof ChildDefinition` condition. This causes PHP errors when classes are (tried to be) autoloaded, that implement interfaces which are not available (because they use them as an optional dependency, like optional EXT:reports integration). The change was initially implemented as a breaking change, but was intended to be lifted to be only a deprecation later [2]. This relaxation works for classes that are not available at all, but not for classes that are available from a autoloader perspective, but whose static dependencies are not and are therefore not loadable. As a solution we revert to the old class resolution algorithm from v7.3 and enqueue this overwrite for the upstream class resolution compiler pass, which makes the upstream compiler pass a no-op. An upstream fix is hopefully added later on via: symfony/symfony#62544 [1] symfony/symfony#61215 [2] symfony/symfony#62544 Releases: main, 13.4, 12.4 Resolves: #108349 Change-Id: I5d55bfdc21caf4aece95f662e21918dd3494ad58 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/91943 Tested-by: Benjamin Franzke <ben@bnf.dev> Reviewed-by: Benjamin Franzke <ben@bnf.dev> Tested-by: Moritz Ngo <moritz.ngo@kandoh.de> Tested-by: core-ci <typo3@b13.com> Reviewed-by: Moritz Ngo <moritz.ngo@kandoh.de>
TYPO3IncTeam
pushed a commit
to TYPO3-CMS/core
that referenced
this pull request
Dec 1, 2025
Symfony DI added [1] a non-optional `class_exists()` check in `Symfony\Component\DependencyInjection\Compiler\ResolveClassPass` for the versions >=7.4 (including 8.0), which is no longer guarded by a previous `$definition instanceof ChildDefinition` condition. This causes PHP errors when classes are (tried to be) autoloaded, that implement interfaces which are not available (because they use them as an optional dependency, like optional EXT:reports integration). The change was initially implemented as a breaking change, but was intended to be lifted to be only a deprecation later [2]. This relaxation works for classes that are not available at all, but not for classes that are available from a autoloader perspective, but whose static dependencies are not and are therefore not loadable. As a solution we revert to the old class resolution algorithm from v7.3 and enqueue this overwrite for the upstream class resolution compiler pass, which makes the upstream compiler pass a no-op. An upstream fix is hopefully added later on via: symfony/symfony#62544 [1] symfony/symfony#61215 [2] symfony/symfony#62544 Releases: main, 13.4, 12.4 Resolves: #108349 Change-Id: I5d55bfdc21caf4aece95f662e21918dd3494ad58 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/91941 Tested-by: Moritz Ngo <moritz.ngo@kandoh.de> Reviewed-by: Benjamin Franzke <ben@bnf.dev> Tested-by: core-ci <typo3@b13.com> Reviewed-by: Moritz Ngo <moritz.ngo@kandoh.de> Tested-by: Benjamin Franzke <ben@bnf.dev>
TYPO3IncTeam
pushed a commit
to TYPO3-CMS/core
that referenced
this pull request
Dec 1, 2025
Symfony DI added [1] a non-optional `class_exists()` check in `Symfony\Component\DependencyInjection\Compiler\ResolveClassPass` for the versions >=7.4 (including 8.0), which is no longer guarded by a previous `$definition instanceof ChildDefinition` condition. This causes PHP errors when classes are (tried to be) autoloaded, that implement interfaces which are not available (because they use them as an optional dependency, like optional EXT:reports integration). The change was initially implemented as a breaking change, but was intended to be lifted to be only a deprecation later [2]. This relaxation works for classes that are not available at all, but not for classes that are available from a autoloader perspective, but whose static dependencies are not and are therefore not loadable. As a solution we revert to the old class resolution algorithm from v7.3 and enqueue this overwrite for the upstream class resolution compiler pass, which makes the upstream compiler pass a no-op. An upstream fix is hopefully added later on via: symfony/symfony#62544 [1] symfony/symfony#61215 [2] symfony/symfony#62544 Releases: main, 13.4, 12.4 Resolves: #108349 Change-Id: I5d55bfdc21caf4aece95f662e21918dd3494ad58 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/91926 Tested-by: Achim Fritz <af@achimfritz.de> Reviewed-by: Benjamin Franzke <ben@bnf.dev> Tested-by: core-ci <typo3@b13.com> Tested-by: Markus Klein <markus.klein@typo3.org> Reviewed-by: Markus Klein <markus.klein@typo3.org> Tested-by: Stefan Bürk <stefan@buerk.tech> Tested-by: Stephan Großberndt <stephan.grossberndt@typo3.org> Reviewed-by: Stefan Bürk <stefan@buerk.tech> Tested-by: Benjamin Franzke <ben@bnf.dev>
31de844 to
767565d
Compare
oliverklee
added a commit
to TYPO3BestPractices/tea
that referenced
this pull request
Dec 1, 2025
symfony/dependency-injection 7.4.0 introduced a backwards-imcompatible change that triggered PHP errors with the current versions of TYPO3 12LTS and 13LTS. Until the bug is fixed in symfony/dependency-injection or until the workarounds in the TYPO3 Core are released, we need to avoid installing symfony/dependency-injection 7.4.0. symfony/symfony#62544 https://review.typo3.org/c/Packages/TYPO3.CMS/+/91926
oliverklee
added a commit
to TYPO3BestPractices/tea
that referenced
this pull request
Dec 1, 2025
symfony/dependency-injection 7.4.0 introduced a backwards-imcompatible change that triggered PHP errors with the current versions of TYPO3 12LTS and 13LTS. Until the bug is fixed in symfony/dependency-injection or until the workarounds in the TYPO3 Core are released, we need to avoid installing symfony/dependency-injection 7.4.0. symfony/symfony#62544 https://review.typo3.org/c/Packages/TYPO3.CMS/+/91926
oliverklee
added a commit
to oliverklee/TYPO3-testing-distribution
that referenced
this pull request
Dec 1, 2025
symfony/dependency-injection 7.4.0 introduced a backwards-imcompatible change that triggered PHP errors with the current versions of TYPO3 12LTS and 13LTS. Until the bug is fixed in symfony/dependency-injection or until the workarounds in the TYPO3 Core are released, we need to avoid installing symfony/dependency-injection 7.4.0. symfony/symfony#62544 https://forge.typo3.org/issues/108349
oliverklee
added a commit
to oliverklee/TYPO3-testing-distribution
that referenced
this pull request
Dec 1, 2025
symfony/dependency-injection 7.4.0 introduced a backwards-imcompatible change that triggered PHP errors with the current versions of TYPO3 12LTS and 13LTS. Until the bug is fixed in symfony/dependency-injection or until the workarounds in the TYPO3 Core are released, we need to avoid installing symfony/dependency-injection 7.4.0. symfony/symfony#62544 https://forge.typo3.org/issues/108349
oliverklee
added a commit
to oliverklee/TYPO3-testing-distribution
that referenced
this pull request
Dec 1, 2025
symfony/dependency-injection 7.4.0 introduced a backwards-imcompatible change that triggered PHP errors with the current versions of TYPO3 12LTS and 13LTS. Until the bug is fixed in symfony/dependency-injection or until the workarounds in the TYPO3 Core are released, we need to avoid installing symfony/dependency-injection 7.4.0. symfony/symfony#62544 https://forge.typo3.org/issues/108349
oliverklee
added a commit
to oliverklee/TYPO3-testing-distribution
that referenced
this pull request
Dec 1, 2025
symfony/dependency-injection 7.4.0 introduced a backwards-imcompatible change that triggered PHP errors with the current versions of TYPO3 12LTS and 13LTS. Until the bug is fixed in symfony/dependency-injection or until the workarounds in the TYPO3 Core are released, we need to avoid installing symfony/dependency-injection 7.4.0. symfony/symfony#62544 https://forge.typo3.org/issues/108349
oliverklee
added a commit
to oliverklee/TYPO3-testing-distribution
that referenced
this pull request
Dec 1, 2025
symfony/dependency-injection 7.4.0 introduced a backwards-imcompatible change that triggered PHP errors with the current versions of TYPO3 12LTS and 13LTS. Until the bug is fixed in symfony/dependency-injection or until the workarounds in the TYPO3 Core are released, we need to avoid installing symfony/dependency-injection 7.4.0. symfony/symfony#62544 https://forge.typo3.org/issues/108349
oliverklee
added a commit
to oliverklee/TYPO3-testing-distribution
that referenced
this pull request
Dec 1, 2025
symfony/dependency-injection 7.4.0 introduced a backwards-imcompatible change that triggered PHP errors with the current versions of TYPO3 12LTS and 13LTS. Until the bug is fixed in symfony/dependency-injection or until the workarounds in the TYPO3 Core are released, we need to avoid installing symfony/dependency-injection 7.4.0. symfony/symfony#62544 https://forge.typo3.org/issues/108349
oliverklee
added a commit
to oliverklee/TYPO3-testing-distribution
that referenced
this pull request
Dec 1, 2025
symfony/dependency-injection 7.4.0 introduced a backwards-imcompatible change that triggered PHP errors with the current versions of TYPO3 12LTS and 13LTS. Until the bug is fixed in symfony/dependency-injection or until the workarounds in the TYPO3 Core are released, we need to avoid installing symfony/dependency-injection 7.4.0. symfony/symfony#62544 https://forge.typo3.org/issues/108349
… PHP error The `class_exists` check and the condition `$definition instanceof ChildDefinition` have been swapped with symfony#61215 in order to produce an error if a service is not available. This error was later relaxed to a deprecation in symfony#61270, but the executing order of the condition kept to be `class_exists` first, then `instanceof`. That means, if `class_exists` fails with a PHP error (like PHP Fatal Error: Interface "My\Vendor\MyInterface" not found`) affected uses will not receive the deprecation, but a fatal error instead.
767565d to
662d28f
Compare
Member
|
Thank you @bnf. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Exception Interface "TYPO3\CMS\Reports\StatusProviderInterface" not foundSee https://forge.typo3.org/issues/108349
The
class_existscheck and the condition$definition instanceof ChildDefinitionhave been swapped with #61215 in order to produce an error if a service is not available.This error was later relaxed in #61270, but the executing order of the condition kept to be
class_existsfirst, theninstanceof.That means, if
class_existsfails with a PHP error (like PHP Fatal Error: Interface "My\Vendor\MyInterface" not found`) affected uses will not see the deprecation, but a fatal error instead.