This fallback exists since
c2de61fb187cf357cd9653693a8fa7cad39ca6ef which is
the first commit which made custom URLs actually functional.
The purpose of this fallback is unclear, it might be related to 'wcf' not
having its own frontend before WoltLab Suite 3.0 and logic expecting that wcf
controllers are accessible from any app.
What's certain is, that this fallback is pretty intransparent, because it:
1) Only affects custom URLs.
2) Only affects controllers assigned to the 'wcf' app.
3) Only affects controllers where the accessed application does not have the
same customURL in its inventory.
Consider this example:
- 'wcf', 'wbb' and 'blog' are installed.
- wcf's AccountManagement is renamed to `my-controller`
- wbb's WatchedThreadList is also renamed to `my-controller`
- blog is left as is
Now accessing:
- `/index.php?my-controller` goes to AccountManagement
- `/blog/index.php?my-controller` goes to AccountManagement
- `/forum/index.php?my-controller` goes to … WatchedThreadList
which most certainly violates the user's expectations.
See also
4da8c1de463ca71f09d284f3529c1d499a7ac8f8 which adjusts a very similar
feature.
FileUtil::removeTrailingSlash($matches['controller'])
);
- // lookup WCF controllers unless initial request targeted WCF itself
- if ($this->routeData === [] && $application !== 'wcf') {
- $this->routeData = ControllerMap::getInstance()->resolveCustomController(
- 'wcf',
- FileUtil::removeTrailingSlash($matches['controller'])
- );
- }
-
if ($this->routeData !== []) {
if (!empty($matches['id'])) {
$this->routeData['id'] = $matches['id'];
$application,
FileUtil::removeTrailingSlash($requestURL)
);
-
- // lookup WCF controllers unless initial request targeted WCF itself
- if ($this->routeData === [] && $application !== 'wcf') {
- $this->routeData = ControllerMap::getInstance()->resolveCustomController(
- 'wcf',
- FileUtil::removeTrailingSlash($requestURL)
- );
- }
}
}