Epic #88528
Updated by Alexander Schnitzler almost 5 years ago
Switchable controller actions are a way to override the controller-action-pairs – configured during the call to @\TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin@ and/or @\TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerModule@ – during runtime, mostly achieved by implementing a select element in a the flexform of a plugin. The actual configuration is therefore stored in the database and most likely very different from what can be seen in @ext_localconf.php@
h1. Why have switchable controller actions been introduced?
Well, there are several different issues these switchable controller actions:
h2. Allow setting both the default controller and the default action dynamically
Since there is a feature in Extbase called @skipDefaultArguments@, URL's do not need to contain the GET parameters for the controller and the action if the target controller and action are the default ones. This feature has been introduced to ease the pain of configuring nice URL's with @realurl@.
h2. Allow to set custom controller-action-pairs for 3rd-party-extensions
Imagine you are using an extension that has a fixed configuration of controller-action-pairs and you would like to extend controller of said extension to add another action. In this case you could define a flexform for the plugin and override the configuration in there. It's not only possible to get rid of GET parameters that reflect default values of plugins, it's also possible to allow/disallow actions for controllers that have been disallowed/allowed previously.
h1. Why should we get rid of switchable controller actions?
Well, the problem with this "feature" is, that configuration can be changed during runtime, which
* Source code is not the single source of truth
* Configuration can no longer be properly versioned (Git/SVN/...)
* Configuration can not be properly cached and displayed for debugging.
h1. How can/should/will we get rid of switchable controller actions?
There are quite a few different steps to take here:
* First of all, we need to remove the restriction, that only configured pairs of controllers and their actions are allowed to be called. This will be done to remove the necessity to use switchable controller actions to allow non-configured controller-action-pairs. Using the configuration as some kind of firewall is an anti pattern anyway. Authentication and Authorization have to be implemented differently. Nevertheless, this change needs to be communicated very well because people might rely on actions not being callable.
* Next, the switchable controller actions defined via flexform will only be used to determine the default controller and its default action. Switchable controller actions may still define a list of actions, but only the first one will be evaluted to determine the default action.
* Then, @skipDefaultArguments@ will be deprecated. This indicates that from TYPO3 version 11 on, links will no longer be created with missing GET parameters for both default controllers and default actions. To avoid having those params in links, route enhancer configurations have to be used and/or adjusted.
* In TYPO3 version 11, switchable controller actions will no longer be evaluted to determine default controller or default action. All links need to contain a controller and action parameter.
* Also, in TYPO3 version 11, @\TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin@ and @\TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerModule@ will no longer accept a list of actions for (cached) controllers. Both methods will accept a list of allowed controllers and a list of uncached actions. The exact api is not yet defined as of this writing. Idea of Benni Mack: Actions could be marked uncached with a doctrine annotation.
h1. Issues that need to be solved
* If there are two different plugins (with the same namespace like Pi1) on one page, both defining a different default action via switchable controller actions, the removal of the switchable controller actions leads to the problem, that one GET parameter defines the default action for both plugins. This means, that there still needs to be a way to set the default action other than via GET params.