Extbase CommandControllers vs. Symfony/Console Integration
With Symfony's quasi-default package symfony/console in PHP, TYPO3 now still contains two ways (Extbase Command Controllers and Symfony Console Commands), irritating developers what the best strategy for the future is.
Current benefits of Extbase Command Controllers
- Use full feature-set of Extbase's under-the-hood framework like our custom Extbase dependency injection and custom annotation functionality
- Use multiple commands within one controllers, which can be related
- Automatically mapping of command line arguments
Current downsides of Extbase Command Controllers
- Registration in ext_localconf.php together with everything else, which makes it impossible to fetch information about command controllers without having to load all ext_localconf.php
- Magic naming convention of ExtensionName/MyCommandController->customCommand which maps to extensionname:my:custom and possibly reducing it to "my:custom" but makes it hard to override commands from another place and to overcome naming clashes.
- Output: Uses a wrapper around base features of Symfony Console, with only very limited functionality with custom API on top, where this layer would be better to use symfony/console (SymfonyStyle) directly
- No maintenance in years to overcome conceptual flaws like fetching configuration from TypoScript (which is based on the first pagetree with sys_template record) basically making it hard to developers to e.g. manually map settings for persistence into the CLI context of Extbase.
Current benefits of Symfony/Console integration
- Allows to integrate all features for defining validating input arguments/options
- Output is flexible by default, allowing to custom functionality like tables natively
- Separate registration of Commands in one place
- Integration is built so no DB connection or initialized backend user is necessary, to fetch all configuration for a command (now possible with Extbase too, but with some conceptual issues for loading pagetrees and configuration).
- All features for using Symfony/Console functionality is integrated.
Current downside of Symfony/Console integration
Missing section in Core APIs on how to use Symfony/Console within TYPO3 (added to docs.typo3.org Core APIs).
No possibility to add symfony commands in scheduler (added in 9.0)
- No special treatment for Commands which should be excluded from scheduler (Extbase has @cli and @internal)
- No documentation on how to use Extbase DI or repositories/domain models with configuration within a Symfony/Console command
- No listing of available commands in the TYPO3 Backend ("Configuration")
On top, TYPO3 Core still uses both approaches. This is very confusing for extension maintainers and newbies.
There needs to be a decision which direction CLI should continue, and a full migration path should be available.
#1 Updated by Benni Mack about 1 year ago
There is even a third component playing into that:
EXT:scheduler with custom scheduler tasks
scheduler is a GUI but also the functionality provide to define tasks that should be run on CLI (but also other states). This actually mixes a state where both definition of when things are run and the execution context play a role. In general CLI scripts should never be called in backend context, as an admin user has different settings than the CLI user, possibly leading to different results.
The end goal needs to be: One solution with the least drawbacks while providing as much functionality as all three parts play.
A common end scenario could be:
- Have only symfony/console commands
- Use scheduler UX to define scheduling times and to take care of scheduling
- Run everything in CLI context (even though a Backend UI could schedule a task/command to run at next run)