TYPO3 v15 dev-main snapshot ()

2026-08-10 22:31:09 +02:00
commit af8cc155b5
6818 changed files with 642608 additions and 0 deletions
@@ -0,0 +1,36 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-95800:
+
+=============================================================================
+Deprecation: #95800 - Deprecate generating public URL for private asset files
+=============================================================================
+
+See :issue:`95800`
+
+Description
+===========
+
+Since TYPO3 6, extensions have been restructured to have public asset files in Resources/Public folder only.
+
+Unfortunately having public assets in extensions located in other folders never was deprecated. This is now done.
+
+
+Impact
+======
+
+Public assets of extensions (files that should be delivered by the web server) MUST be located in Resources/Public folder of the extension, otherwise a deprecation message is now emitted once a URL to such asset is resolved.
+
+
+Affected Installations
+======================
+
+Installations having extensions activated, that have public asset files in other locations than Resources/Public.
+
+
+Migration
+=========
+
+Extension authors should move all public assets to Resources/Public folder
+
+.. index:: PHP-API, NotScanned, ext:core
@@ -0,0 +1,43 @@
+.. include:: /Includes.rst.txt
+
+.. _important-100889-1690476872:
+
+=======================================================================
+Important: #100889 - Allow insecure site resolution by query parameters
+=======================================================================
+
+See :issue:`100889`
+
+..  important::
+    This change was introduced as part of the
+    `TYPO3 12.4.4 and 11.5.30 security releases <https://typo3.org/security/advisory/typo3-core-sa-2023-003>`__.
+
+Description
+===========
+
+Resolving sites by the `id` and `L` HTTP query parameters is now denied by
+default. However, it is still allowed to resolve a particular page by, for
+example, "example.org" - as long as the page ID `123` is in the scope of the
+site configured for the base URL "example.org".
+
+The new feature flag
+`security.frontend.allowInsecureSiteResolutionByQueryParameters` - which is
+disabled per default - can be used to reactivate the previous behavior:
+
+..  code-block:: php
+
+    $GLOBALS['TYPO3_CONF_VARS']['SYS']['features']['security.frontend.allowInsecureSiteResolutionByQueryParameters'] = true;
+
+
+Impact
+======
+
+Resolving a page via query parameters is now restricted to the specific
+site where the page is located.
+
+Affected installations
+======================
+
+Installations which resolve pages from one domain via another domain.
+
+.. index:: Frontend, NotScanned, ext:core
@@ -0,0 +1,40 @@
+.. include:: /Includes.rst.txt
+
+.. _important-102799-1707403491:
+
+===========================================================================================
+Important: #102799 - TYPO3_CONF_VARS.GFX.processor_stripColorProfileParameters option added
+===========================================================================================
+
+See :issue:`102799`
+
+Description
+===========
+
+The string-based configuration option
+:php:`$GLOBALS['TYPO3_CONF_VARS']['GFX']['processor_stripColorProfileCommand']`
+has been superseded by
+:php:`$GLOBALS['TYPO3_CONF_VARS']['GFX']['processor_stripColorProfileParameters']`
+for security reasons.
+
+The former option expected a string of command line parameters. The defined
+parameters had to be shell-escaped beforehand, while the new option expects an
+array of strings that will be shell-escaped by TYPO3 when used.
+
+The existing configuration will continue to be supported. Still, it is suggested
+to use the new configuration format, as the Install Tool is adapted to allow
+modification of the new configuration option only:
+
+..  code-block:: php
+
+    // Before
+    $GLOBALS['TYPO3_CONF_VARS']['GFX']['processor_stripColorProfileCommand'] = '+profile \'*\'';
+
+    // After
+    $GLOBALS['TYPO3_CONF_VARS']['GFX']['processor_stripColorProfileParameters'] = [
+        '+profile',
+        '*'
+    ];
+
+
+.. index:: LocalConfiguration, ext:core
@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _important-102800-1707409544:
+
+=========================================================================================================
+Important: #102800 - File Abstraction Layer enforces absolute paths to match project root or lockRootPath
+=========================================================================================================
+
+See :issue:`102800`
+
+Description
+===========
+
+
+The File Abstraction Layer Local Driver has been adapted to verify whether a
+given absolute file path is allowed in order to prevent access to files outside
+the project root or to the additional root path restrictions defined in
+:php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['lockRootPath']`.
+
+The option :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['lockRootPath']` has been
+extended to support an array of root path prefixes to allow for multiple storages
+to be listed. Beware that trailing slashes are enforced automatically.
+
+It is suggested to use the new array-based syntax, which will be applied automatically
+once this setting is updated via Install Tool Configuration Wizard:
+
+..  code-block:: php
+
+    // Before
+    $GLOBALS['TYPO3_CONF_VARS']['BE']['lockRootPath'] = '/var/extra-storage';
+
+    // After
+    $GLOBALS['TYPO3_CONF_VARS']['BE']['lockRootPath'] =  [
+        '/var/extra-storage1/',
+        '/var/extra-storage2/',
+    ];
+
+
+.. index:: FAL, LocalConfiguration, ext:core
@@ -0,0 +1,32 @@
+.. include:: /Includes.rst.txt
+
+.. _important-103306-1714976257:
+
+=======================================================================
+Important: #103306 - Frame GET parameter in tx_cms_showpic eID disabled
+=======================================================================
+
+See :issue:`103306`
+
+Description
+===========
+
+The show image controller (eID `tx_cms_showpic`) lacks a cryptographic
+HMAC-signature on the frame HTTP query parameter (e.g.
+`/index.php?eID=tx_cms_showpic?file=3&...&frame=12345`).
+This allows adversaries to instruct the system to produce an arbitrary number of
+thumbnail images on the server side.
+
+To prevent uncontrolled resource consumption, the frame HTTP query parameter is
+now ignored, since it could not be used by core APIs.
+
+The new feature flag
+`security.frontend.allowInsecureFrameOptionInShowImageController` — which is
+disabled per default — can be used to reactivate the previous behavior:
+
+..  code-block:: php
+
+    $GLOBALS['TYPO3_CONF_VARS']['SYS']['features']['security.frontend.allowInsecureFrameOptionInShowImageController'] = true;
+
+
+.. index:: Frontend, NotScanned, ext:frontend
@@ -0,0 +1,21 @@
+.. include:: /Includes.rst.txt
+
+.. _important-92020-1668719172:
+
+===============================================================================
+Important: #92020 - New API entry point available at https://get.typo3.org/api/
+===============================================================================
+
+See :issue:`92020`
+
+Description
+===========
+
+The core version service now uses the new entry point of the REST API
+available via https://get.typo3.org/api.
+
+The old entry point is still available but should not be longer used.
+
+For more information see `https://get.typo3.org/api/doc <https://get.typo3.org/api/doc>`_.
+
+.. index:: ext:install
@@ -0,0 +1,50 @@
+.. include:: /Includes.rst.txt
+
+.. _important-93635:
+
+==================================================================
+Important: #93635 - Add mail configuration for setting smtp domain
+==================================================================
+
+See :issue:`93635`
+
+Description
+===========
+
+Some smtp-relay-server require to set the domain under which the sender is
+sending an email. As default the EsmtpTransport from Symfony will use the current
+domain/IP of the host or container. This will be sufficient for the most of the
+servers but some servers requires a valid domain is passed. If this isn't done,
+sending emails via such servers will fail.
+
+Setting a valid smtp domain can be achieved by setting
+:php:`['MAIL']['transport_smtp_domain']` in the LocalConfiguration.php.
+This will set the given domain to the EsmtpTransport agent an send the
+correct EHLO-command to the relay-server.
+
+Configuration Example for GSuite.
+
+.. code-block:: php
+
+    return [
+        //....
+        'MAIL' => [
+            'defaultMailFromAddress' => 'webserver@example.com',
+            'defaultMailFromName' => 'SYSTEMMAIL',
+            'transport' => 'smtp',
+            'transport_smtp_domain' => 'example.com',
+            'transport_smtp_encrypt' => '',
+            'transport_smtp_password' => '',
+            'transport_smtp_server' => 'smtp-relay.gmail.com:587',
+            'transport_smtp_username' => '',
+        ],
+        //....
+    ];
+
+Impact
+======
+
+Now it is possible to set the smtp mail domain which is required for
+some relay-server.
+
+.. index:: LocalConfiguration, ext:core
@@ -0,0 +1,53 @@
+.. include:: /Includes.rst.txt
+
+.. _important-94951-1655368665:
+
+===================================================================
+Important: #94951 - Restrict export functionality to allowed users
+===================================================================
+
+See :issue:`94951`
+
+.. important::
+    This change was introduced as part of the
+    `TYPO3 11.5.11 and 10.4.29 security release <https://typo3.org/security/advisory/typo3-core-sa-2022-001>`__.
+
+Description
+===========
+
+The export functionality has the following security drawbacks:
+
+*   Export for editors is not limited on field level
+*   The :guilabel:`Save to filename` functionality saves to a shared folder,
+    which other editors with different access rights may have access to.
+
+Both issues are not easy to resolve and also the target
+audience for the Import/Export functionality are mainly
+TYPO3 admins.
+
+Impact
+======
+
+The export functionality is restricted
+to TYPO3 admin users and to users, who explicitly have
+access through the new user TSConfig setting
+:typoscript:`options.impexp.enableExportForNonAdminUser`.
+
+Affected installations
+======================
+
+Installations with EXT:impexp installed where non-admin users need to use the
+export functionality.
+
+Migration
+=========
+
+If non-admin users should be able to use the export tool, set the
+following user TSconfig:
+
+.. code-block:: typoscript
+    :caption: EXT:my_sitepackage/Configuration/TSconfig/allusers.tsconfig
+
+    options.impexp.enableExportForNonAdminUser = 1
+
+.. index:: Backend, TSConfig, NotScanned, ext:impexp
@@ -0,0 +1,145 @@
+.. include:: /Includes.rst.txt
+
+.. _important-96332:
+
+===================================================================
+Important: #96332 - Extbase Validators can use dependency injection
+===================================================================
+
+See :issue:`96332`
+
+Description
+===========
+
+In contrast to what has been outlined with :doc:`this changelog <../11.0/Breaking-92238-ServiceInjectionInExtbaseValidators>`,
+Extbase validators can use dependency injection in v11 again.
+
+Using dependency injection in Extbase validators is possible again, and it
+will be available as standard functionality in TYPO3 v12.
+
+All options below are only needed for extensions that really need to find fully compatible
+ways for dependency injection in their validators. In case single extensions have already been adapted
+to use the strategy from :doc:`the breaking changelog <../11.0/Breaking-92238-ServiceInjectionInExtbaseValidators>`,
+no further adaption is needed.
+
+Extensions still have to apply some manual code changes to single validators
+if they should be dependency injection aware, though: Validators that implement
+method :php:`setOptions()` can use :php:`__construct()` or :php:`inject*` methods
+for dependency injection. Method :php:`setOptions()` will be added to :php:`ValidatorInterface`
+in v12 as mandatory method, and :php:`AbstractValidator` will implement it. Extensions
+with dependency injection-aware validators additionally need to set the class
+:yaml:`public: true` and :yaml:`shared: false` in :file:`Services.yaml`. This
+will be done automatically in v12.
+
+.. note::
+
+    All standard validators of EXT:extbase and EXT:form will be marked :php:`final` in TYPO3 v12.
+    Extension authors should consider this when refactoring validators in TYPO3 v11 already.
+
+A typical Extbase validator that uses dependency injection in v10 and extends :php:`AbstractValidator`
+looks like this in v10:
+
+.. code-block:: php
+
+    class MyCustomValidator extends AbstractValidator
+    {
+        public function injectSomething(Something $something)
+        {
+            $this->something = $something;
+        }
+    }
+
+An extension that keeps dependency injection in v11 can now look like this:
+
+.. code-block:: php
+
+    class MyCustomValidator extends AbstractValidator
+    {
+        public function injectSomething(Something $something)
+        {
+            $this->something = $something;
+        }
+
+        public function setOptions(array $options): void
+        {
+            // This method is upwards compatible with TYPO3 v12, it will be implemented
+            // by AbstractValidator in v12 directly and is part of v12 ValidatorInterface.
+            // @todo: Remove this method when v11 compatibility is dropped.
+            $this->initializeDefaultOptions($options);
+        }
+    }
+
+An extension that keeps compatibility with v10 and v11 at the same time and needs
+dependency injection for custom validators, may need an additional quirk to retain v10
+compatibility. It looks like this:
+
+.. code-block:: php
+
+    class MyCustomValidator extends AbstractValidator
+    {
+        public function injectSomething(Something $something)
+        {
+            $this->something = $something;
+        }
+
+        public function __construct(array $options = []) {
+            // Retain v10 compatibility if the validator has options. This is
+            // especially important if there are *mandatory* options, otherwise
+            // option initialization will be called twice in v11, which may fail.
+            // @todo: Remove this method when v10 compatibility is dropped.
+            if ((new Typo3Version())->getMajorVersion() < 11) {
+                parent::__construct($options);
+            }
+        }
+
+        public function setOptions(array $options): void
+        {
+            // This method is upwards compatible with TYPO3 v12, it will be implemented
+            // by AbstractValidator in v12 directly and is part of v12 ValidatorInterface.
+            // @todo: Remove this method when v11 compatibility is dropped.
+            $this->initializeDefaultOptions($options);
+        }
+    }
+
+Extensions compatible with v11 and v12 can streamline the code like this:
+
+.. code-block:: php
+
+    class MyCustomValidator extends AbstractValidator
+    {
+        public function __construct(Something $something) {
+            $this->something = $something;
+        }
+
+        public function setOptions(array $options): void
+        {
+            // @todo: Remove this method when v11 compatibility is dropped.
+            $this->initializeDefaultOptions($options);
+        }
+    }
+
+The v12 and above version of this validator can then looks like this:
+
+.. code-block:: php
+
+    class MyCustomValidator extends AbstractValidator
+    {
+        public function __construct(private readonly Something $something) {
+        }
+    }
+
+In all of the above cases, whenever Extbase validators need native dependency injection
+without manual :php:`GeneralUtility::makeInstance()` calls for their dependencies, and
+if TYPO3 v11 should be supported, these validators must set :yaml:`public: true` and
+:yaml:`shared: false` in :file:`Services.yaml`:
+
+.. code-block:: yaml
+
+    # This is obsolete when the extension does not support TYPO3 v11 anymore.
+    # @todo: Remove this when v11 compatibility is dropped.
+    MyVendor\MyExtension\Validation\Validator\MyCustomValidator:
+        public: true
+        shared: false
+
+
+.. index:: PHP-API, ext:extbase
@@ -0,0 +1,24 @@
+.. include:: /Includes.rst.txt
+
+.. _important-97111-1657214952:
+
+======================================
+Important: #97111 - Default URI scheme
+======================================
+
+See :issue:`97111`
+
+Description
+===========
+
+Several places in the TYPO3 core fall back to using `http` as a protocol for
+links in case none was given. In order to adjust this behavior the new
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['defaultScheme']` setting has been
+introduced, which uses `http` as default.
+
+In order to adjust the default protocol, one has to add the following
+assignment to their :file:`typo3conf/LocalConfiguration.php` settings:
+
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['defaultScheme'] = 'https'`
+
+.. index:: LocalConfiguration, RTE, ext:core
@@ -0,0 +1,28 @@
+.. include:: /Includes.rst.txt
+
+.. _important-97950-1657892101:
+
+==================================================================
+Important: #97950 - New "iconIdentifier" option in login providers
+==================================================================
+
+See :issue:`97950`
+
+Description
+===========
+
+A new option :php:`iconIdentifier` is added to login providers, which accepts
+any icon that's available in the Icon Registry.
+
+Example:
+
+.. code-block:: php
+
+    $GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['backend']['loginProviders'][1433416747] = [
+        'provider' => UsernamePasswordLoginProvider::class,
+        'sorting' => 50,
+        'iconIdentifier' => 'actions-key',
+        'label' => 'LLL:EXT:backend/Resources/Private/Language/locallang.xlf:login.link',
+    ];
+
+.. index:: Backend, PHP-API, ext:backend
@@ -0,0 +1,27 @@
+.. include:: /Includes.rst.txt
+
+.. _important-98122-1671636081:
+
+=================================================================
+Important: #98122 - Fix felogin variable name in TypoScript setup
+=================================================================
+
+See :issue:`98122`
+
+Description
+===========
+
+The showForgotPasswordLink setting was renamed to showForgotPassword during the
+refactoring to fluid templates. It is now also renamed in the TypoScript setup.
+
+The TypoScript constant name is not changed to keep compatibility.
+
+Migration
+=========
+
+Use :typoscript:`plugin.tx_felogin_login.settings.showForgotPassword` instead of
+:typoscript:`plugin.tx_felogin_login.settings.showForgotPasswordLink` in TypoScript setup.
+And :typoscript:`styles.content.loginform.showForgotPassword` instead of
+:typoscript:`styles.content.loginform.showForgotPasswordLink` in TypoScript constants.
+
+.. index:: TypoScript, ext:felogin
@@ -0,0 +1,94 @@
+.. include:: /Includes.rst.txt
+
+.. _important-98960-1667212946:
+
+===================================================================
+Important: #98960 - Default type definition of custom Content Types
+===================================================================
+
+See :issue:`98960`
+
+Description
+===========
+
+Due to the deprecation of Switchable Controller Actions for Extbase, it is
+recommended to use custom content types as plugins. When using Extbase's API
+:php:`\TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin()` with
+the 5th argument being set to
+:php:`\TYPO3\CMS\Extbase\Utility\ExtensionUtility::PLUGIN_TYPE_CONTENT_ELEMENT`
+or TYPO3's native API :php:`\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addPlugin()`
+with the second argument being set to `CType`, the entered icon identifier
+is now automatically added as `typeicon_classes` for the given `CType` and
+the `TCA` types definition (`showitem`) of the default `header` type is
+automatically applied, so extension authors do not need to add all default
+fields anymore.
+
+Note
+----
+
+These defaults are only applied if they are not set manually, so the changes
+are optional defaults.
+
+In addition, the API method :php:`\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addToAllTCAtypes()`
+now also allows to add custom fields after a palette, so common variants such
+as the `Plugin` tab can be added after a specific palette.
+
+Example
+-------
+
+Example for a custom Extbase plugin with TYPO3's Core "felogin" extension
+in `EXT:felogin/Configuration/TCA/Overrides/tt_content.php`:
+
+..  code-block:: php
+    :caption: EXT:felogin/Configuration/TCA/Overrides/tt_content.php
+
+    call_user_func(static function () {
+        $contentTypeName = 'felogin_login';
+        \TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerPlugin(
+            'Felogin',
+            'Login',
+            'LLL:EXT:felogin/Resources/Private/Language/Database.xlf:tt_content.CType.felogin_login.title',
+            'mimetypes-x-content-login',
+            'forms'
+        );
+
+        // Add the FlexForm for the new content type
+        \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addPiFlexFormValue(
+            '*',
+            'FILE:EXT:felogin/Configuration/FlexForms/Login.xml',
+            $contentTypeName
+        );
+
+        // Add the FlexForm to the showitem list
+        \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addToAllTCAtypes(
+            'tt_content',
+            '--div--;LLL:EXT:frontend/Resources/Private/Language/locallang_ttc.xlf:tabs.plugin, pi_flexform',
+            $contentTypeName,
+            'after:palette:headers'
+        );
+    });
+
+It is configured to be a content element with its own ctype by having the 5th
+parameter set to :php:`ExtensionUtility::PLUGIN_TYPE_CONTENT_ELEMENT`.
+
+..  code-block:: php
+    :caption: EXT:felogin/ext_localconf.php
+    :emphasize-lines: 14
+
+    use TYPO3\CMS\Core\Utility\ExtensionManagementUtility;
+
+    ExtensionUtility::configurePlugin(
+        'Felogin',
+        'Login',
+        [
+            LoginController::class => 'login, overview',
+            PasswordRecoveryController::class => 'recovery,showChangePassword,changePassword',
+        ],
+        [
+            LoginController::class => 'login, overview',
+            PasswordRecoveryController::class => 'recovery,showChangePassword,changePassword',
+        ],
+        ExtensionUtility::PLUGIN_TYPE_CONTENT_ELEMENT
+    );
+
+.. index:: Backend, TCA, ext:core
@@ -0,0 +1,53 @@
+:template: changelogOverview.html
+..  include:: /Includes.rst.txt
+..  _changelog-11-5-x:
+
+==============
+11.5.x Changes
+==============
+
+**Table of contents**
+
+..  contents::
+    :local:
+    :depth: 1
+
+
+Breaking Changes
+================
+
+None since TYPO3 v11.5.0 LTS release.
+
+..  attention::
+
+    Breaking changes are not planned after the TYPO3 v11.5.0 LTS release.
+
+Features
+========
+
+None since TYPO3 v11.5.0 LTS release.
+
+..  attention::
+
+    New features are not planned after the TYPO3 v11.5.0 LTS release.
+
+Deprecation
+===========
+
+..  toctree::
+    :maxdepth: 1
+    :titlesonly:
+    :glob:
+
+    Deprecation-*
+
+
+Important
+=========
+
+..  toctree::
+    :maxdepth: 1
+    :titlesonly:
+    :glob:
+
+    Important-*