TYPO3 Core

Timo Poppinga wrote:

eid is not working if language listen to / ist disabled

that's because SiteBaseRedirectResolver is before EidHandler

SiteBaseRedirectResolver checks for

// Language is found, and hidden but also not visible to the BE user, this needs to fail
if ($language instanceof SiteLanguage && !$this->isLanguageEnabled($language, $GLOBALS['BE_USER'] ?? null)) {
return GeneralUtility::makeInstance(ErrorController::class)->pageNotFoundAction(
$request,
'Page is not available in the requested language.',
['code' => PageAccessFailureReasons::LANGUAGE_NOT_AVAILABLE]
);
}

and returns an 404

If you add at the beginning of SiteBaseRedirectResolver its works but i do not now if this has Side effects be awre str_starts_with only works with php 8+

$uri = $request->getUri();
        $path = $uri->getPath();
        if (\str_starts_with($path, '/index.php')) {
            return $handler->handle($request);
        }

I just got hit by this problem too.

In my opinion the typo3/cms-frontend/eid middleware should be guaranteed to run before the typo3/cms-frontend/site middleware - as far as I'm aware there is nothing in TYPO3 documentation that suggest that Site and SiteLanguage objects are already resolved at the time eID script is run. Also the order in which middlewares are defined in EXT:frontend/Configuration/RequestMiddlewares.php file seems to hint that typo3/cms-frontend/eid is expected to be invoked right after typo3/cms-core/normalized-params-attribute.

Right now it's a bit of a mess. I checked several our TYPO3 11 projects: some have typo3/cms-frontend/eid before typo3/cms-frontend/site, some the other way around... The latter ones then have typo3/cms-frontend/base-redirect-resolver before typo3/cms-frontend/eid and eID handler is practically disabled on them.

I understand that eID scripts are not the recommended way to go anymore, but since the handler is not officially deprecated, it should work. Therefore I think the issue should be reopened.

The eID needs to be executed after the normalized-params-attribute middleware, but not "right after".
The core ships the middleware in the proposed order.

This order "can" be changed in projects by any extension (3rd party, site-package, some local path extensions and so on)
or by adding own middleware messing around with the middlewares.

Some are moving the eID middleware by intention to a later point. Mainly, to "get" the resolved site/siteLanguage or even
a bootstrapped TypoScript without doing it themself (and to use extbase). Normally, eID handler are in the role to bootstrap
everything they need and beeing on there own - but some are making there live easier by moving the eID middleware to a later
point. That's bascially a legit move, even if I would not recommend it.

Technically, there is no need to ensure eID at a concrete point in the chain, beside being after the normalized-params-attribute
middleware as that is the only dependency needed to be run beforehand.

If you have instances with a changed order, review used 3rd party extension and own extension registering/changing middleware
configuration and order to ensure a "working" state if you have some.

Therefore, this is not a core bug. If something moves eID to a later point and some eID hander doe not work anymore thats an issue
of the extension changing that order.

You can ensure to have a extension which is loaded at last to fix the ordering again.

However, instead of moving the eID middleware the eID handler should be migrated to a middleware and registerd as middleware at
that point. Which would also prepare for a future deprecation/removal of the eID middleware/eID handler.

Hi Stefan,

thanks for your comments.

Stefan Bürk wrote in #note-5:

Normally, eID handler are in the role to bootstrap everything they need and beeing on there own.

This was my assumption based on the fact that eID scripts predate site configuration etc., so I considered this issue a bug. But I see your point and agree with your argumentation.

We have internally developed a patch that ensures eID middleware runs early enough in projects that require it. In the long term we are moving from eID to custom middlewares anyway.