Deprecation: #92947 - TYPO3_MODE and TYPO3_REQUESTTYPE constants

TYPO3_REQUESTTYPE_* constants

• TYPO3_REQUESTTYPE_FE - Use ApplicationType->isFrontend() instead, see below.
• TYPO3_REQUESTTYPE_BE - Use ApplicationType->isBackend() instead, see below.
• TYPO3_REQUESTTYPE_CLI - Use Environment::isCli() instead.
• TYPO3_REQUESTTYPE_AJAX - Extensions should barely need this at all. If really required, using strpos($request->getQueryParams()['route'] ?? '', '/ajax/') === 0 could be used as alternative to find out if a request is a backend ajax request. A better solution however is to refactor consuming code to not depend on this distinction between backend and backend-ajax at all - the TYPO3 core may drop this separation at some point in the future, too.
• TYPO3_REQUESTTYPE_INSTALL - Extensions should never use this. There is only a small number of places in the install tool extensions can extend. Those should have a proper API to separate code from other use cases. A specific check for an install tool scope should not be required.

TYPO3_MODE usage as global script file security gate

TYPO3 still has some extension PHP script files executed in global context without class or callable encapsulation, namely ext_localconf.php, ext_tables.php and files within Configuration/TCA/Overrides/. When those files are located within the public document root of an instance and called via HTTP directly, they may error out and render error messages. This can be a security risk. To prevent this, those files MUST have a security gate as first line. This typically looks like:

defined('TYPO3_MODE') or die();

These calls should be changed to use the new constant TYPO3 instead. It is simply defined to true in early TYPO3 bootstrap and can be used for this purpose:

defined('TYPO3') or die();

Other usages of TYPO3_MODE and TYPO3_REQUESTTYPE in bootstrap script files

The new API class ApplicationType MUST NOT be used in the extension related early bootstrap script files ext_localconf.php, ext_tables.php and Configuration/TCA/*.

The reason is simple: The frontend and backend Application classes are the first objects within TYPO3 bootstrap that "know" which kind of application is executed. They add this information to the PSR-7 request object as attribute applicationType. The helper class ApplicationType - the main substitution for TYPO3_MODE - operates on this. TCA related extension files and ext_* script files however are executed before the Application object has been started, and before the request object is set in globals. The information if a frontend or backend is called does not exist at this point in time, so the helper class ApplicationType can't be used.

This change is in line with a general core bootstrap strategy: A mid-term goal is to have a static framework state after bootstrap, that does not depend on the executed application type. In the future, executed code which must change the static state, after the Application object has been set up, will have better opportunities to reset this state before the Application emits a response. Extensions should bow to this goal and should drop application related state changes in bootstrap related files.

TYPO3_MODE and TYPO3_REQUESTTYPE usages in class files

Some generic extension classes not involved in TYPO3 bootstrap still need to execute different things if they are executed in frontend or backend scope. A use cases is for instance the need to calculate different resource paths depending on frontend or backend.

This code should use the new ApplicationType class.

Before:

if (TYPO3_MODE === 'FE') {
    ...
}

After:

use TYPO3\CMS\Core\Http\ApplicationType;
...
if (ApplicationType::fromRequest($request)->isFrontend()) {
    ...
}

This needs the PSR-7 request that is handed over by the Application specific request handlers to single controllers. Code that needs this switch should be refactored to receive this request object if it is not available already. However, some extension code (especially core hooks) do not provide the request object, yet. In those cases, it is ok to fall back to the request object that has been registered as $GLOBALS['TYPO3_REQUEST'] by the TYPO3 core. This is always set by the RequestHandler that is called before a controller action is executed. It should be noted that falling back to $GLOBALS['TYPO3_REQUEST'] is a technical debt in itself, the TYPO3 core will try to reduce the need for this fallback over time. A call using this fallback looks like:

if (ApplicationType::fromRequest($GLOBALS['TYPO3_REQUEST'])->isFrontend())
    ...
}

As a last use case, there may be low level code executed by a CLI command controller, sometimes using classes that are also used in frontend or backend scope. Some of these CLI calls do not set up a request object at all. The core will change this over time with upcoming patches, but some use cases may remain that are called by CLI directly without a PSR-7 request. The fact that a request object may be missing and still a detection for frontend or backend application type is needed can lead to this code:

if (($GLOBALS['TYPO3_REQUEST'] ?? null) instanceof ServerRequestInterface
    && ApplicationType::fromRequest($GLOBALS['TYPO3_REQUEST'])->isFrontend()
) {
    ...
}