Bug #102092
closedCannot autowire service "TYPO3\CMS\Core\Routing\PageArguments"
0%
Description
Just updated to the latest TYPO3 CMS dev-main.
Container builder throws
(1/1) Symfony\Component\DependencyInjection\Exception\RuntimeException
Cannot autowire service "TYPO3\CMS\Core\Routing\PageArguments": argument "$pageId" of method "__construct()" is type-hinted "int", you should configure its value explicitly.
Am not autowiring it in my extension and have no third-party extensions.
Tried both 12.4-dev
& dev-main
. See screenshots. Same result.
Problem
Autowiring \TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController
doesn't work. I had autowired TypoScriptFrontendController
class in a constructor in one file and in a property in a separate file. The TypoScriptFrontendController
class requires the PageArguments
class in its constructor, which in turn, is autowired but has scalar values for its constructor. Same goes for the two more parameters in the TypoScriptFrontendController
.
Solution
Avoid autowiring \TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController
. Instead use, the $GLOBALS['TSFE']
.
Sentiments
I wish there was a way to easily get ready-made services straight from di container instead of using complex methods such as the Aspects
bag or globals
. Also wish that there be single points of constructing objects in TYPO3. In chasing down the PageArguments
problem, I realized that it is constructed from multiple places. It's insane, especially for debugging and efficiency reasons. But that's just me.
Files
Updated by Christian Kuhn 11 months ago
- Status changed from New to Closed
Yeah. TypoScriptFrontendController has a messy constructor and can't be autowired / injected easily. This is "the" main FE class (next to ContentObjectRenderer), and both are still wired as well.
The status of these classes improves each version - especially TypoScriptFrontendController is shrinking and continues to get dependencies removed. We also prepared further refactorings in v12 and will continue to improve the situation in v13.
In the end, TypoScriptFrontendController should end up with a simple constructor that is free for DI.
It's a time consuming process to refactor especially these two classes, and not too many persons get their feet wet in this area since it's easy to break a lot of b/w compat things. But we're slowly getting there.
As such, the overall problem is known but splits into many single patches. Those will be done with single issues. This issue itself does not directly help us in this regard, so I hope it's ok to close here for now. Let's see how this area will look at the end of v13 development, chances are TypoScriptFrontendController will shrink a lot further, increasing chances to also free the constructor for proper DI.
Updated by Leonie Philine 18 days ago
Note to folks googling for the above mentioned error message:
This can also occur if you implement custom LinkBuilder
classes extending \TYPO3\CMS\Frontend\Typolink\AbstractTypolinkBuilder
.
If you autowire all resource: "../Classes/*"
without excluding your link builders in Configuration/Services.yaml
, then Symfony DI will try to autowire \TYPO3\CMS\Frontend\Typolink\AbstractTypolinkBuilder::__construct
, which takes a TypoScriptFrontendController
argument, for your custom link builders. This, of course, must fail, for the reasons mentioned in the OP.
Use exclude: "../Classes/Path/To/Your/LinkBuilders/*"
in Configuration/Services.yaml
to make sure the link builders are not autowired. (There is no need for autowiring, either: They are instantiated in the \TYPO3\CMS\Frontend\Typolink\LinkFactory
- see use of $GLOBALS['TYPO3_CONF_VARS']['FE']['typolinkBuilder']
.)