TYPO3 v15 dev-main snapshot ()

Documentation/Changelog/8.7.x/Breaking-82093-ExtFormFieldPartialChanged.rst

@@ -0,0 +1,59 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-82093:
+
+=================================================================
+Breaking: #82093 - EXT:form Partials/Field/Field.html has changed
+=================================================================
+
+See :issue:`82093`
+
+Description
+===========
+
+To let the form field viewhelper attribute errorClass work, the partial
+:file:`EXT:form/Resources/Private/Frontend/Partials/Field/Field.html` has been changed.
+
+.. code-block:: html
+
+   <f:form.validationResults for="{element.identifier}">
+
+has been changed to
+
+.. code-block:: html
+
+   <f:form.validationResults for="{element.rootForm.identifier}.{element.identifier}">
+
+
+Impact
+======
+
+Users who overwrite this partial by its own partial have to make adjustments.
+Otherwise no `has-error` class will be rendered in case of form validation errors
+into the parents :html:`<div class="form-group">` and the :html:`<span class="help-block">`
+content will not be rendered.
+
+
+Affected Installations
+======================
+
+All installations with overwritten partial :file:`EXT:form/Resources/Private/Frontend/Partials/Field/Field.html`
+
+
+Migration
+=========
+
+Change the partial :file:`Field/Field.html` within your site package.
+
+.. code-block:: html
+
+   <f:form.validationResults for="{element.identifier}">
+
+change to
+
+.. code-block:: html
+
+   <f:form.validationResults for="{element.rootForm.identifier}.{element.identifier}">
+
+
+.. index:: Frontend, ext:form, NotScanned

Documentation/Changelog/8.7.x/Breaking-84843-UseNo-cookieDomainForYoutubeByDefault.rst

@@ -0,0 +1,51 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-84843-1668719172:
+
+==============================================================
+Breaking: #84843 - Use no-cookie domain for youtube by default
+==============================================================
+
+See :issue:`84843`
+
+Description
+===========
+
+To improve the privacy of users the renderer for YouTube videos has been changed to use
+the no-cookie domain `www.youtube-nocookie.com` by default. The regular domain `www.youtube.com`
+is used if explicitly set by the following TypoScript configuration:
+
+.. code-block:: typoscript
+
+    lib.contentElement {
+        settings {
+            media {
+                additionalConfig {
+                    no-cookie = 0
+                }
+            }
+        }
+    }
+
+
+Impact
+======
+
+The TypoScript configuration :typoscript:`lib.contentElement.settings.media.additionalConfig` is used
+as attribute :php:`additionalConfig` of the ViewHelper :php:`\TYPO3\CMS\Fluid\ViewHelpers\MediaViewHelper`.
+
+If no configuration is provided, the domain `www.youtube-nocookie.com` is used.
+
+
+Affected Installations
+======================
+
+Installations which require the usage of the domain `www.youtube.com` or setting cookies by YouTube.
+
+
+Migration
+=========
+
+Use the TypoScript configuration :typoscript:`lib.contentElement.settings.media.additionalConfig.no-cookie = 0`
+
+.. index:: TypoScript, ext:fluid_styled_content

Documentation/Changelog/8.7.x/Deprecation-83403-ExtFormTranslationForOptionsPropertiesAsString.rst

@@ -0,0 +1,48 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-83403:
+
+==============================================================================
+Deprecation: #83403 - EXT:form - deprecate translation for "options" as string
+==============================================================================
+
+See :issue:`83403`
+
+Description
+===========
+
+The templates for RadioButton and MultiCheckbox form elements have been changed. This was necessary
+to allow dots and special chars within labels and values for the "options" property of the
+aforementioned elements.
+For compatibility reasons, the old template syntax is still supported but is deprecated and will be
+removed with TYPO3 v9.
+
+Impact
+======
+
+If a user utilizes his own templates for MultiCheckbox and/ or RadioButton form elements and
+translates the "options" property in the following way, a deprecation warning will be thrown.
+
+.. code-block:: html
+
+   {formvh:translateElementProperty(element: element, property: 'options.{value}')}
+
+Affected Installations
+======================
+
+Any installation which uses ext:form and own templates for MultiCheckbox and/ or RadioButton form
+elements.
+
+
+Migration
+=========
+
+Use
+
+.. code-block:: html
+
+   {formvh:translateElementProperty(element: element, property: '{0: \'options\', 1: value}')}
+
+to translate the "options" property within MultiCheckbox and RadioButton form element templates.
+
+.. index:: Frontend, ext:form

Documentation/Changelog/8.7.x/Deprecation-84449-TranslateElementErrorViewHelperArguments.rst

@@ -0,0 +1,49 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-84449:
+
+===============================================================
+Deprecation: #84449 - TranslateElementErrorViewHelper arguments
+===============================================================
+
+See :issue:`84449`
+
+Description
+===========
+
+The template EXT:form/Resources/Private/Frontend/Partials/Field/Field.html has been changed. This
+was necessary because of a bug with validation messages containing arguments.
+For compatibility reasons, the old template syntax is still supported but is deprecated and will be
+removed with TYPO3 v10.
+
+Impact
+======
+
+If a user utilizes his own template for EXT:form/Resources/Private/Frontend/Partials/Field/Field.html,
+a deprecation warning will be thrown.
+
+
+Affected Installations
+======================
+
+Any installation which uses the form framework and a customized template for
+EXT:form/Resources/Private/Frontend/Partials/Field/Field.html.
+
+
+Migration
+=========
+
+Change
+
+.. code-block:: html
+
+   {formvh:translateElementError(element: element, code: error.code, arguments: error.arguments, defaultValue: error.message)}
+
+to
+
+.. code-block:: html
+
+   {formvh:translateElementError(element: element, error: error)}
+
+
+.. index:: Frontend, ext:form

Documentation/Changelog/8.7.x/Feature-78161-IntroduceTypoScriptFileExtension.rst

@@ -0,0 +1,44 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-78161:
+
+======================================================
+Feature: #78161 - Introduce .typoscript file extension
+======================================================
+
+See :issue:`78161`
+
+Description
+===========
+
+The new file extension .typoscript will be the default for TypoScript configuration
+files and is the only recommended one from now on. This effort is made to introduce
+a dedicated file extension for TypoScript configuration files, and to avoid conflicts
+with already existing and more spread file extensions like ".ts" for TypeScript or
+Video Transport Stream Files.
+
+New prioritised files for static templates:
+
+* constants.typoscript
+* setup.typoscript
+
+New prioritised files for extension statics:
+
+* ext_typoscript_constants.typoscript
+* ext_typoscript_setup.typoscript
+
+For more details please head over to the decision platform:
+
+* https://decisions.typo3.org/t/file-endings-for-typoscript-files-and-tsconfig-files/43
+* https://decisions.typo3.org/t/file-endings-for-typoscript-and-tsconfig-files-results/71
+
+
+Impact
+======
+
+The ".typoscript" file extension is prioritised over the legacy .txt and .ts file
+extensions, and the only recommended file extension for typoscript configuration
+files.
+
+
+.. index:: Frontend, TypoScript

Documentation/Changelog/8.7.x/Feature-81654-AddingNovalidateAttributeToFluidFormViewHelper.rst

@@ -0,0 +1,18 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-81654:
+
+======================================================================
+Feature: #81654 - Adding novalidate Attribute to Fluid Form ViewHelper
+======================================================================
+
+See :issue:`81654`
+
+Description
+===========
+
+Adding novalidate attribute to fluid form viewHelper to disable the browser form validation.
+The attribute novalidate is optional and can set with novalidate="1".The argument will
+converted to <form novalidate="novalidate">...</form>.
+
+.. index:: Fluid

Documentation/Changelog/8.7.x/Feature-83405-AddConfirmationFinisherTemplate.rst

@@ -0,0 +1,82 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-83405:
+
+===================================================
+Feature: #83405 - add ConfirmationFinisher template
+===================================================
+
+See :issue:`83405`
+
+Description
+===========
+
+The ConfirmationFinisher message is now rendered within a fluid template to allow styling of the message.
+Furthermore, the FormRuntime (and thus all form element values) and the finisherVariableProvider are available in the template [1].
+Custom variables can be added globally within the form setup or at form level in the form definition [2].
+By using a fluid template and the associated html escaping, the display of the ConfirmationFinisher message is protected against XSS / html injection attacks.
+The ext: form supplied fluid template does not include any HTML wrapping to remain compatible with existing installations, but it is possible to implement your own template [3].
+
+[1] Template variables
+----------------------
+
+* :html:`{form}` - Object for access to submitted form element values (https://docs.typo3.org/typo3cms/extensions/form/Concepts/FrontendRendering/Index.html#accessing-form-values)
+* :html:`{finisherVariableProvider}` - Object with data from previous finishers (https://docs.typo3.org/typo3cms/extensions/form/Concepts/FrontendRendering/Index.html#share-data-between-finishers)
+* :html:`{message}` - The confirmation message
+
+[2] custom template variables
+-----------------------------
+
+global within the form setup:
+
+.. code-block:: yaml
+
+    TYPO3:
+      CMS:
+        Form:
+          prototypes:
+            standard:
+              finishersDefinition:
+                Confirmation:
+                  options:
+                    variables:
+                      foo: bar
+
+per form within the form definition:
+
+.. code-block:: yaml
+
+    finishers:
+      -
+        identifier: Confirmation
+        options:
+          message: 'Thx'
+          variables:
+            foo: bar
+
+[3] custom Template
+-------------------
+
+form setup:
+
+.. code-block:: yaml
+
+    TYPO3:
+      CMS:
+        Form:
+          prototypes:
+            standard:
+              finishersDefinition:
+                Confirmation:
+                  options:
+                    templateRootPaths:
+                      20: 'EXT:my_site_package/Resources/Private/Templates/Form/Finishers/Confirmation/'
+
+Impact
+======
+
+Integrators can use a ConfirmationFinisher message within a fluid template.
+Integrators can use additional information such as form element values within the template.
+The ConfirmationFinisher message is protected against XSS / html injection attacks.
+
+.. index:: Frontend, ext:form, NotScanned

Documentation/Changelog/8.7.x/Feature-84244-AllowAddingAdditionalQueryrestrictions.rst

@@ -0,0 +1,51 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-84244:
+
+============================================================
+Feature: #84244 - Allow adding additional query restrictions
+============================================================
+
+See :issue:`84244`
+
+Description
+===========
+
+It is now possible to add additional query restrictions by adding class names as key to
+:php:`$GLOBALS['TYPO3_CONF_VARS']['DB']['additionalQueryRestrictions']`
+These restriction objects will be added to any select query executed using the QueryBuilder.
+
+If these added restriction objects additionally implement :php:`\TYPO3\CMS\Core\Database\Query\Restriction\EnforceableQueryRestrictionInterface`
+and return true in the to be implemented method :php:`isEnforced()`, calling :php:`$queryBuilder->getRestrictions()->removeAll()`
+such restrictions will **still** be applied to the query.
+
+If an enforced restriction must be removed, it can still be removed with :php:`$queryBuilder->->getRestrictions()->removeByType(SomeClass::class);`
+
+Implementers of custom restrictions can therefore have their restrictions always enforced, or even not applied at all,
+by returning an empty expression in certain cases.
+
+To add a custom restriction class, use the following snippet in a :file:`ext_localconf.php` file of your extension:
+
+.. code-block:: php
+
+    if (!isset($GLOBALS['TYPO3_CONF_VARS']['DB']['additionalQueryRestrictions'][\Vendor\ExtName\Database\Query\Restriction\CustomRestriction::class])) {
+        $GLOBALS['TYPO3_CONF_VARS']['DB']['additionalQueryRestrictions'][\Vendor\ExtName\Database\Query\Restriction\CustomRestriction::class] = [];
+    }
+
+Please note, that the class name must be the array key and the value must always be an array, which is reserved for options
+given to the restriction objects.
+
+Impact
+======
+
+Restrictions added by third party extensions will impact the whole system. Therefore this API does not allow removing restrictions
+added by the system and adding restrictions should be handled with care.
+
+Removing third party restrictions is possible, by setting the option value :php:`disabled` for a restriction to :php:`true`
+in global TYPO3 configuration or :php:`ext_localconf.php` of an extension, like shown below.
+
+.. code-block:: php
+
+    $GLOBALS['TYPO3_CONF_VARS']['DB']['additionalQueryRestrictions'][\Vendor\ExtName\Database\Query\Restriction\CustomRestriction::class]['disabled'] = true;
+
+.. index:: Backend, Database, Frontend, ext:core

Documentation/Changelog/8.7.x/Feature-84537-MakeCHashConfigurableInFluidWidgetLinks.rst

@@ -0,0 +1,19 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-84537:
+
+================================================================
+Feature: #84537 - Make cHash configurable in Fluid Widget Links
+================================================================
+
+See :issue:`84537`
+
+Description
+===========
+
+When creating links with fluid widgets it is now possible to disable the cHash calculation.
+
+A new argument `useCacheHash` for the :html:`<f:widget.link>` and the :html:`<f:widget.uri>` ViewHelpers has been added.
+By default it is set to `true` to keep the previous behavior.
+
+.. index:: Fluid, NotScanned

Documentation/Changelog/8.7.x/Feature-84781-AddedSchedulerTaskToAnonymizeIPAddressesOfTables.rst

@@ -0,0 +1,40 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-84781-1668719172:
+
+==========================================================================
+Feature: #84781 - Added scheduler task to anonymize IP addresses of tables
+==========================================================================
+
+See :issue:`84781`
+
+Description
+===========
+
+A new scheduler task has been added which makes it possible to anonymize IP addresses stored in database tables.
+
+The task *Anonymize IP addresses in database tables* is configured in the :file:`ext_localconf.php`.
+
+.. code-block:: php
+
+    $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['scheduler']['tasks'][\TYPO3\CMS\Scheduler\Task\IpAnonymizationTask::class]['options']['tables']['<tableName>'] = [
+        'dateField' => '<dateFieldName>',
+        'ipField' => '<ipFieldName>'
+    ];
+
+After the base configuration the table is available in the scheduler task with the following configuration options:
+
+- Table
+- Minimum age an entry must have to be anonymized
+- IP mask level
+
+
+Impact
+======
+
+The following tables are available by default:
+
+- index_stat_search
+- sys_log
+
+.. index:: CLI, ext:scheduler

Documentation/Changelog/8.7.x/Feature-90351-ConfigureTYPO3-shippedCookiesWithSameSiteFlag.rst

@@ -0,0 +1,62 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-90351:
+
+====================================================================
+Feature: #90351 - Configure TYPO3-shipped cookies with SameSite flag
+====================================================================
+
+See :issue:`90351`
+
+Description
+===========
+
+TYPO3 Core sends four cookies set by PHP to the browser when a session is requested:
+
+- fe_typo_user - used to identify a session ID when logged-in to the TYPO3 Frontend
+- be_typo_user - used to identify a backend session when a Backend User logged in to TYPO3 Backend or Frontend
+- Typo3InstallTool - used to validate a session for the System Maintenance Area / "Install Tool"
+- be_lastLoginProvider - stores information about the last login provider when logging into TYPO3 Backend
+
+All modern wide-spread browsers (Mozilla Firefox, Chromium-based Browsers such as Google Chrome, Safari, Microsoft Edge) support sending cookies with an additional flag called "SameSite" which
+defines the visibility of a cookie when used in other scripts or
+iframes such as a YouTube video embedded into a site. The same site
+flag defines whether to send such information to these "third-party
+sites".
+
+Starting with Google Chrome 80 (expected in February 2020), the browser treats any cookie without having the SameSite flag sent to
+be the same as "lax".
+
+TYPO3 now supports the configuration of this cookie for Frontend-
+and Backend users. For the install Tool and lastLoginProvider
+the cookies are now always sent with the "strict" flag set.
+
+SameSite enhances privacy for every visitor or editor of your
+TYPO3 installation.
+
+Read more about SameSite cookies on: https://web.dev/samesite-cookies-explained/
+
+
+Impact
+======
+
+All cookies sent by TYPO3 Core now send the SameSite flag by default, whereas TYPO3 Frontend sends the SameSite flag "lax",
+and all other cookies are sent via "strict".
+
+The cookies for Frontend User Sessions can be configured via
+`$GLOBALS[TYPO3_CONF_VARS][FE][cookieSameSite]` to be either
+"strict", "lax" or "none".
+
+The cookies for Backend User Sessions can be configured via
+`$GLOBALS[TYPO3_CONF_VARS][BE][cookieSameSite]` to be either
+"strict", "lax" or "none".
+
+Please note that "none" only works when running the site via HTTPS.
+
+Older browsers without SameSite support do not consider evaluating
+the SameSite flag will behave as before.
+
+Both settings can be configured in the Install Tool / Maintenance
+Area Settings module.
+
+.. index:: LocalConfiguration, ext:core

Documentation/Changelog/8.7.x/Important-23178-NewTYPO3_CONF_VARSOptionFEpageNotFound_handling_accessdeniedheader.rst

@@ -0,0 +1,20 @@
+.. include:: /Includes.rst.txt
+
+.. _important-23178-1668719172:
+
+==========================================================================================
+Important: #23178 - New TYPO3_CONF_VARS option FE|pageNotFound_handling_accessdeniedheader
+==========================================================================================
+
+See :issue:`23178`
+
+Description
+===========
+
+In order to send a correct HTTP header to the browser when access to a page is denied,
+a new option TYPO3_CONF_VARS is introduced.
+
+The option :php:`FE|pageNotFound_handling_accessdeniedheader` allows to configure the
+header which defaults to :php:`HTTP/1.0 403 Access denied`.
+
+.. index:: Frontend, LocalConfiguration

Documentation/Changelog/8.7.x/Important-75591-PartialsHoneypothtmlHasChanged.rst

@@ -0,0 +1,19 @@
+.. include:: /Includes.rst.txt
+
+.. _important-75591:
+
+======================================================
+Important: #75591 - Partials/Honeypot.html has changed
+======================================================
+
+See :issue:`75591`
+
+Description
+===========
+
+The partial :file:`EXT:form/Resources/Private/Frontend/Partials/Honeypot.html` has been changed. The
+honeypot field now passes the accessibility tests WCAG 2.0 by adding an aria-hidden attribute.
+All installations with the overwritten partial :file:`EXT:form/Resources/Private/Frontend/Partials/Honeypot.html`
+are affected and should be migrated.
+
+.. index:: Frontend, ext:form

Documentation/Changelog/8.7.x/Important-77830-CSC-HeaderLinkRespectsGlobalPageTarget.rst

@@ -0,0 +1,24 @@
+.. include:: /Includes.rst.txt
+
+.. _important-77830-1668719172:
+
+==========================================================
+Important: #77830 - CSC-HeaderLinkRespectsGlobalPageTarget
+==========================================================
+
+See :issue:`77830`
+
+Description
+===========
+
+Setting the global configuration :typoscript:`lib.parseTarget` was not respected by the header_link field.
+Now the configuration is properly applied and might change the output in the frontend.
+
+Impact
+======
+
+If the global setting :typoscript:`lib.parseTarget` is set, the field header_link will now respect it.
+If in addition the target of header_link is set in a content element, it will take precedence over
+:typoscript:`lib.parseTarget`.
+
+.. index:: Frontend, TypoScript

Documentation/Changelog/8.7.x/Important-78336-GeneratePreviewLinksWithAChash.rst

@@ -0,0 +1,36 @@
+.. include:: /Includes.rst.txt
+
+.. _important-78336:
+
+=======================================================
+Important: #78336 - Generate preview links with a chash
+=======================================================
+
+See :issue:`78336`
+
+Description
+===========
+
+The preview link configuration has been extended to be able to generate links with a cHash.
+
+Provide the setting `useCacheHash = 1` to add a cHash. This is essential for records displayed
+using Extbase which enforces cHash usage.
+
+.. code-block:: typoscript
+
+	TCEMAIN.preview {
+		<table name> {
+			previewPageId = 123
+			useCacheHash = 1
+			fieldToParameterMap {
+				uid = tx_myext_pi1[showUid]
+			}
+			additionalGetParameters {
+				tx_myext_pi1[special] = HELLO
+			}
+		}
+	}
+
+If `useCacheHash = 1` is not set, the `no_cache` parameter will be added just like before.
+
+.. index:: Backend, Frontend, TSConfig

Documentation/Changelog/8.7.x/Important-79647-AddedHookForResolvingCustomLinkTypes.rst

@@ -0,0 +1,52 @@
+.. include:: /Includes.rst.txt
+
+.. _important-79647:
+
+==============================================================
+Important: #79647 - Added Hook for resolving custom link types
+==============================================================
+
+See :issue:`79647`
+
+Description
+===========
+
+A newly introduced hook in :php:`LinkService->resolveByStringRepresentation` allows to resolve custom link types with
+special syntax. A reference to the empty :php:`$result` array is passed as well as the :php:`$urn` string that could not be
+resolved by the core.
+
+Example
+=======
+
+An example implementation for custom links that use `myLinkIdentifier:` as a prefix could look like this:
+
+:file:`EXT:my_site/ext_localconf.php`
+
+.. code-block:: php
+
+   $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['Link']['resolveByStringRepresentation'][] =
+      \MyVendor\MySite\Hooks\LinkServiceHook::class . '->resolveByStringRepresentation';
+
+
+:file:`EXT:my_site/Classes/Hooks/LinkServiceHook.php`
+
+.. code-block:: php
+
+   namespace MyVendor\MySite\Hooks;
+
+   class LinkServiceHook
+   {
+      public function resolveByStringRepresentation(array $parameters): void
+      {
+         // Only care for links that start with myLinkIdentifier:
+         if (stripos($parameters['urn'], 'myLinkIdentifier:') !== 0) {
+            return;
+         }
+
+         // Be aware: substr of 17 because of the identifier and the colon
+         $parameters['result'] = ['myLinkIdentifier' => substr($parameters['urn'], 17)];
+         $parameters['result']['type'] = 'myLinkIdentifier';
+      }
+   }
+
+.. index:: Backend, PHP-API

Documentation/Changelog/8.7.x/Important-81751-DbalCompatibleQuotingInTca.rst

@@ -0,0 +1,47 @@
+.. include:: /Includes.rst.txt
+
+.. _important-81751:
+
+==================================================
+Important: #81751 - DBAL compatible quoting in TCA
+==================================================
+
+See :issue:`81751`
+
+Description
+===========
+
+Names of tables and columns used in SQL fragments of :php:`TCA` definitions need proper quoting to be compatible with different database drivers. The database
+framework of the core now applies proper quoting to table and column names if they are wrapped as :php:`{#tableName}.{#columnName}`
+
+It is advised to adapt extensions accordingly to run successfully on databases like PostgreSQL.
+
+Example for a :php:`TCA` definition snippet:
+
+.. code-block:: php
+
+    'columns' => [
+        'aField' => [
+            'config' => [
+                'foreign_table' => 'tt_content',
+                'foreign_table_where' => 'AND {#tt_content}.{#CType} IN (\'text\',\'textpic\',\'textmedia\') ORDER BY {#tt_content}.{#CType} ASC',
+                ...
+            ],
+        ],
+        ...
+    ],
+
+    'columns' => [
+        'aField' => [
+            'config' => [
+                'type' => 'text',
+                'search' => [
+                    'andWhere' => '{#CType}=\'text\' OR {#CType}=\'textpic\' OR {#CType}=\'textmedia\''
+                ],
+                ...
+            ],
+        ],
+        ...
+    ],
+
+.. index:: Database, Backend, TCA

Documentation/Changelog/8.7.x/Important-82763-GlobalFluidExpressionNodeTypeAndTemplatePreProcessorConfiguration.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _important-82763:
+
+============================================================================================
+Important: #82763 - Fluid config for ExpressionNodeType and TemplatePreProcessor made global
+============================================================================================
+
+See :issue:`82763`
+
+Description
+===========
+
+Before, Fluid's arrays of class names for ``ExpressionNodeType`` and ``TemplatePreProcessor`` were hardcoded into the
+``RenderingContext`` constructor and were not possible to modify except when having access to the ``RenderingContext``.
+
+Now, these two arrays of class names are possible to configure in ``TYPO3_CONF_VARS`` which allows extensions or site
+administrators to add and remove such Fluid components on a global level.
+
+Example:
+
+.. code-block:: php
+
+    // Add one new ExpressionNodeType and one new TemplatePreProcessor to be used in every RenderingContext
+    // For example from an ext_localconf.php file in an extension.
+    $GLOBALS['TYPO3_CONF_VARS']['SYS']['fluid']['expressionNodeTypes'][] = \MyVendor\MyExtension\MyFluidExpressionNodeType::class;
+    $GLOBALS['TYPO3_CONF_VARS']['SYS']['fluid']['preProcessors'][] = \MyVendor\MyExtension\MyFluidTemplatePreProcessor::class;
+
+These classes will then be *added to the list of existing implementations* and will be automatically used as defaults
+when new ``RenderingContext`` instances are created.
+
+See for reference how to create such implementations:
+
+* :php:`\TYPO3Fluid\Fluid\Core\Parser\TemplateProcessorInterface`
+* :php:`\TYPO3Fluid\Fluid\Core\Parser\SyntaxTree\Expression\ExpressionNodeInterface`
+
+Both interfaces contain the documentation for how they must be implemented, when/why functions get called and what the
+expected return types are. The interfaces must of course be implemented by classes you add to ``TYPO3_CONF_VARS`` in
+these configuration sections. Due to their global nature you should be very careful to implement the classes and in
+particular observe the return types.
+
+.. index:: Fluid, LocalConfiguration

Documentation/Changelog/8.7.x/Important-82794-AddedSysLanguageModeFallbackStop.rst

@@ -0,0 +1,34 @@
+.. include:: /Includes.rst.txt
+
+.. _important-82794:
+
+======================================================================================
+Important: #82794 - Added config.sys_language_mode = content_fallback;3,2,pageNotFound
+======================================================================================
+
+See :issue:`82794`
+
+Description
+===========
+
+If a translation (language UID 5) has a TypoScript configuration to
+:typoscript:`config.sys_language_mode = content_fallback;3,2` the definition is that if this page is not
+available in this translation (language = 5) then check if a translation for `3` and after that `2` is
+set.
+
+However, if none of the page translations is available, the fallback to `0` always applies.
+
+On a set up like:
+
+* language = 0 is german
+* language = 2 is english-worldwide
+* language = 3 is english-US
+* language = 5 is russian
+
+You would not want to fall back to german AT ALL.
+
+It is now possible to define a special keyword called `pageNotFound` to not fall back to
+:typoscript:`sys_language_uid = 0` if any other fallbacks do not work - so a 404 error page is thrown.
+:typoscript:`config.sys_language_mode = content_fallback;3,2,pageNotFound`
+
+.. index:: TypoScript, Frontend

Documentation/Changelog/8.7.x/Important-83768-RemoveReferrerCheck.rst

@@ -0,0 +1,41 @@
+.. include:: /Includes.rst.txt
+
+.. _important-83768-1668719172:
+
+=========================================
+Important: #83768 - Remove referrer check
+=========================================
+
+See :issue:`83768`
+
+Description
+===========
+
+Browser vendors are considering or have already announced **not** to send the referrer URL/path in HTTP requests when
+links are followed or forms are submitted due to privacy reasons. TYPO3 used the referrer as a meagre CSRF protection
+for the backend. However, this has been replaced by proper CSRF protection tokens for every backend action and therefore,
+the referrer check became obsolete and has been removed.
+
+Usages of the configuration option :php:`[SYS][doNotCheckReferer]` within TYPO3 Core have been removed, as this is not
+needed anymore. However, the option can still be set for extensions implementing this option.
+
+
+Impact
+======
+
+Backend users will not notice any differences.
+
+
+Affected Installations
+======================
+
+All installations are affected.
+
+
+Migration
+=========
+
+TYPO3 extensions that use option :php:`[SYS][doNotCheckReferer]` to implement a kind of CSRF protection, should use
+proper CSRF protection tokens provided by the core.
+
+.. index:: Backend, FullyScanned

Documentation/Changelog/8.7.x/Important-83971-ConsoleShowDeprecationWarningInChrome.rst

@@ -0,0 +1,38 @@
+.. include:: /Includes.rst.txt
+
+.. _important-83971:
+
+====================================================================================
+Important: #83971 - Browser Notification API only works on SSL encrypted connections
+====================================================================================
+
+See :issue:`83971`
+
+Description
+===========
+
+Google Chrome has deprecated the JavaScript Notification API for unencrypted connections, which
+triggers warnings. Due to this TYPO3 does not use the LoginRefresh notification here anymore.
+
+See https://goo.gl/rStTGz for more details.
+
+
+Impact
+======
+
+The browser notifications for expired login only works on HTTPS.
+
+
+Affected Installations
+======================
+
+Any installation which does not use HTTPS.
+
+
+Migration
+=========
+
+Use SSL / HTTPS for the installation and the Notification API will work just like before.
+
+
+.. index:: Backend, JavaScript

Documentation/Changelog/8.7.x/Important-84144-RootlineUtilityIsEnrichingOnlyProperlySelectedRelationalDatabaseFields.rst

@@ -0,0 +1,22 @@
+.. include:: /Includes.rst.txt
+
+.. _important-84144:
+
+==================================================================================================
+Important: #84144 - RootlineUtility is enriching only properly selected relational database fields
+==================================================================================================
+
+See :issue:`84144`
+
+Description
+===========
+
+The main functionality for fetching the whole rootline of a page previously fetched all relational
+fields defined in TCA of a page record. This led to massive performance problems with large menus,
+as not all fields are necessary in root line records.
+
+Now, the rootline fetching only looks up relational data of fields which have been added to
+:php:`$GLOBALS[TYPO3_CONF_VARS][FE][addRootLineFields]`. The field `pages.media` is added per
+default since it is a predefined value.
+
+.. index:: Frontend, ext:frontend

Documentation/Changelog/8.7.x/Important-84844-AddFieldnameToDataHandler-Localize-TranslateToMessageHook.rst

@@ -0,0 +1,16 @@
+.. include:: /Includes.rst.txt
+
+.. _important-84844:
+
+=====================================================================================
+Important: #84844 - Add fieldname to DataHandler - localize - translateToMessage hook
+=====================================================================================
+
+See :issue:`84844`
+
+Description
+===========
+
+The `translateToMessage` hooks of the :php`localize()` function of the :php:`DataHandler` now get a fourth parameter for the currently processed fieldname.
+
+.. index:: Backend, PHP-API

Documentation/Changelog/8.7.x/Important-84910-DenyDirectFALCommandsForFormDefinitions.rst

@@ -0,0 +1,58 @@
+.. include:: /Includes.rst.txt
+
+.. _important-84910:
+
+=================================================================
+Important: #84910 - Deny direct FAL commands for form definitions
+=================================================================
+
+In order to control settings in user provided form definitions files and only
+allow manipulations by using the backend form editor (or direct file access
+using e.g. SFTP) form file extensions have been changed form simple `.yaml`
+to more specific `.form.yaml`.
+
+Direct file commands by using either the backend file list module or implemented
+invocations of the file abstraction layer (FAL) API are denied per default and
+have to allowed explicitly for the following commands for files ending with the
+new file suffix `.form.yaml`:
+
+* plain command invocations
+
+  + create (creating new, empty file having `.form.yaml` suffix)
+  + rename (renaming to file having `.form.yaml` suffix)
+  + replace (replacing an existing file having `.form.yaml` suffix)
+  + move (moving to different file having `.form.yaml` suffix)
+
+* command and content invocations - content signature required
+
+  + add (uploading new file having `.form.yaml` suffix)
+  + setContents (changing contents of file having `.form.yaml` suffix)
+
+In order to grant those commands, `\TYPO3\CMS\Form\Slot\FilePersistenceSlot`
+has been introduced (singleton instance).
+
+.. code-block:: php
+
+    // Allowing content modifications on a $file object with
+    // given $newContent information prior to executing the command
+
+    $slot = GeneralUtility::makeInstance(FilePersistenceSlot::class);
+    $slot->allowInvocation(
+        FilePersistenceSlot::COMMAND_FILE_SET_CONTENTS,
+        $file->getCombinedIdentifier(),
+        $this->filePersistenceSlot->getContentSignature($newContent)
+    );
+
+    $file->setContents($newContent);
+
+In contrast to *plain command invocations*, those having *content invocations*
+(`add` and `setContents`, see list of commands above) require a content signature
+as well in order to be executed. The previous example demonstrates that for the
+`setContents` command.
+
+Extensions that are modifying (e.g. post-processing) persisted form definition
+files using the file abstraction layer (FAL) API need to adjust and extend their
+implementation and allow according invocations as outlined above.
+
+See :issue:`84910`
+.. index:: Backend, FAL, ext:form

Documentation/Changelog/8.7.x/Important-85044-FilterDisallowedPropertiesInFormEditor.rst

@@ -0,0 +1,111 @@
+.. include:: /Includes.rst.txt
+
+.. _important-85044:
+
+===============================================================
+Important: #85044 - Filter disallowed properties in form editor
+===============================================================
+
+See :issue:`85044`
+
+Description
+===========
+
+The form editor save and preview actions now check the submitted form definition against configured possibilities within the form editor setup.
+
+If a form element property is defined in the form editor setup then it means that the form element property can be written by the form editor.
+A form element property can be written if the property path is defined within the following form editor properties:
+
+* :yaml:`formElementsDefinition.<formElementType>.formEditor.editors.<index>.propertyPath`
+* :yaml:`formElementsDefinition.<formElementType>.formEditor.editors.<index>.*.propertyPath`
+* :yaml:`formElementsDefinition.<formElementType>.formEditor.editors.<index>.additionalElementPropertyPaths`
+* :yaml:`formElementsDefinition.<formElementType>.formEditor.propertyCollections.<finishers|validators>.<index>.editors.<index>.additionalElementPropertyPaths`
+
+If a form editor property :yaml:`templateName` is "Inspector-PropertyGridEditor" or "Inspector-MultiSelectEditor" or "Inspector-ValidationErrorMessageEditor"
+it means that the form editor property :yaml:`propertyPath` is interpreted as a so called "multiValueProperty".
+A "multiValueProperty" can contain any subproperties relative to the value from :yaml:`propertyPath` which are valid.
+If :yaml:`formElementsDefinition.<formElementType>.formEditor.editors.<index>.templateName` = "Inspector-PropertyGridEditor" and :yaml:`formElementsDefinition.<formElementType>.formEditor.editors.<index>.propertyPath` = "options.xxx"
+then (for example) "options.xxx.yyy" is a valid property path to write.
+
+If a form elements finisher|validator property is defined in the form editor setup then it means that the form elements finisher|validator property can be written by the form editor.
+A form elements finisher|validator property can be written if the property path is defined within the following form editor properties:
+
+* :yaml:`formElementsDefinition.<formElementType>.formEditor.propertyCollections.<finishers|validators>.<index>.editors.<index>.propertyPath`
+* :yaml:`formElementsDefinition.<formElementType>.formEditor.propertyCollections.<finishers|validators>.<index>.editors.<index>.*.propertyPath`
+
+If a form elements finisher|validator property :yaml:`templateName` is "Inspector-PropertyGridEditor" or "Inspector-MultiSelectEditor" or "Inspector-ValidationErrorMessageEditor"
+it means that the form editor property :yaml:`propertyPath` is interpreted as a so called "multiValueProperty".
+A "multiValueProperty" can contain any subproperties relative to the value from :yaml:`propertyPath` which are valid.
+If :yaml:`formElementsDefinition.<formElementType>.formEditor.propertyCollections.<finishers|validators>.<index>.editors.<index>.templateName` = "Inspector-PropertyGridEditor"
+and :yaml:`formElementsDefinition.<formElementType>.formEditor.propertyCollections.<finishers|validators>.<index>.editors.<index>.propertyPath` = "options.xxx"
+that (for example) "options.xxx.yyy" is a valid property path to write.
+
+If you use a custom form editor JavaScript "inspector editor" implementation (see https://docs.typo3.org/typo3cms/extensions/form/Concepts/FormEditor/Index.html#inspector)
+which does not define the writable property paths by one of the above described inspector editor properties (e.g :yaml:`propertyPath`) within the form setup,
+you must provide the writable property paths with a hook. Otherwise the editor will fail when saving.
+
+
+Connect to the hook:
+
+.. code-block:: php
+
+    $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['ext/form']['buildFormDefinitionValidationConfiguration'][] = \Vendor\YourNamespace\YourClass::class;
+
+Use the hook:
+
+The hook must return an array with a set of ValidationDto objects.
+
+.. code-block:: php
+
+    /**
+     * @param \TYPO3\CMS\Form\Domain\Configuration\FormDefinition\Validators\ValidationDto $validationDto
+     * @return array
+     */
+    public function addAdditionalPropertyPaths(\TYPO3\CMS\Form\Domain\Configuration\FormDefinition\Validators\ValidationDto $validationDto): array
+    {
+        // Create a ValidationDto object for the form element type "Form" (:yaml:`formElementsDefinition.<formElementType>`).
+        $formValidationDto = $validationDto->withFormElementType('Form');
+        // Create a ValidationDto object for the finishers for the form element type "Form".
+        $formFinishersValidationDto = $formValidationDto->withPropertyCollectionName('finishers');
+
+        // Create a ValidationDto object for the form element type "Text" (:yaml:`formElementsDefinition.<formElementType>`).
+        $textValidationDto = $validationDto->withFormElementType('Text');
+        // Create a ValidationDto object for the validators for the form element type "Text".
+        $textValidatorsValidationDto = $textValidationDto->withPropertyCollectionName('validators');
+
+        // Create a ValidationDto object for the form element type "Date" (:yaml:`formElementsDefinition.<formElementType>`).
+        $dateValidationDto = $validationDto->withFormElementType('Date');
+
+        $propertyPaths = [
+            // Register the property :yaml:`renderingOptions.my.custom.property` for the form element type "Form".
+            // This property can now be written by the form editor.
+            $formValidationDto->withPropertyPath('renderingOptions.my.custom.property'),
+
+            // Register the property :yaml:`options.custom.property` for the finisher "MyCustomFinisher" for the form element type "Form".
+            // "MyCustomFinisher" must be equal to the identifier property from
+            // your custom inspector editor (:yaml:`formElementsDefinition.Form.formEditor.propertyCollections.finishers.<index>.editors.<index>.identifier`)
+            // This property can now be written by the form editor.
+            $formFinishersValidationDto->withPropertyCollectionElementIdentifier('MyCustomFinisher')->withPropertyPath('options.custom.property'),
+
+            // Register the properties :yaml:`properties.my.custom.property` and :yaml:`properties.my.other.custom.property` for the form element type "Text".
+            // This property can now be written by the form editor.
+            $textValidationDto->withPropertyPath('properties.my.custom.property'),
+            $textValidationDto->withPropertyPath('properties.my.other.custom.property'),
+
+            // Register the property :yaml:`options.custom.property` for the validator "CustomValidator" for the form element type "Text".
+            // "CustomValidator" must be equal to the identifier property from
+            // your custom inspector editor (:yaml:`formElementsDefinition.Text.formEditor.propertyCollections.validators.<index>.editors.<index>.identifier`)
+            // This property can now be written by the form editor.
+            $textValidatorsValidationDto->withPropertyCollectionElementIdentifier('CustomValidator')->withPropertyPath('options.custom.property'),
+
+            $textValidatorsValidationDto->withPropertyCollectionElementIdentifier('AnotherCustomValidator')->withPropertyPath('options.other.custom.property'),
+
+            $dateValidationDto->withPropertyPath('properties.custom.property'),
+            // ..
+        ];
+
+        return $propertyPaths;
+    }
+
+
+.. index:: Backend, ext:form

Documentation/Changelog/8.7.x/Important-85361-EXTrte_ckeditor-Re-addTheSoftHyphenButton.rst

@@ -0,0 +1,62 @@
+.. include:: /Includes.rst.txt
+
+.. _important-85361:
+
+====================================================================
+Important: #85361 - EXT:rte_ckeditor - re-add the soft hyphen button
+====================================================================
+
+See :issue:`85361`
+
+Description
+===========
+
+With the switch from htmlArea to CKEditor the soft hyphen button was gone. This functionality is now
+re-added as custom CKEditor plugin.
+
+It is loaded like each other existing CKEditor plugin in the TYPO3 core via
+:file:`EXT:rte_ckeditor/Configuration/RTE/Editor/Plugins.yaml`. It's automatically loaded in
+the RTE presets "default" and "full". The shortcut `Ctrl` + `-` for adding a soft hyphen works
+without showing the button in the CKEditor button bar.
+
+Impact
+======
+
+By using the shipped RTE presets "default" or "full", the functionality and the toolbar button is
+automatically added to CKEditor toolbar. This helps the editor immensely to create better content for
+the responsive web these days.
+
+How to activate the functionality in a custom RTE preset
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The functionality is automatically added if you are importing
+:file:`EXT:rte_ckeditor/Configuration/RTE/Editor/Plugins.yaml` in your custom RTE preset. If your
+custom RTE preset can't rely on that file, you can explicitly import this plugin as shown:
+
+.. code-block:: yaml
+
+   editor:
+     externalPlugins:
+       softhyphen:
+         resource: "EXT:rte_ckeditor/Resources/Public/JavaScript/Plugins/softhyphen/"
+         # set whether the shortcut for this plugin is activated or not
+         enableShortcut: true
+
+
+How to add the button in a custom RTE preset
+''''''''''''''''''''''''''''''''''''''''''''
+
+The button with the buttonName `softHyphen` of the plugin is assigned to a toolbarGroup named
+`insertcharacters`. Based on how you like to configure the toolbar in your RTE preset you must either
+use the toolbarGroup or the buttonName to display the button at the desired location in the toolbar.
+
+Please take look into the supplied RTE presets to see working examples:
+
+- :file:`EXT:rte_ckeditor/Configuration/RTE/Default.yaml`
+- :file:`EXT:rte_ckeditor/Configuration/RTE/Full.yaml`
+
+More information can be found in the official CKEditor 4 documentation (toolbar concepts):
+
+- https://docs.ckeditor.com/ckeditor4/latest/guide/dev_toolbarconcepts.html
+
+.. index:: RTE, ext:rte_ckeditor

Documentation/Changelog/8.7.x/Important-85385-IntegratePharStreamWrapper.rst

@@ -0,0 +1,44 @@
+.. include:: /Includes.rst.txt
+
+.. _important-85385-1668719172:
+
+=================================================
+Important: #85385 - Integrate Phar Stream Wrapper
+=================================================
+
+See :issue:`85385`
+
+Description
+===========
+
+In order to solve the issues mentioned in the `security advisory TYPO3-SA-2018-002`_
+a new `PharStreamWrapper` has been integrated that intercepts all according stream actions using the `phar://` stream prefix.
+
+`PharStreamWrapper` only allows invocation of Phar files that are located in the usual extension directory located in
+`typo3conf/ext/` - Phar files stored at different locations cannot be invoked anymore.
+
+When using Phar files in extensions PHP's `__DIR__` magic constant has to be avoided
+and replaced by according TYPO3 file resolving instead. This is required in order to
+allow extensions being referenced using symbolic links - when `__DIR__` points to
+the source which is probably outside of `typo3conf/ext/` and thus denies the expected
+Phar file invocation.
+
+.. code-block:: php
+
+   // ...
+   include_once 'phar://' . __DIR__ . '/Resources/bundle.phar/vendor/autoload.php';
+   // ...
+
+has to be adjusted to the following instead, using `ExtensionManagementUtility::extPath()` in order to resolve the proper path
+
+.. code-block:: php
+
+   // ...
+   include_once 'phar://' . \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::extPath('my_extension')
+     . '/Resources/bundle.phar/vendor/autoload.php';
+   // ...
+
+.. _security advisory TYPO3-SA-2018-002: https://typo3.org/security/advisory/typo3-core-sa-2018-002/
+
+
+.. index:: PHP-API, ext:core

Documentation/Changelog/8.7.x/Important-85689-ReplacedDefaultValueWithPlaceholderInExternalUrlLinkHandler.rst

@@ -0,0 +1,20 @@
+.. include:: /Includes.rst.txt
+
+.. _important-85689:
+
+========================================================================================
+Important: #85689 - Replaced default value with placeholder in external url link handler
+========================================================================================
+
+See :issue:`85689`
+
+Description
+===========
+
+The :php:`UrlLinkHandler` in EXT:recordlist used a default input value "http://" for external links.
+This is not practical because editors often paste a link in the field. This caused broken links due
+to duplicate HTTP protocols, for example: `http://https://typo3.org/`
+
+A placeholder is now used instead of a default value. Editors can paste links directly and do not have to remove a default value first.
+
+.. index:: PHP-API, Backend

Documentation/Changelog/8.7.x/Important-87298-DestroySessionsOnPasswordChange.rst

@@ -0,0 +1,50 @@
+.. include:: /Includes.rst.txt
+
+.. _important-87298:
+
+==================================================================
+Important: #87298 - [SECURITY] Destroy sessions on password change
+==================================================================
+
+See :issue:`87298`
+
+Description
+===========
+
+If a user - backend or frontend - changes the password, all existing sessions of that user
+must be destroyed for security reasons.
+
+In the core, we added functionality which takes care of this task with a DataHandler hook.
+Changing passwords in the backend will destroy all existing sessions of the edited user.
+
+The frontend login extension takes care of this task if the user resets a password (password recovery process).
+
+For all third party extensions which also handle password changes we added a method to
+the SessionManager class to easily integrate this important task, please check the code below:
+
+.. code-block:: php
+
+   # For any example below, we need the SessionManager
+   use \TYPO3\CMS\Core\Session\SessionManager;
+
+   # 1) Example: Destroy all backend user sessions for a backend user
+   $sessionManager = GeneralUtility::makeInstance(SessionManager::class);
+   $sessionBackend = $sessionManager->getSessionBackend('BE');
+   $sessionManager->invalidateAllSessionsByUserId($sessionBackend, (int)$id);
+
+   # 2) Example: Destroy all frontend user sessions for a frontend user
+   $sessionManager = GeneralUtility::makeInstance(SessionManager::class);
+   $sessionBackend = $sessionManager->getSessionBackend('FE');
+   $sessionManager->invalidateAllSessionsByUserId($sessionBackend, (int)$id);
+
+   # 3) Example: Destroy all backend user sessions for a backend user but keep and renew current backend user session
+   $sessionManager = GeneralUtility::makeInstance(SessionManager::class);
+   $sessionBackend = $sessionManager->getSessionBackend('BE');
+   $sessionManager->invalidateAllSessionsByUserId($sessionBackend, (int)$id, $GLOBALS['BE_USER']);
+
+   # 4) Example: Destroy all frontend user sessions for a frontend user but keep and renew current frontend user session
+   $sessionManager = GeneralUtility::makeInstance(SessionManager::class);
+   $sessionBackend = $sessionManager->getSessionBackend('FE');
+   $sessionManager->invalidateAllSessionsByUserId($sessionBackend, (int)$id, $GLOBALS['TSFE']->fe_user);
+
+.. index:: Backend, Frontend, PHP-API, ext:core

Documentation/Changelog/8.7.x/Important-88302-PreventOverridingCKEditorConfigFromPlugins.rst

@@ -0,0 +1,55 @@
+.. include:: /Includes.rst.txt
+
+.. _important-88302:
+
+===================================================================
+Important: #88302 - Prevent overriding CKEditor config from plugins
+===================================================================
+
+See :issue:`88302`
+
+Description
+===========
+
+Configuration from external plugins is now only set if the plugin actually
+provided some. By default, the plugin name is used for any configuration
+provided by an external plugin. Since the name of the internal configuration
+setting can be chosen by the author of a plugin we now provide a new option
+"configName" to adjust the name that should be used.
+
+Input
+
+.. code-block:: yaml
+
+   editor:
+     externalPlugins:
+       myplugin:
+         resource: "EXT:my_extension/Resources/Public/JavaScript/Contrib/plugins/myplugin/"
+         route: "myroute"
+         configName: "super_config"
+         option1: "value1"
+         option2: "value2"
+         option3: "value3"
+
+Output
+
+.. code-block:: js
+
+   CKEDITOR.plugins.addExternal(
+      'myplugin',
+      'typo3conf/ext/my_extension/Resources/Public/JavaScript/Contrib/plugins/myplugin/'
+   );
+
+.. code-block:: yaml
+
+   editor:
+     config:
+       super_config:
+         route: "myroute"
+         routeUrl: "/typo3/index.php?route=myroute"
+         option1: "value1"
+         option2: "value2"
+         option3: "value3"
+         option3: "value3"
+
+.. index:: JavaScript, RTE, ext:rte_ckeditor

Documentation/Changelog/8.7.x/Index.rst

@@ -0,0 +1,55 @@
+:template: changelogOverview.html
+.. include:: /Includes.rst.txt
+..  _changelog-8-7-x:
+
+8.7.x Changes
+=============
+
+Changes after 8.7.0 LTS release.
+
+**Table of contents**
+
+.. contents::
+   :local:
+   :depth: 1
+
+Breaking
+^^^^^^^^^
+
+.. toctree::
+   :maxdepth: 1
+   :titlesonly:
+   :glob:
+
+   Breaking-*
+
+Features
+^^^^^^^^
+
+.. toctree::
+   :maxdepth: 1
+   :titlesonly:
+   :glob:
+
+   Feature-*
+
+
+Deprecation
+^^^^^^^^^^^
+
+.. toctree::
+   :maxdepth: 1
+   :titlesonly:
+   :glob:
+
+   Deprecation-*
+
+Important
+^^^^^^^^^
+
+.. toctree::
+   :maxdepth: 1
+   :titlesonly:
+   :glob:
+
+   Important-*