Content-Blocks interfers with vendor/bin/typo3 Symfony Expression Language handling

[garvinhicking]

With a dev-main content-blocks extension installed and recent TYPO3v12, executing:

vendor/bin/typo3 language

yields this error:

Uncaught TYPO3 Exception Too few arguments to function TYPO3\CMS\Core\ExpressionLanguage\ProviderConfigurationLoader::__construct(), 0 passed in /var/www/html/vendor/typo3/cms-core/Classes/Utility/GeneralUtility.php on line 2985 and exactly 3 expected
thrown in file /var/www/html/vendor/typo3/cms-core/Classes/ExpressionLanguage/ProviderConfigurationLoader.php
in line 29

While in an installation without Content-Blocks, this would happen:

  Command "language" is not defined.

 Do you want to run "language:update" instead?  (yes/no) [no]:

I suppose there's some kind of interference in overloading things that might break this. It's not a pressing issue because having a wrong command is not regular operation, but maybe this is something important to address.

Another thing that first happened - I got a lot of errors for many of our content blocks stating:

  [ InvalidArgumentException ]
  The field "header" is missing the required "type" in Content Block "faktore
  /slider-crew".

In this case even fieldtypes that had their useExistingField: true set (and should be type-inferred from TCA) were all reported. So probably at the early bootstrap phase there's a problem in not having the TCA resolved, and this is related to the error above?

[nhovratov]

Okay, so this has something to do with how Symfony handles missing commands. It iterates over all registered commands and asks the TYPO3 CommandRegistry for an instance of the command. If the command is a Content Blocks command (e.g. LanguageGenerateCommand) the problem is, that the Bootstrap process of TYPO3 is skipped in this case leading to missing TCA and therefore the Content Blocks error occurs.

The DI error occurs when a TYPO3 command is requested, but the container is not built fully (only failsafe container) for the same reason as above.

So this error is heavily random and depends on the loading order of commands.

Content Blocks does not influence the behavior, it just provides Commands which depend on low level booting processes.

[garvinhicking]

Ah, I see! Is there any way to make the CB Command recognize its "uninitialized" state and maybe not perform certain actions? Like not setting up internal dependencies that would require the stack to exist, because symfony probably just needs the setArguments() or other specific properties?

Thanks for investigating&explaining ☺️

[nhovratov]

Not sure, as this is DI that triggers this whole process. Only way could be by lazy loading dependencies with GU:makeInstance. But that's feels not right.

[garvinhicking]

I understand. Doing the DI setup in Services.php to have some influence on it also doesn't feel demanded.

I'm good with closing the issue as "wontfix", it is rather some edge case scenario I can live with, knowing about it.