It turns out that that the third and last remaining change of
000c0c8a26491708b2af995bdd6f0e627cc75161 is also broken.
After effectively reverting / removing the logic in the other two files
modified by that commit in
e0976fcfdbeeafc80bc202f80ae2f946326d465d and
416dafddb18a3e82750c6e8ca089d4f9132b39dc, this commit cleans up the last
change.
Since
000c0c8a26491708b2af995bdd6f0e627cc75161 is is impossible for this
redirect to happen and the reason is simple:
The logic will only ever be executed for non-CMS pages, as these are the only
ones where `->lookupDefaultController()` returns an application.
The `controller` return value of `->lookupDefaultController()` will contain the
`routePart` (i.e. `board-list`). However the application overrides are keyed by
the controller name (i.e. `BoardList`), causing the lookup to always fail,
resulting in the given `$application` being returned as-is in `$override`. As
both values are identical, the branch will never be taken and the redirect will
never be executed.
protected function handleDefaultController(string $application, array $routeData): array
{
$data = ControllerMap::getInstance()->lookupDefaultController($application);
- if (!empty($data['application']) && $data['application'] !== $application) {
- $override = ControllerMap::getInstance()->getApplicationOverride($application, $data['controller']);
- if ($application !== $override) {
- HeaderUtil::redirect(
- LinkHandler::getInstance()->getLink(
- ControllerMap::getInstance()->resolve(
- $data['application'],
- $data['controller'],
- false
- )['controller'],
- ['application' => $data['application']]
- ),
- true,
- true
- );
-
- exit;
- }
- }
// copy route data
foreach ($data as $key => $value) {