Bug #102092
closed
Cannot 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 
Updated by Christian Kuhn 8 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.