Epic #88528
closedRemove switchable controller action functionality
100%
Description
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
Why have switchable controller actions been introduced?¶
Well, there are several different issues these switchable controller actions:
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
.
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.
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.
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.
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.
Updated by Alexander Schnitzler about 5 years ago
- Related to Bug #71569: FrontendConfigurationManager::overrideSwitchableControllerActionsFromFlexForm does not check if plugin has flexform added
Updated by Alexander Schnitzler about 5 years ago
- Related to Bug #73630: flexform data is not deleted when changing plugin added
Updated by Riccardo De Contardi about 5 years ago
- Related to Bug #80365: Document switchableControllerActions added
Updated by Georg Ringer almost 5 years ago
- Status changed from New to In Progress
Updated by Christian Eßl almost 5 years ago
- Related to Bug #73795: Bug when switching a extbase plugin with flexforms "switchableControllerActions" to a plugin without flexform added
Updated by Christian Eßl almost 5 years ago
- Related to Bug #70378: switchableControllerActions overrides configuration of non-cacheable actions added
Updated by Christian Eßl almost 5 years ago
- Related to Bug #80101: Extbase getContentObject() gets no result by calling in another controller added
Updated by Riccardo De Contardi over 4 years ago
- Related to Task #88496: Replace switchable controller actions terminology added
Updated by Christian Kuhn almost 3 years ago
- Related to Task #96282: Remove extbase switchable controller actions added
Updated by Christian Kuhn almost 3 years ago
- Related to Task #91118: Fix Changelog 89463 - Switchable Controller Actions added
Updated by Stefan Froemken over 1 year ago
Hello Alexander,
thank you for this great work which is IMO done since ~3 years.
What do you think? Can we close this epic issue?
Nice greetings
Stefan
Updated by Christian Kuhn over 1 year ago
- Status changed from In Progress to Resolved