[TASK] Move documentation files into 9.5 folder - part 2 45/58545/3
authorAnja <aleichsenring@ab-softlab.de>
Mon, 1 Oct 2018 19:50:09 +0000 (21:50 +0200)
committerWouter Wolters <typo3@wouterwolters.nl>
Mon, 1 Oct 2018 20:27:55 +0000 (22:27 +0200)
Change-Id: Ic2ad05680c072f901c200b05810be958204825db
Releases: master
Resolves: #86434
Reviewed-on: https://review.typo3.org/58545
Reviewed-by: Christian Kuhn <lolli@schwarzbu.ch>
Tested-by: TYPO3com <no-reply@typo3.com>
Tested-by: Christian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Wouter Wolters <typo3@wouterwolters.nl>
Tested-by: Wouter Wolters <typo3@wouterwolters.nl>
32 files changed:
typo3/sysext/core/Documentation/Changelog/9.5/Breaking-86492-RemovedStdWrapSupportForConfigadditionalHeaders.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.5/Deprecation-83793-FALResourceStorage-dumpFileContents.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.5/Deprecation-86433-VariousStdWrapFunctionsAndContentObjectRenderer-relatedMethods.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.5/Deprecation-86438-PageRenderer-loadJQuery.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.5/Deprecation-86439-MarkSeveralMethodsWithinTemplateServiceAsInternal.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.5/Deprecation-86440-InternalMethodsAndPropertiesWithinRteHtmlParser.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.5/Deprecation-86441-VariousMethodsAndPropertiesInsideBackendUserAuthentication.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.5/Deprecation-86461-MarkVariousTypoScriptParsingFunctionalityAsInternal.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.5/Deprecation-86466-AbstractUserAuthentication-fetchUserRecord.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.5/Deprecation-86486-TypoScriptFrontendController-processOutput.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.5/Feature-86160-PageTypeEnhancerForMappingTypeParameter.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.5/Feature-86365-RoutingEnhancersAndAspects.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.5/Feature-86457-TCATypeSlugAddsAPrependingSlash.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.5/Important-82363-MakeExtBaseTranslationHandlingConsistentWithTyposcript.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.5/Important-85560-LocationOfXLFLabelsChanged.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/master/Breaking-86492-RemovedStdWrapSupportForConfigadditionalHeaders.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Deprecation-83793-FALResourceStorage-dumpFileContents.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Deprecation-86433-VariousStdWrapFunctionsAndContentObjectRenderer-relatedMethods.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Deprecation-86438-DeprecatePageRenderer-loadJQuery.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Deprecation-86439-MarkSeveralMethodsWithinTemplateServiceAsInternal.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Deprecation-86440-InternalMethodsAndPropertiesWithinRteHtmlParser.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Deprecation-86441-VariousMethodsAndPropertiesInsideBackendUserAuthentication.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Deprecation-86461-MarkVariousTypoScriptParsingFunctionalityAsInternal.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Deprecation-86466-AbstractUserAuthentication-fetchUserRecord.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Deprecation-86486-TypoScriptFrontendController-processOutput.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-86160-PageTypeEnhancerForMappingTypeParameter.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-86365-RoutingEnhancersAndAspects.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-86457-TCATypeSlugAddsAPrependingSlash.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Important-82363-MakeExtBaseTranslationHandlingConsistentWithTyposcript.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Important-85560-LocationOfXLFLabelsDownloaded.rst [deleted file]
typo3/sysext/install/Configuration/ExtensionScanner/Php/ClassConstantMatcher.php
typo3/sysext/install/Configuration/ExtensionScanner/Php/MethodCallMatcher.php

diff --git a/typo3/sysext/core/Documentation/Changelog/9.5/Breaking-86492-RemovedStdWrapSupportForConfigadditionalHeaders.rst b/typo3/sysext/core/Documentation/Changelog/9.5/Breaking-86492-RemovedStdWrapSupportForConfigadditionalHeaders.rst
new file mode 100644 (file)
index 0000000..cf8d7e7
--- /dev/null
@@ -0,0 +1,35 @@
+.. include:: ../../Includes.txt
+
+=======================================================================
+Breaking: #86492 - Removed stdWrap support for config.additionalHeaders
+=======================================================================
+
+See :issue:`86492`
+
+Description
+===========
+
+The feature to use :ts:`stdWrap` for :ts:`config.additionalHeaders` has been removed due to
+an incompatibility with page caching.
+
+
+Impact
+======
+
+:ts:`stdWrap` cannot be used anymore to manipulate additional headers set via TypoScript.
+
+
+Affected Installations
+======================
+
+Any TYPO3 instance that uses this feature, which has been introduced with version 9.0.
+
+
+Migration
+=========
+
+For the time being there will be no TypoScript based solution for dynamic HTTP headers.
+
+Consider implementing a PSR-15 middleware to add advanced logic for additional frontend response headers.
+
+.. index:: Frontend, TypoScript, NotScanned, ext:frontend
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/9.5/Deprecation-83793-FALResourceStorage-dumpFileContents.rst b/typo3/sysext/core/Documentation/Changelog/9.5/Deprecation-83793-FALResourceStorage-dumpFileContents.rst
new file mode 100644 (file)
index 0000000..d73a33b
--- /dev/null
@@ -0,0 +1,32 @@
+.. include:: ../../Includes.txt
+
+=============================================================
+Deprecation: #83793 - FAL ResourceStorage->dumpFileContents()
+=============================================================
+
+See :issue:`83793`
+
+Description
+===========
+
+The method :php:`TYPO3\CMS\Core\Resource\ResourceStorage->dumpFileContents()` has been marked as deprecated.
+
+
+Impact
+======
+
+Calling this method will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with extensions, which use the method.
+
+
+Migration
+=========
+
+Use :php:`TYPO3\CMS\Core\Resource\ResourceStorage->streamFile()` instead.
+
+.. index:: FAL, PHP-API, FullyScanned
diff --git a/typo3/sysext/core/Documentation/Changelog/9.5/Deprecation-86433-VariousStdWrapFunctionsAndContentObjectRenderer-relatedMethods.rst b/typo3/sysext/core/Documentation/Changelog/9.5/Deprecation-86433-VariousStdWrapFunctionsAndContentObjectRenderer-relatedMethods.rst
new file mode 100644 (file)
index 0000000..f8ff800
--- /dev/null
@@ -0,0 +1,51 @@
+.. include:: ../../Includes.txt
+
+=========================================================================================
+Deprecation: #86433 - Various stdWrap functions and ContentObjectRenderer-related methods
+=========================================================================================
+
+See :issue:`86433`
+
+Description
+===========
+
+The following TypoScript :ts:`stdWrap` sub-properties and functions have been marked as deprecated:
+
+* :ts:`stdWrap.addParams`
+* :ts:`stdWrap.filelist`
+* :ts:`stdWrap.filelink`
+
+In conjunction with the properties, the following methods have been deprecated:
+
+* :php:`TYPO3\CMS\Frontend\ContentObjectRenderer->stdWrap_addParams()`
+* :php:`TYPO3\CMS\Frontend\ContentObjectRenderer->stdWrap_filelink()`
+* :php:`TYPO3\CMS\Frontend\ContentObjectRenderer->stdWrap_filelist()`
+* :php:`TYPO3\CMS\Frontend\ContentObjectRenderer->addParams()`
+* :php:`TYPO3\CMS\Frontend\ContentObjectRenderer->filelink()`
+* :php:`TYPO3\CMS\Frontend\ContentObjectRenderer->filelist()`
+* :php:`TYPO3\CMS\Frontend\ContentObjectRenderer->typolinkWrap()`
+* :php:`TYPO3\CMS\Frontend\ContentObjectRenderer->currentPageUrl()`
+
+These functions were part of TYPO3 Core due to legacy functionality related
+to ContentObject "TABLE" and "CSS Styled Content".
+
+
+Impact
+======
+
+Calling any of the methods or using the properties will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom TypoScript options which have not been migrated to FAL
+or Fluid Styled Content.
+
+
+Migration
+=========
+
+Use Fluid Styled Content, or DataProcessors instead.
+
+.. index:: Frontend, TypoScript, FullyScanned
diff --git a/typo3/sysext/core/Documentation/Changelog/9.5/Deprecation-86438-PageRenderer-loadJQuery.rst b/typo3/sysext/core/Documentation/Changelog/9.5/Deprecation-86438-PageRenderer-loadJQuery.rst
new file mode 100644 (file)
index 0000000..fec3e8f
--- /dev/null
@@ -0,0 +1,36 @@
+.. include:: ../../Includes.txt
+
+================================================
+Deprecation: #86438 - PageRenderer->loadJQuery()
+================================================
+
+See :issue:`86438`
+
+Description
+===========
+
+The method
+:php:`TYPO3\CMS\Core\Page\PageRenderer->loadJQuery()`
+and the constants
+:php:`TYPO3\CMS\Core\Page\PageRenderer::JQUERY_VERSION_LATEST` and
+:php:`TYPO3\CMS\Core\Page\PageRenderer::JQUERY_NAMESPACE_NONE` have been marked as deprecated.
+
+
+Impact
+======
+
+Calling this method will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom or third party extensions, which use the method.
+
+
+Migration
+=========
+
+Use a package manager for frontend or custom jQuery files instead.
+
+.. index:: Backend, Frontend, PHP-API, FullyScanned
diff --git a/typo3/sysext/core/Documentation/Changelog/9.5/Deprecation-86439-MarkSeveralMethodsWithinTemplateServiceAsInternal.rst b/typo3/sysext/core/Documentation/Changelog/9.5/Deprecation-86439-MarkSeveralMethodsWithinTemplateServiceAsInternal.rst
new file mode 100644 (file)
index 0000000..1509041
--- /dev/null
@@ -0,0 +1,38 @@
+.. include:: ../../Includes.txt
+
+=============================================================================
+Deprecation: #86439 - Mark several methods within TemplateService as internal
+=============================================================================
+
+See :issue:`86439`
+
+Description
+===========
+
+The following methods in :php:`\TYPO3\CMS\Core\TypoScript\TemplateService` have been marked as protected:
+
+* :php:`prependStaticExtra()`
+* :php:`versionOL()`
+* :php:`processIncludes()`
+* :php:`mergeConstantsFromPageTSconfig()`
+* :php:`flattenSetup()`
+* :php:`substituteConstants()`
+
+
+Impact
+======
+
+Calling the methods in a public context  will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions working with the :php:`TemplateService` class.
+
+Migration
+=========
+
+Avoid using the methods, and re-implement the functionality on your own, if necessary.
+
+.. index:: Backend, FullyScanned, ext:core
diff --git a/typo3/sysext/core/Documentation/Changelog/9.5/Deprecation-86440-InternalMethodsAndPropertiesWithinRteHtmlParser.rst b/typo3/sysext/core/Documentation/Changelog/9.5/Deprecation-86440-InternalMethodsAndPropertiesWithinRteHtmlParser.rst
new file mode 100644 (file)
index 0000000..e831aa9
--- /dev/null
@@ -0,0 +1,67 @@
+.. include:: ../../Includes.txt
+
+==========================================================================
+Deprecation: #86440 - Internal Methods and properties within RteHtmlParser
+==========================================================================
+
+See :issue:`86440`
+
+Description
+===========
+
+Several methods and properties in class :php:`TYPO3\CMS\Core\Html\RteHtmlParser` have been changed
+from public to protected visibility.
+Some additional functionality has been marked as deprecated, as this has been replaced with the new RTE configuration
+since TYPO3 v8.
+
+The following properties have changed visibility to protected:
+
+* :php:`blockElementList`
+* :php:`recPid`
+* :php:`elRef`
+* :php:`tsConfig`
+* :php:`procOptions`
+* :php:`TS_transform_db_safecounter`
+* :php:`getKeepTags_cache`
+* :php:`allowedClasses`
+
+The following public methods have changed visibility to protected:
+
+* :php:`TS_images_db()`
+* :php:`TS_links_db()`
+* :php:`TS_transform_db()`
+* :php:`TS_transform_rte()`
+* :php:`HTMLcleaner_db()`
+* :php:`getKeepTags()`
+* :php:`divideIntoLines()`
+* :php:`setDivTags()`
+* :php:`getWHFromAttribs()`
+* :php:`urlInfoForLinkTags()` (deprecated, not in use anymore)
+* :php:`TS_AtagToAbs()`
+
+The following processing options (`RTE.proc.`) have been marked as deprecated:
+
+* :ts:`keepPDIVattribs`
+* :ts:`dontRemoveUnknownTags_db`
+
+
+Impact
+======
+
+Setting any of the options, calling the methods above or accessing the properties will trigger a
+PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with extensions or custom usages for RTE handling (e.g. `l10nmgr`).
+
+
+Migration
+=========
+
+Migrate to use the public API only and use other options (such as :ts:`allowAttributes` instead of
+:ts:`dontRemoveUnknownTags_db`) in order to only run certain instructions on the RteHtmlParser object.
+
+.. index:: RTE, FullyScanned, PHP-API
diff --git a/typo3/sysext/core/Documentation/Changelog/9.5/Deprecation-86441-VariousMethodsAndPropertiesInsideBackendUserAuthentication.rst b/typo3/sysext/core/Documentation/Changelog/9.5/Deprecation-86441-VariousMethodsAndPropertiesInsideBackendUserAuthentication.rst
new file mode 100644 (file)
index 0000000..5a44941
--- /dev/null
@@ -0,0 +1,46 @@
+.. include:: ../../Includes.txt
+
+=====================================================================================
+Deprecation: #86441 - Various methods and properties inside BackendUserAuthentication
+=====================================================================================
+
+See :issue:`86441`
+
+Description
+===========
+
+Some minor changes have been made with :php:`TYPO3\CMS\Core\Authentication\BackendUserAuthentication` in order
+to continue cleaning up the code.
+
+The property :php:`checkWorkspaceCurrent_cache` has been marked as protected, as it is an internal cache.
+
+The second argument of method :php:`modAccess()` has been marked as deprecated, as the method should not trigger runtime exceptions anymore.
+
+The method :php:`isPSet()` has been marked as deprecated.
+
+The following - mostly workspaces-related - methods have been marked as "internal":
+
+* :php:`workspaceCannotEditOfflineVersion()`
+* :php:`workspacePublishAccess()`
+* :php:`workspaceSwapAccess()`
+* :php:`workspaceCannotEditOfflineVersion()`
+
+
+Impact
+======
+
+Calling the deprecated method or the protected property will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with enhanced workspace or permission functionality.
+
+
+Migration
+=========
+
+Avoid using the methods, and re-implement the functionality on your own, if necessary.
+
+.. index:: Frontend, FullyScanned, PHP-API
diff --git a/typo3/sysext/core/Documentation/Changelog/9.5/Deprecation-86461-MarkVariousTypoScriptParsingFunctionalityAsInternal.rst b/typo3/sysext/core/Documentation/Changelog/9.5/Deprecation-86461-MarkVariousTypoScriptParsingFunctionalityAsInternal.rst
new file mode 100644 (file)
index 0000000..8ab7557
--- /dev/null
@@ -0,0 +1,57 @@
+.. include:: ../../Includes.txt
+
+===============================================================================
+Deprecation: #86461 - Mark various TypoScript parsing functionality as internal
+===============================================================================
+
+See :issue:`86461`
+
+Description
+===========
+
+The following properties and methods within :php:`TYPO3\CMS\Core\TypoScript\Parser\TypoScriptParser`
+have changed visibility from public to protected as they are used for internal purpose:
+
+* :php:`raw`
+* :php:`rawP`
+* :php:`lastComment`
+* :php:`commentSet`
+* :php:`multiLineEnabled`
+* :php:`multiLineObject`
+* :php:`multiLineValue`
+* :php:`inBrace`
+* :php:`lastConditionTrue`
+* :php:`syntaxHighLight`
+* :php:`highLightData`
+* :php:`highLightData_bracelevel`
+* :php:`highLightStyles`
+* :php:`highLightBlockStyles`
+* :php:`highLightBlockStyles_basecolor`
+* :php:`nextDivider()`
+* :php:`parseSub()`
+* :php:`rollParseSub()`
+* :php:`setVal()`
+* :php:`error()`
+* :php:`regHighLight()`
+* :php:`syntaxHighlight_print()`
+
+
+Impact
+======
+
+Calling any of the methods or accessing any of the properties will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom TypoScript Parsers or extensions which make use of internal
+TypoScript parsings.
+
+
+Migration
+=========
+
+Ensure to only use public entry-points of the TypoScript parsers.
+
+.. index:: TypoScript, FullyScanned, PHP-API
diff --git a/typo3/sysext/core/Documentation/Changelog/9.5/Deprecation-86466-AbstractUserAuthentication-fetchUserRecord.rst b/typo3/sysext/core/Documentation/Changelog/9.5/Deprecation-86466-AbstractUserAuthentication-fetchUserRecord.rst
new file mode 100644 (file)
index 0000000..c8a1a20
--- /dev/null
@@ -0,0 +1,38 @@
+.. include:: ../../Includes.txt
+
+=================================================================
+Deprecation: #86466 - AbstractUserAuthentication->fetchUserRecord
+=================================================================
+
+See :issue:`86466`
+
+Description
+===========
+
+Method :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->fetchUserRecord()`
+has been marked as deprecated.
+
+
+Impact
+======
+
+Calling the method will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+The methods has been called indirectly via
+:php:`TYPO3\CMS\Core\Authentication\AbstractAuthenticationService->fetchUserRecord()` as
+:php:`$this->pObj->fetchUserRecord()`. It has usually not been called directly through
+custom authentication services. Instances are usually not affected by the change, the
+extension scanner will find possible usages.
+
+
+Migration
+=========
+
+If used within authentication services, use :php:`$this->fetchUserRecord()` instead, otherwise
+copy the method around.
+
+.. index:: PHP-API, FullyScanned
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/9.5/Deprecation-86486-TypoScriptFrontendController-processOutput.rst b/typo3/sysext/core/Documentation/Changelog/9.5/Deprecation-86486-TypoScriptFrontendController-processOutput.rst
new file mode 100644 (file)
index 0000000..69629e6
--- /dev/null
@@ -0,0 +1,34 @@
+.. include:: ../../Includes.txt
+
+===================================================================
+Deprecation: #86486 - TypoScriptFrontendController->processOutput()
+===================================================================
+
+See :issue:`86486`
+
+Description
+===========
+
+The method :php:`TypoScriptFrontendController->processOutput()` has been
+marked as deprecated.
+
+
+Impact
+======
+
+Calling this method will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with extensions that use the method.
+
+
+Migration
+=========
+
+Use :php:`TypoScriptFrontendController->applyHttpHeadersToResponse()` and
+:php:`TypoScriptFrontendController->processContentForOutput()` instead, if necessary.
+
+.. index:: Frontend, PHP-API, FullyScanned
diff --git a/typo3/sysext/core/Documentation/Changelog/9.5/Feature-86160-PageTypeEnhancerForMappingTypeParameter.rst b/typo3/sysext/core/Documentation/Changelog/9.5/Feature-86160-PageTypeEnhancerForMappingTypeParameter.rst
new file mode 100644 (file)
index 0000000..6809046
--- /dev/null
@@ -0,0 +1,81 @@
+.. include:: ../../Includes.txt
+
+==============================================================
+Feature: #86160 - PageTypeEnhancer for mapping &type parameter
+==============================================================
+
+See :issue:`86160`
+
+Description
+===========
+
+A new Route Enhancer is added to the newly introduced Routing functionality which allows to add
+a suffix to the existing route (including existing other enhancers) to map a page type (GET parameter &type=)
+to a suffix.
+
+It is now possible to map various page types to endings.
+
+Example TypoScript:
+
+.. code-block:: typoscript
+
+   page = PAGE
+   page.typeNum = 0
+   page.10 = TEXT
+   page.10.value = Default page
+
+   rssfeed = PAGE
+   rssfeed.typeNum = 13
+   rssfeed.10 < plugin.tx_myplugin
+   rssfeed.config.disableAllHeaderCode = 1
+   rssfeed.config.additionalHeaders.10.header = Content-Type: xml/rss
+
+   jsonview = PAGE
+   jsonview.typeNum = 26
+   jsonview.10 = USER
+   jsonview.10.userFunc = MyVendor\MyExtension\Controller\JsonPageController->renderAction
+   jsonview.10.config.disableAllHeaderCode = 1
+   jsonview.10.config.additionalHeaders.10.header = Content-Type: application/json
+
+Now configure the Route Enhancer in your site's :file:`config.yaml` file like this:
+
+.. code-block:: yaml
+
+   routeEnhancers:
+      PageTypeSuffix:
+         type: PageType
+         default: ''
+         map:
+            'rss.feed': 13
+            '.json': 26
+
+
+The :yaml:`map` allows to add a filename or a file ending and map this to a :ts:`page.typeNum` value.
+
+It is also possible to set :yaml:`default` to e.g. ".html" to add a ".html" suffix to all default pages.
+
+.. code-block:: yaml
+
+   routeEnhancers:
+      PageTypeSuffix:
+         type: PageType
+         default: '.json'
+         index: 'index'
+         map:
+            'rss.feed': 13
+            '.json': 26
+
+The :yaml:`index` property is used when generating links on root-level page, thus, instead of e.g. having
+`/en/.json` thus would then result in `/en/index.json`.
+
+Impact
+======
+
+The TYPO3 Frontend-internal `&type` parameter can now also be part of a speaking URL with a simple
+line of configuration.
+
+Please note that the implementation is a Decorator Enhancer, which means that the PageTypeEnhancer
+is only there for adding suffixes to an existing route / variant, but not to substitute something
+within the middle of a speaking URL segment.
+
+.. index:: Frontend
diff --git a/typo3/sysext/core/Documentation/Changelog/9.5/Feature-86365-RoutingEnhancersAndAspects.rst b/typo3/sysext/core/Documentation/Changelog/9.5/Feature-86365-RoutingEnhancersAndAspects.rst
new file mode 100644 (file)
index 0000000..0802498
--- /dev/null
@@ -0,0 +1,453 @@
+.. include:: ../../Includes.txt
+.. highlight:: yaml
+
+===============================================
+Feature: #86365 - Routing Enhancers and Aspects
+===============================================
+
+See :issue:`86365`
+
+Description
+===========
+
+Page-based routing is now flexible by adding enhancers to Routes that are generated or resolved with parameters, which
+were previously appended as GET parameters.
+
+An enhancer creates variants of a specific page-base route for a specific purpose (e.g. one plugin, one Extbase plugin)
+and enhance the existing route path which can contain flexible values, so-called "placeholders".
+
+On top, aspects can be registered to a specific enhancer to modify a specific placeholder, like static speaking names
+within the route path, or dynamically generated.
+
+To give you an overview of what the distinction is, we take a regular page which is available under
+
+`https://www.example.com/path-to/my-page`
+
+to access the Page with ID 13.
+
+Enhancers are ways to extend this route with placeholders on top of this specific route to a page.
+
+`https://www.example.com/path-to/my-page/products/{product-name}`
+
+The suffix `/products/{product-name}` to the base route of the page is added by an enhancer. The placeholder variable
+which is added by the curly braces can then be statically or dynamically resolved or built by an Aspect or more
+commonly known a Mapper.
+
+Enhancers and aspects are activated and configured in a site configuration, currently possible by modifying the
+site's :file:`config.yml` and adding the :yaml:`routeEnhancers` section manually, as there is no UI available for
+this configuration. See examples below.
+
+It is possible to use the same enhancers multiple times with different configurations, however, be aware that
+it is not possible to combine multiple variants / enhancers that match multiple configurations.
+
+However, custom enhancers can be built to overcome special use cases where e.g. two plugins with multiple parameters
+each could be configured. Otherwise, the first variant that matches the URL parameters is used for generation and
+resolving.
+
+Enhancers
+^^^^^^^^^
+
+TYPO3 comes with the following enhancers out of the box:
+
+- Simple Enhancer (enhancer type "Simple")
+- Plugin Enhancer (enhancer type "Plugin")
+- Extbase Plugin Enhancer (enhancer type "Extbase")
+
+Custom enhancers can be registered by adding an entry to an extensions :file:`ext_localconf.php`.
+
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['routing']['CustomPlugin'] = \MyVendor\MyPackage\Routing\CustomEnhancer::class;`
+
+Within a configuration, an enhancer always evaluates the following properties:
+
+* `type` - the short name of the enhancer as registered within :php:`$TYPO3_CONF_VARS`. This is mandatory.
+* `limitToPages` - an array of page IDs where this enhancer should be called. This is optional. This property (array)
+  evaluates to only trigger an enhancer for specific pages. In case of special plugin pages it is
+  useful to only enhance pages with IDs, to speed up performance for building page routes of all other pages.
+
+Simple Enhancer
+---------------
+
+The Simple Enhancer works with various route arguments to map them to a argument to be used later-on.
+
+`index.php?id=13&category=241&tag=Benni`
+results in
+`https://www.example.com/path-to/my-page/241/Benni`
+
+The configuration looks like this::
+
+   routeEnhancers:
+     # Unique name for the enhancers, used internally for referencing
+     CategoryListing:
+       type: Simple
+       limitToPages: [13]
+       routePath: '/show-by-category/{category_id}/{tag}'
+       defaults:
+         tag: ''
+         requirements:
+           category_id: '[0-9]{1..3}'
+           tag: '^[a-zA-Z0-9].*$'
+         _arguments:
+           category_id: 'category'
+
+The configuration option `routePath` defines the static keyword (previously known to some as "postVarSets" keyword for
+some TYPO3 folks), and the available placeholders.
+
+The `requirements` section exactly specifies what kind of parameter should be added to that route as regular expression.
+This way, it is configurable to only allow integer values for e.g. pagination. If the requirements are too loose, a
+URL signature parameter ("cHash") is added to the end of the URL which cannot be removed.
+
+The `defaults` section defines which URL parameters are optional. If the parameters are omitted on generation, they
+can receive a default value, and do not need a placeholder - it is also possible to add them at the very end of the
+`routePath`.
+
+The `_arguments` section defines what Route Parameters should be available to the system. In this example, the
+placeholder is called `category_id` but the URL generation receives the argument `category`, so this is mapped to
+this very name.
+
+An enhancer is only there to replace a set of placeholders and fill in URL parameters or resolve them properly
+later-on, but not to substitute the values with aliases, this can be achieved by Aspects.
+
+
+Plugin Enhancer
+---------------
+
+The Plugin Enhancer works with plugins on a page that are commonly known as `Pi-Based Plugins`, where previously
+the following GET/POST variables were used:
+
+   `index.php?id=13&tx_felogin_pi1[forgot]=1&&tx_felogin_pi1[user]=82&tx_felogin_pi1[hash]=ABCDEFGHIJKLMNOPQRSTUVWXYZ012345`
+
+The base for the plugin enhancer is to configure a so-called "namespace", in this case `tx_felogin_pi1` - the plugin's
+namespace.
+
+The Plugin Enhancer explicitly sets exactly one additional variant for a specific use-case. In case of Frontend Login,
+we would need to set up multiple configurations of Plugin Enhancer for forgot and recover passwords.
+
+::
+
+   routeEnhancers:
+     ForgotPassword:
+       type: Plugin
+       limitToPages: [13]
+       routePath: '/forgot-password/{user}/{hash}'
+       namespace: 'tx_felogin_pi1'
+       defaults:
+         forgot: "1"
+       requirements:
+         user: '[0-9]{1..3}'
+         hash: '^[a-zA-Z0-9]{32}$'
+
+If a URL is generated with the given parameters to link to a page, the result will look like this:
+
+   `https://www.example.com/path-to/my-page/forgot-password/82/ABCDEFGHIJKLMNOPQRSTUVWXYZ012345`
+
+If the input given to generate the URL does not meet the requirements, the route enhancer does not offer the
+variant and the parameters are added to the URL as regular query parameters. If e.g. the user parameter would be more
+than three characters, or non-numeric, this enhancer would not match anymore.
+
+As you see, the Plugin Enhancer is used to specify placeholders and requirements, with a given namespace.
+
+If you want to replace the user ID (in this example "82") with the username, you would need an aspect that can be
+registered within any enhancer, but see below for details on Aspects.
+
+
+Extbase Plugin Enhancer
+-----------------------
+
+When creating extbase plugins, it is very common to have multiple controller/action combinations. The Extbase Plugin
+Enhancer is therefore an extension to the regular Plugin Enhancer, except for the functionality that multiple variants
+are generated, typically built on the amount of controller/action pairs.
+
+The `namespace` option is omitted, as this is built with `extension` and `plugin` name.
+
+The Extbase Plugin enhancer with the configuration below would now apply to the following URLs:
+
+* `index.php?id=13&tx_news_pi1[controller]=News&tx_news_pi1[action]=list`
+* `index.php?id=13&tx_news_pi1[controller]=News&tx_news_pi1[action]=list&tx_news_pi1[page]=5`
+* `index.php?id=13&tx_news_pi1[controller]=News&tx_news_pi1[action]=detail&tx_news_pi1[news]=13`
+* `index.php?id=13&tx_news_pi1[controller]=News&tx_news_pi1[action]=archive&tx_news_pi1[year]=2018&&tx_news_pi1[month]=8`
+
+And generate the following URLs
+
+* `https://www.example.com/path-to/my-page/list/`
+* `https://www.example.com/path-to/my-page/list/5`
+* `https://www.example.com/path-to/my-page/detail/13`
+* `https://www.example.com/path-to/my-page/archive/2018/8`
+
+::
+
+   routeEnhancers:
+     NewsPlugin:
+       type: Extbase
+       limitToPages: [13]
+       extension: News
+       plugin: Pi1
+       routes:
+         - { routePath: '/list/{page}', _controller: 'News::list', _arguments: {'page': '@widget_0/currentPage'} }
+         - { routePath: '/tag/{tag_name}', '_controller': 'News::list', '_arguments': {'tag_name': 'overwriteDemand/tags'}}
+         - { routePath: '/blog/{news_title}', _controller: 'News::detail', _arguments: {'news_title': 'news'} }
+         - { routePath: '/archive/{year}/{month}', _controller: 'News::archive' }
+       defaultController: 'News::list'
+       defaults:
+         page: '0'
+       requirements:
+         page: '\d+'
+
+In this example, you also see that the `_arguments` parameter can be used to bring them into sub properties of an array,
+which is typically the case within demand objects for filtering functionality.
+
+Aspects
+^^^^^^^
+
+Now that we've looked into ways on how to extend a route to a page with arguments, and to put them into the URL
+path as segments, the detailed logic within one placeholder is in an aspect. The most common practice of an aspect
+is a so-called mapper. Map `{news_title}` which is a UID within TYPO3 to the actual news title, which is a field
+within the database table.
+
+An aspect can be a way to modify, beautify or map an argument from the URL generation into a placeholder. That's why
+the terms "Mapper" and "Modifier" will pop up, depending on the different cases.
+
+Aspects are registered within one single enhancer configuration with the option `aspects` and can be used with any
+enhancer.
+
+Let's start with some simpler examples first:
+
+
+StaticValueMapper
+-----------------
+
+The StaticValueMapper replaces values simply on a 1:1 mapping list of an argument into a speaking segment, useful
+for a checkout process to define the steps into "cart", "shipping", "billing", "overview" and "finish", or in a
+simpler example to create speaking segments for all available months.
+
+The configuration could look like this:
+
+::
+
+   routeEnhancers:
+     NewsArchive:
+       type: Extbase
+       limitToPages: [13]
+       extension: News
+       plugin: Pi1
+       routes:
+         - { routePath: '/{year}/{month}', _controller: 'News::archive' }
+       defaultController: 'News::list'
+       defaults:
+         month: ''
+       aspects:
+         month:
+           type: StaticValueMapper
+           map:
+             january: 1
+             february: 2
+             march: 3
+             april: 4
+             may: 5
+             june: 6
+             july: 7
+             august: 8
+             september: 9
+             october: 10
+             november: 11
+             december: 12
+
+
+You'll see the placeholder "month" where the aspect replaces the value to a speaking segment.
+
+It is possible to add an optional `localeMap` to that aspect to use the locale of a value to use in multi-language
+setups.
+
+::
+
+    routeEnhancers:
+      NewsArchive:
+        type: Extbase
+        limitToPages: [13]
+        extension: News
+        plugin: Pi1
+        routes:
+          - { routePath: '/{year}/{month}', _controller: 'News::archive' }
+        defaultController: 'News::list'
+        defaults:
+          month: ''
+        aspects:
+          month:
+            type: StaticValueMapper
+            map:
+              january: 1
+              february: 2
+              march: 3
+              april: 4
+              may: 5
+              june: 6
+              july: 7
+              august: 8
+              september: 9
+              october: 10
+              november: 11
+              december: 12
+          localeMap:
+            - locale: 'de_.*'
+              map:
+                januar: 1
+                februar: 2
+                maerz: 3
+                april: 4
+                mai: 5
+                juni: 6
+                juli: 7
+                august: 8
+                september: 9
+                oktober: 10
+                november: 11
+                dezember: 12
+
+
+LocaleModifier
+--------------
+
+The enhanced part of a route path could be `/archive/{year}/{month}` - however, in multi-language setups, it should be
+possible to rename `/archive/` depending on the language that is given for this page translation. This modifier is a
+good example where a route path is modified but is not affected by arguments.
+
+The configuration could look like this::
+
+   routeEnhancers:
+     NewsArchive:
+       type: Extbase
+       limitToPages: [13]
+       extension: News
+       plugin: Pi1
+       routes:
+         - { routePath: '/{localized_archive}/{year}/{month}', _controller: 'News::archive' }
+       defaultController: 'News::list'
+       aspects:
+         localized_archive:
+           type: LocaleModifier
+           default: 'archive'
+           localeMap:
+             - locale: 'fr_FR.*|fr_CA.*'
+               value: 'archives'
+             - locale: 'de_DE.*'
+                value: 'archiv'
+
+You'll see the placeholder "localized_archive" where the aspect replaces the localized archive based on the locale of
+the language of that page.
+
+
+StaticRangeMapper
+-----------------
+
+A static range mapper allows to avoid the `cHash` and narrow down the available possibilities for a placeholder,
+and to explicitly define a range for a value, which is recommended for all kinds of pagination functionalities.
+
+::
+
+   routeEnhancers:
+     NewsPlugin:
+       type: Extbase
+       limitToPages: [13]
+       extension: News
+       plugin: Pi1
+       routes:
+         - { routePath: '/list/{page}', _controller: 'News::list', _arguments: {'page': '@widget_0/currentPage'} }
+       defaultController: 'News::list'
+       defaults:
+         page: '0'
+       requirements:
+         page: '\d+'
+       aspects:
+         page:
+           type: StaticRangeMapper
+           start: 1
+           end: 100
+
+This limits down the pagination to max. 100 pages, if a user calls the news list with page 101, then the route enhancer
+does not match and would not apply the placeholder.
+
+PersistedAliasMapper
+--------------------
+
+If an extension ships with a slug field, or a different field used for the speaking URL path, this database field
+can be used to build the URL::
+
+    routeEnhancers:
+      NewsPlugin:
+        type: Extbase
+        limitToPages: [13]
+        extension: News
+        plugin: Pi1
+        routes:
+          - { routePath: '/detail/{news_title}', _controller: 'News::detail', _arguments: {'news_title': 'news'} }
+        defaultController: 'News::detail'
+        aspects:
+          news_title:
+            type: PersistedAliasMapper
+            tableName: 'tx_news_domain_model_news'
+            routeFieldName: 'path_segment'
+            routeValuePrefix: '/'
+
+The PersistedAliasMapper looks up (via a so-called delegate pattern under the hood) to map the given value to a
+a URL. The property `tableName` points to the database table, property `routeFieldName` is the field which will be
+used within the route path for example.
+
+The special `routeValuePrefix` is used for TCA type `slug` fields where the prefix `/` is within all fields of the
+field names, which should be removed in the case above.
+
+If a field is used for `routeFieldName` that is not prepared to be put into the route path, e.g. the news title field,
+it still must be ensured that this is unique. On top, if there are special characters like spaces they will be
+URL-encoded, to ensure a definitive value, a slug TCA field is recommended.
+
+PersistedPatternMapper
+----------------------
+
+When a placeholder should be fetched from multiple fields of the database, the PersistedPatternMapper is for you.
+It allows to combine various fields into one variable, ensuring a unique value by e.g. adding the UID to the field
+without having the need of adding a custom slug field to the system.
+
+::
+
+   routeEnhancers:
+     Blog:
+       type: Extbase
+       limitToPages: [13]
+       extension: BlogExample
+       plugin: Pi1
+       routes:
+         - { routePath: '/blog/{blogpost}', _controller: 'Blog::detail', _arguments: {'blogpost': 'post'} }
+       defaultController: 'Blog::detail'
+       aspects:
+         blogpost:
+           type: PersistedPatternMapper
+           tableName: 'tx_blogexample_domain_model_post'
+           routeFieldPattern: '^(?P<title>.+)-(?P<uid>\d+)$'
+           routeFieldResult: '{title}-{uid}'
+
+The `routeFieldPattern` option builds the title and uid fields from the database, the `routeFieldResult` shows
+how the placeholder will be output.
+
+Impact
+======
+
+Some notes to the implementation:
+
+While accessing a page in TYPO3 in the Frontend, all arguments are currently built back into the global
+GET parameters, but are also available as so-called `PageArguments` object, which is then used to be signed and verified
+that they are valid, when handing them to process a frontend request further.
+
+If there are dynamic parameters (= parameters which are not strictly limited), a verification GET parameter `cHash`
+is added, which can and should not be removed from the URL. The concept of manually activating or deactivating
+the generation of a `cHash` is not optional anymore, but strictly built-in to ensure proper URL handling. If you
+really have the requirement to never have a cHash argument, ensure that all placeholders are having strict definitions
+on what could be the result of the page segment (e.g. pagination), and feel free to build custom mappers.
+
+Setting the TypoScript option `typolink.useCacheHash` is not necessary anymore when running with a site configuration.
+
+Please note that Enhancers and Page-based routing is only available for pages that are built with a site configuration.
+
+All existing APIs like `typolink` or functionality evaluate the new Page Routing API directly and come with route
+enhancers.
+
+Please note that if you update the Site configuration with enhancers that you need to clear all caches.
+
+.. index:: Frontend, PHP-API
diff --git a/typo3/sysext/core/Documentation/Changelog/9.5/Feature-86457-TCATypeSlugAddsAPrependingSlash.rst b/typo3/sysext/core/Documentation/Changelog/9.5/Feature-86457-TCATypeSlugAddsAPrependingSlash.rst
new file mode 100644 (file)
index 0000000..6cc981b
--- /dev/null
@@ -0,0 +1,44 @@
+.. include:: ../../Includes.txt
+
+=======================================================
+Feature: #86457 - TCA Type Slug adds a prepending slash
+=======================================================
+
+See :issue:`86457`
+
+Description
+===========
+
+The new TCA type slug field now hard-codes a slash as a prefix for all pages, as this is
+mandatory for URL resolving and ensuring a uniqueness within a site.
+
+However, for slug types within regular records, it is not necessary to do so, therefore, the slash
+is never prepended on a "regular" slug field.
+
+If - in some special cases - the "slug" field should contain a slash (due to e.g. nested categories
+with speaking segments), a new option `prependSlash` is added to TCA type slug.
+
+
+Impact
+======
+
+Third-party extensions using the slug field now receive a slug value without a slash, and
+can use this as a regular - sanitized - slug field. It is however recommended to use the
+`uniqueInPid` eval option to ensure uniqueness.
+
+If a nested record structure is given, it is recommended to use the new option `prependSlash`
+by setting it to :php:`true`.
+
+.. code-block:: php
+
+    'type' => 'slug',
+    'config' => [
+        'generatorOptions' => [
+            'fields' => ['title'],
+        ]
+        'fallbackCharacter' => '-',
+        'prependSlash' => true,
+        'eval' => 'uniqueInPid'
+    ]
+
+.. index:: TCA
diff --git a/typo3/sysext/core/Documentation/Changelog/9.5/Important-82363-MakeExtBaseTranslationHandlingConsistentWithTyposcript.rst b/typo3/sysext/core/Documentation/Changelog/9.5/Important-82363-MakeExtBaseTranslationHandlingConsistentWithTyposcript.rst
new file mode 100644 (file)
index 0000000..183e31e
--- /dev/null
@@ -0,0 +1,229 @@
+.. include:: ../../Includes.txt
+
+================================================================================
+Important: #82363 - Make Extbase translation handling consistent with TypoScript
+================================================================================
+
+See :issue:`82363`
+
+Description
+===========
+
+Extbase now renders the translated records in the same way TypoScript rendering does.
+The new behaviour is controlled by the Extbase feature switch :typoscript:`consistentTranslationOverlayHandling`.
+
+.. code-block:: typoscript
+
+     config.tx_extbase.features.consistentTranslationOverlayHandling = 1
+
+The new behaviour is default in TYPO3 v9. The feature switch will be removed in TYPO3 v10, so there will be just
+one way of fetching records.
+You can override the setting using normal TypoScript.
+
+
+Impact
+======
+
+Users relying on the old behaviour can disable the feature switch.
+
+The change modifies how Extbase interprets the TypoScript settings
+:ts:`config.sys_language_mode` and :ts:`config.sys_language_overlay` and the
+:php:`Typo3QuerySettings` properties :php:`languageOverlayMode` and :php:`languageMode`.
+
+Changes in the rendering:
+
+1) Setting :php:`Typo3QuerySettings->languageMode` does **not** influence how Extbase queries records anymore.
+   The corresponding TypoScript setting :ts:`config.sys_language_mode` is used by the core
+   to decide what to do when a page is not translated to the given language (display 404, or try page with different language).
+   Users who used to set :php:`Typo3QuerySettings->languageMode` to `strict` should use
+   :php:`Typo3QuerySettings->setLanguageOverlayMode('hideNonTranslated')` to get translated records only.
+
+   The old behavior was confusing, because `languageMode` had different meaning and accepted different
+   values in TS context and in Extbase context.
+
+2) Setting :php:`Typo3QuerySettings->languageOverlayMode` to :php:`true` makes Extbase fetch records
+   from default language and overlay them with translated values. So e.g. when a record is hidden in
+   the default language, it will not be shown. Also records without translation parents will not be shown.
+   For relations, Extbase reads relations from a translated record (so it’s not possible to inherit
+   a field value from translation source) and then passes the related records through :php:`$pageRepository->getRecordOverlay()`.
+   So e.g. when you have a translated `tt_content` with FAL relation, Extbase will show only those
+   `sys_file_reference` records which are connected to the translated record (not caring whether some of
+   these files have `l10n_parent` set).
+
+   Previously :php:`Typo3QuerySettings->languageOverlayMode` had no effect.
+   Extbase always performed an overlay process on the result set.
+
+3) Setting :php:`Typo3QuerySettings->languageOverlayMode` to :php:`false` makes Extbase fetch aggregate
+   root records from a given language only. Extbase will follow relations (child records) as they are,
+   without checking their `sys_language_uid` fields, and then it will pass these records through
+   :php:`$pageRepository->getRecordOverlay()`.
+   This way the aggregate root record's sorting and visibility doesn't depend on default language records.
+   Moreover, the relations of a record, which are often stored using default language uids,
+   are translated in the final result set (so overlay happens).
+
+   For example:
+   Given a translated `tt_content` having relation to 2 categories (in the mm table translated
+   tt_content record is connected to category uid in default language), and one of the categories is translated.
+   Extbase will return a `tt_content` model with both categories.
+   If you want to have just translated category shown, remove the relation in the translated `tt_content`
+   record in the TYPO3 Backend.
+
+Note that by default :php:`Typo3QuerySettings` uses the global TypoScript configuration like
+:ts:`config.sys_language_overlay` and :php:`$GLOBALS['TSFE']->sys_language_content`
+(calculated based on :ts:`config.sys_language_uid` and :ts:`config.sys_language_mode`).
+So you need to change :php:`Typo3QuerySettings` manually only if your Extbase code should
+behave different than other `tt_content` rendering.
+
+Setting :php:`setLanguageOverlayMode()` on a query influences **only** fetching of the aggregate root. Relations are always
+fetched with :php:`setLanguageOverlayMode(true)`.
+
+When querying data in translated language, and having :php:`setLanguageOverlayMode(true)`, the relations
+(child objects) are overlaid even if aggregate root is not translated.
+See :php:`QueryLocalizedDataTest->queryFirst5Posts()`.
+
+Following examples show how to query data in Extbase in different scenarios, independent of the global TS settings:
+
+1) Fetch records from the language uid=1 only, with no overlays.
+   Previously (:ts:`consistentTranslationOverlayHandling = 0`):
+
+   It was not possible.
+
+
+   Now (:ts:`consistentTranslationOverlayHandling = 1`):
+
+   ::
+
+      $querySettings = $query->getQuerySettings();
+      $querySettings->setLanguageUid(1);
+      $querySettings->setLanguageOverlayMode(false);
+
+2) Fetch records from the language uid=1, with overlay, but hide non-translated records
+   Previously (:ts:`consistentTranslationOverlayHandling = 0`):
+
+   ::
+
+      $querySettings = $query->getQuerySettings();
+      $querySettings->setLanguageUid(1);
+      $querySettings->setLanguageMode('strict');
+
+   Now (:ts:`consistentTranslationOverlayHandling = 1`):
+
+   ::
+
+      $querySettings = $query->getQuerySettings();
+      $querySettings->setLanguageUid(1);
+      $querySettings->setLanguageOverlayMode('hideNonTranslated');
+
+
++------------------------+-------------------------------------------------------------------------------------------------+----------------------------------------------+------------------------------+
+| QuerySettings property | old behaviour                                                                                   | new behaviour                                | default value (TSFE|Extbase) |
++========================+=================================================================================================+==============================================+==============================+
+| languageUid            |                                                                                                 | same                                         | 0                            |
++------------------------+-------------------------------------------------------------------------------------------------+----------------------------------------------+------------------------------+
+| respectSysLanguage     |                                                                                                 | same                                         | `true`                       |
++------------------------+-------------------------------------------------------------------------------------------------+----------------------------------------------+------------------------------+
+| languageOverlayMode    | not used                                                                                        | values: `true`, `false`, `hideNonTranslated` | 0 | `true`                   |
+|                        |                                                                                                 |                                              |                              |
++------------------------+-------------------------------------------------------------------------------------------------+----------------------------------------------+------------------------------+
+| languageMode           | documented values: `null`, `content_fallback`, `strict` or `ignore`.                            | not used                                     | `null`                       |
+|                        | Only `strict` was evaluated. Setting `LanguageMode` to `strict`                                 |                                              |                              |
+|                        | caused passing `hideNonTranslated` param to `getRecordOverlay` in :php:`Typo3DbBackend`         |                                              |                              |
+|                        | and changing the query to work similar to TypoScript `sys_language_overlay = hideNonTranslated` |                                              |                              |
++------------------------+-------------------------------------------------------------------------------------------------+----------------------------------------------+------------------------------+
+
+
+Identifiers
+-----------
+
+Domain models have a main identifier `uid` and two additional properties `_localizedUid` and `_versionedUid`.
+Depending on whether the `languageOverlayMode` mode is enabled (`true` or `'hideNonTranslated'`) or disabled (`false`),
+the identifier contains different values.
+When `languageOverlayMode` is enabled then `uid` property contains `uid` value of the default language record,
+the `uid` of the translated record is kept in the `_localizedUid`.
+
++----------------------------------------------------------+-------------------------+---------------------------+
+| Context                                                  | Record in language 0    | Translated record         |
++==========================================================+=========================+===========================+
+| Database                                                 | uid:2                   | uid:11, l10n_parent:2     |
++----------------------------------------------------------+-------------------------+---------------------------+
+| Domain Object values with `languageOverlayMode` enabled  | uid:2, _localizedUid:2  | uid:2, _localizedUid:11   |
++----------------------------------------------------------+-------------------------+---------------------------+
+| Domain Object values with `languageOverlayMode` disabled | uid:2, _localizedUid:2  | uid:11, _localizedUid:11  |
++----------------------------------------------------------+-------------------------+---------------------------+
+
+See tests in :file:`extbase/Tests/Functional/Persistence/QueryLocalizedDataTest.php`.
+
+The :php:`$repository->findByUid()` method takes current rendering language into account (e.g. L=1). It does not take
+`defaultQuerySetting` set on the repository into account.
+The result of this method also depends on whether `languageOverlayMode` is set or not.
+Values in braces show previous behaviour (disabled flag) if different than current.
+
+The bottom line is that with the feature flag on, you can now use  :php:`findByUid()` using translated record uid to get
+translated content independently from language set in global context.
+
++-------------------+----------------+----------------------+----------------------+----------------------+----------------------+
+|                   |                | L=0                                         | L=1                                         |
++-------------------+----------------+----------------------+----------------------+----------------------+----------------------+
+| repository method | property       | Overlay              | No overlay           | Overlay              | No overlay           |
++===================+================+======================+======================+======================+======================+
+| findByUid(2)      | title          | Post 2               | Post 2               | Post 2 (Post 2 - DK) | Post 2 (Post 2 - DK) |
++-------------------+----------------+----------------------+----------------------+----------------------+----------------------+
+|                   | uid            | 2                    | 2                    | 2                    | 2                    |
++-------------------+----------------+----------------------+----------------------+----------------------+----------------------+
+|                   | _localizedUid  | 2                    | 2                    | 2 (11)               | 2 (11)               |
++-------------------+----------------+----------------------+----------------------+----------------------+----------------------+
+| findByUid(11)     | title          | Post 2 - DK (Post 2) | Post 2 - DK (Post 2) | Post 2 - DK          | Post 2 - DK          |
++-------------------+----------------+----------------------+----------------------+----------------------+----------------------+
+|                   | uid            | 2 (2)                | 11 (2)               | 2                    | 11 (2)               |
++-------------------+----------------+----------------------+----------------------+----------------------+----------------------+
+|                   | _localizedUid  | 11 (2)               | 11 (2)               | 11                   | 11                   |
++-------------------+----------------+----------------------+----------------------+----------------------+----------------------+
+
+.. note::
+
+   Note that :php:`$repository->findByUid()` behaves differently than a custom query by an `uid`
+   like :php:`$query->matching($query->equals('uid', 11));` The custom query will return `null` if passed `uid` doesn't match
+   language set in the :php:`$querySettings->setLanguageUid()` method.
+
+Filtering & sorting
+-------------------
+
+When filtering by aggregate root property like `Post->title`,
+both filtering and sorting takes translated values into account and you will get correct results, also with pagination.
+
+When filtering or ordering by child object property, then Extbase does a left join between aggregate root
+table and child record table.
+Then the filter is applied as where clause. This means that filtering or ordering by child record property
+only takes values from child records which uids are stored in db (in most cases its default language record).
+See :php:`TranslationTest::fetchingTranslatedPostByBlogTitle()`
+
+This limitation also applies to Extbase with feature flag being disabled.
+
+Summary of the important code changes
+=====================================
+
+1) :php:`DataMapper` gets a :php:`Query` as a constructor parameter. This allows to use aggregate root :php:`QuerySettings` (language)
+   when fetching child records/relations. Later, in a separate patch we can pass other settings too e.g. :php:`setIgnoreEnableFields`
+   to fix issue around this setting. See :php:`DataMapper->getPreparedQuery` method.
+2) :php:`DataMapper` is passed to  :php:`LazyLoadingProxy` and  :php:`LazyObjectStorage`, so the settings don't get lost when fetching data lazily.
+3) :php:`Query` object gets a new property `parentQuery` which is useful to detect whether we're fetching aggregate root or child object.
+4) Extbase model for  :php:`FileReference` uses `_localizedUid` for fetching `OriginalResource`
+5) :php:`DataMapper` forces child records to be fetched using  :php:`setLanguageOverlayMode(true)`.
+6) When getRespectSysLanguage is set,  :php:`DataMapper` uses aggregate root language to overlay child records to correct language.
+7) The `where` clause used for finding translated records in overlay mode (`true`, `hideNonTranslated`) has been fixed.
+   It filters out the non translated records on db side in case `hideNonTranslated` is set.
+   It allows for filtering and sorting by translated values. See :php:`Typo3DbQueryParser->getLanguageStatement()`
+
+
+Most important known issues (ones this patch doesn't solve)
+===========================================================
+
+- Persistence session uses the same key for default language record and the translation - https://forge.typo3.org/issues/59992
+- Extbase allows to fetch deleted/hidden records - https://forge.typo3.org/issues/86307
+
+
+For more information about rendering please refer to the TypoScript reference_.
+
+.. _reference: https://docs.typo3.org/typo3cms/TyposcriptReference/Setup/Config/Index.html?highlight=sys_language_mode#sys-language-overlay
+
+.. index:: Database, TCA, TypoScript, ext:extbase
diff --git a/typo3/sysext/core/Documentation/Changelog/9.5/Important-85560-LocationOfXLFLabelsChanged.rst b/typo3/sysext/core/Documentation/Changelog/9.5/Important-85560-LocationOfXLFLabelsChanged.rst
new file mode 100644 (file)
index 0000000..360ebec
--- /dev/null
@@ -0,0 +1,18 @@
+.. include:: ../../Includes.txt
+
+==================================================
+Important: #85560 - Location of XLF labels changed
+==================================================
+
+See :issue:`85560`
+
+Description
+===========
+
+Downloaded files for XLF language files are usually stored within :file:`typo3conf/l10n`. When the environment
+variable `TYPO3_PATH_ROOT` is set, which is common for all composer-based installations, the XLF language files
+are now found outside the document root, available under :file:`var/labels/`.
+
+The Environment API :php:`Environment::getLabelsPath()` resolves the correct full location path prefix.
+
+.. index:: PHP-API
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Breaking-86492-RemovedStdWrapSupportForConfigadditionalHeaders.rst b/typo3/sysext/core/Documentation/Changelog/master/Breaking-86492-RemovedStdWrapSupportForConfigadditionalHeaders.rst
deleted file mode 100644 (file)
index cf8d7e7..0000000
+++ /dev/null
@@ -1,35 +0,0 @@
-.. include:: ../../Includes.txt
-
-=======================================================================
-Breaking: #86492 - Removed stdWrap support for config.additionalHeaders
-=======================================================================
-
-See :issue:`86492`
-
-Description
-===========
-
-The feature to use :ts:`stdWrap` for :ts:`config.additionalHeaders` has been removed due to
-an incompatibility with page caching.
-
-
-Impact
-======
-
-:ts:`stdWrap` cannot be used anymore to manipulate additional headers set via TypoScript.
-
-
-Affected Installations
-======================
-
-Any TYPO3 instance that uses this feature, which has been introduced with version 9.0.
-
-
-Migration
-=========
-
-For the time being there will be no TypoScript based solution for dynamic HTTP headers.
-
-Consider implementing a PSR-15 middleware to add advanced logic for additional frontend response headers.
-
-.. index:: Frontend, TypoScript, NotScanned, ext:frontend
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Deprecation-83793-FALResourceStorage-dumpFileContents.rst b/typo3/sysext/core/Documentation/Changelog/master/Deprecation-83793-FALResourceStorage-dumpFileContents.rst
deleted file mode 100644 (file)
index 6bdaa7e..0000000
+++ /dev/null
@@ -1,32 +0,0 @@
-.. include:: ../../Includes.txt
-
-=============================================================
-Deprecation: #83793 - FAL ResourceStorage->dumpFileContents()
-=============================================================
-
-See :issue:`83793`
-
-Description
-===========
-
-The method :php:`ResourceStorage->dumpFileContents()` has been marked as deprecated.
-
-
-Impact
-======
-
-Calling this method will trigger a PHP deprecation notice.
-
-
-Affected Installations
-======================
-
-TYPO3 installations with extensions, which use the method.
-
-
-Migration
-=========
-
-Use :php:`ResourceStorage->streamFile()` instead.
-
-.. index:: FAL, PHP-API, FullyScanned
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Deprecation-86433-VariousStdWrapFunctionsAndContentObjectRenderer-relatedMethods.rst b/typo3/sysext/core/Documentation/Changelog/master/Deprecation-86433-VariousStdWrapFunctionsAndContentObjectRenderer-relatedMethods.rst
deleted file mode 100644 (file)
index 6532846..0000000
+++ /dev/null
@@ -1,50 +0,0 @@
-.. include:: ../../Includes.txt
-
-=========================================================================================
-Deprecation: #86433 - Various stdWrap functions and ContentObjectRenderer-related methods
-=========================================================================================
-
-See :issue:`86433`
-
-Description
-===========
-
-The following TypoScript `stdWrap` sub-properties and functionalities have been deprecated:
-
-- :ts:`stdWrap.addParams`
-- :ts:`stdWrap.filelist`
-- :ts:`stdWrap.filelink`
-
-In conjunction with the properties, the following methods have been deprecated:
-- :php:`TYPO3\CMS\Frontend\ContentObjectRenderer->stdWrap_addParams()`
-- :php:`TYPO3\CMS\Frontend\ContentObjectRenderer->stdWrap_filelink()`
-- :php:`TYPO3\CMS\Frontend\ContentObjectRenderer->stdWrap_filelist()`
-- :php:`TYPO3\CMS\Frontend\ContentObjectRenderer->addParams()`
-- :php:`TYPO3\CMS\Frontend\ContentObjectRenderer->filelink()`
-- :php:`TYPO3\CMS\Frontend\ContentObjectRenderer->filelist()`
-- :php:`TYPO3\CMS\Frontend\ContentObjectRenderer->typolinkWrap()`
-- :php:`TYPO3\CMS\Frontend\ContentObjectRenderer->currentPageUrl()`
-
-These functionalities have been part of TYPO3 Core due to legacy functionalities related
-to ContentObject "TABLE" and "CSS Styled Content".
-
-
-Impact
-======
-
-Calling any of the methods or using the properties will trigger a PHP deprecation notice.
-
-
-Affected Installations
-======================
-
-TYPO3 installations with custom TypoScript options which have not been migrated to FAL
-or Fluid Styled Content.
-
-
-Migration
-=========
-
-Use Fluid Styled Content, or DataProcessors instead.
-
-.. index:: Frontend, TypoScript, FullyScanned
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Deprecation-86438-DeprecatePageRenderer-loadJQuery.rst b/typo3/sysext/core/Documentation/Changelog/master/Deprecation-86438-DeprecatePageRenderer-loadJQuery.rst
deleted file mode 100644 (file)
index cc062de..0000000
+++ /dev/null
@@ -1,32 +0,0 @@
-.. include:: ../../Includes.txt
-
-==========================================================
-Deprecation: #86438 - Deprecate PageRenderer->loadJQuery()
-==========================================================
-
-See :issue:`86438`
-
-Description
-===========
-
-The method :php:`PageRenderer->loadJQuery()` and the constants :php:`PageRenderer::JQUERY_VERSION_LATEST` and :php:`PageRenderer::JQUERY_NAMESPACE_NONE` have been marked as deprecated.
-
-
-Impact
-======
-
-Calling this method will trigger a PHP deprecation notice.
-
-
-Affected Installations
-======================
-
-TYPO3 installations with custom or thrid party extensions, which use the method.
-
-
-Migration
-=========
-
-Use a package manager for frontend or custom jQuery files instead.
-
-.. index:: Backend, Frontend, PHP-API, FullyScanned
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Deprecation-86439-MarkSeveralMethodsWithinTemplateServiceAsInternal.rst b/typo3/sysext/core/Documentation/Changelog/master/Deprecation-86439-MarkSeveralMethodsWithinTemplateServiceAsInternal.rst
deleted file mode 100644 (file)
index 0e58d41..0000000
+++ /dev/null
@@ -1,41 +0,0 @@
-.. include:: ../../Includes.txt
-
-=============================================================================
-Deprecation: #86439 - Mark several methods within TemplateService as internal
-=============================================================================
-
-See :issue:`86439`
-
-Description
-===========
-
-Some minor changes have been made with :php:`\TYPO3\CMS\Core\TypoScript\TemplateService` in order
-to continue cleaning up the code.
-
-The following methods have been marked as protected:
-
-- :php:`prependStaticExtra()`
-- :php:`versionOL()`
-- :php:`processIncludes()`
-- :php:`mergeConstantsFromPageTSconfig()`
-- :php:`flattenSetup()`
-- :php:`substituteConstants()`
-
-
-Impact
-======
-
-Calling the methods in a public context will now trigger a PHP deprecation message.
-
-
-Affected Installations
-======================
-
-TYPO3 installations with custom extensions working with the :php:`TemplateService` class.
-
-Migration
-=========
-
-Avoid using the methods, and re-implement the functionality on your own, if necessary.
-
-.. index:: Backend, FullyScanned, ext:core
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Deprecation-86440-InternalMethodsAndPropertiesWithinRteHtmlParser.rst b/typo3/sysext/core/Documentation/Changelog/master/Deprecation-86440-InternalMethodsAndPropertiesWithinRteHtmlParser.rst
deleted file mode 100644 (file)
index ecabadc..0000000
+++ /dev/null
@@ -1,65 +0,0 @@
-.. include:: ../../Includes.txt
-
-==========================================================================
-Deprecation: #86440 - Internal Methods and properties within RteHtmlParser
-==========================================================================
-
-See :issue:`86440`
-
-Description
-===========
-
-The PHP class :php:`TYPO3\CMS\Core\Html\RteHtmlParser` hasn't been fully touched since the dawn
-of PHP 5, and exposes all properties and methods has public, although these are fully configurable
-and writable. Their visibility has been changed from public to protected, and some additional
-functionality has been marked as deprecated, as this has been replaced with the new RTE configuration
-since TYPO3 v8.
-
-The following properties are marked as protected:
-- :php:`blockElementList`
-- :php:`recPid`
-- :php:`elRef`
-- :php:`tsConfig`
-- :php:`procOptions`
-- :php:`TS_transform_db_safecounter`
-- :php:`getKeepTags_cache`
-- :php:`allowedClasses`
-
-The following public methods have changed visibility to protected:
-- :php:`TS_images_db()`
-- :php:`TS_links_db()`
-- :php:`TS_transform_db()`
-- :php:`TS_transform_rte()`
-- :php:`HTMLcleaner_db()`
-- :php:`getKeepTags()`
-- :php:`divideIntoLines()`
-- :php:`setDivTags()`
-- :php:`getWHFromAttribs()`
-- :php:`urlInfoForLinkTags()` (deprecated, not in use anymore)
-- :php:`TS_AtagToAbs()`
-
-The following processing options (`RTE.proc.`) have been deprecated.
-- keepPDIVattribs
-- dontRemoveUnknownTags_db
-
-
-Impact
-======
-
-Setting any of the option, calling the methods above or accessing the properties will trigger
-a deprecation message.
-
-
-Affected Installations
-======================
-
-TYPO3 installations with extensions on custom usages for RTE handling (e.g. `l10nmgr`).
-
-
-Migration
-=========
-
-Migrate to use the public API only and use other options (such as `allowAttributes` instead of
-`dontRemoveUnknownTags_db`) in order to only run certain instructions on the RteHtmlParser object.
-
-.. index:: RTE, FullyScanned, PHP-API
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Deprecation-86441-VariousMethodsAndPropertiesInsideBackendUserAuthentication.rst b/typo3/sysext/core/Documentation/Changelog/master/Deprecation-86441-VariousMethodsAndPropertiesInsideBackendUserAuthentication.rst
deleted file mode 100644 (file)
index 829a0bb..0000000
+++ /dev/null
@@ -1,45 +0,0 @@
-.. include:: ../../Includes.txt
-
-=====================================================================================
-Deprecation: #86441 - Various methods and properties inside BackendUserAuthentication
-=====================================================================================
-
-See :issue:`86441`
-
-Description
-===========
-
-Some minor changes have been made with :php:`TYPO3\CMS\Core\Authentication\BackendUserAuthentication` in order
-to continue cleaning up the code.
-
-The property :php:`checkWorkspaceCurrent_cache` has been marked as protected, as it is an internal cache.
-
-The second argument of method :php:`modAccess()` has been marked as deprecated, as the method should not trigger runtime exceptions anymore.
-
-The method :php:`isPSet()` has been marked as deprecated.
-
-The following - mostly workspaces-related - methods have been marked as "internal":
-- :php:`workspaceCannotEditOfflineVersion()`
-- :php:`workspacePublishAccess()`
-- :php:`workspaceSwapAccess()`
-- :php:`workspaceCannotEditOfflineVersion()`
-
-
-Impact
-======
-
-Calling the deprecated method or the protected property will now trigger a PHP deprecation message.
-
-
-Affected Installations
-======================
-
-TYPO3 installations with enhanced workspace or permission functionality.
-
-
-Migration
-=========
-
-Avoid using the methods, and re-implement the functionality on your own, if necessary.
-
-.. index:: Frontend, FullyScanned
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Deprecation-86461-MarkVariousTypoScriptParsingFunctionalityAsInternal.rst b/typo3/sysext/core/Documentation/Changelog/master/Deprecation-86461-MarkVariousTypoScriptParsingFunctionalityAsInternal.rst
deleted file mode 100644 (file)
index 65ef9cc..0000000
+++ /dev/null
@@ -1,57 +0,0 @@
-.. include:: ../../Includes.txt
-
-===============================================================================
-Deprecation: #86461 - Mark various TypoScript parsing functionality as internal
-===============================================================================
-
-See :issue:`86461`
-
-Description
-===========
-
-The following properties and methods within :php:`TYPO3\CMS\Core\TypoScript\Parser\TypoScriptParser`
-now have changed visibility from public to protected as they are used for internal purpose:
-
-- :php:`raw`
-- :php:`rawP`
-- :php:`lastComment`
-- :php:`commentSet`
-- :php:`multiLineEnabled`
-- :php:`multiLineObject`
-- :php:`multiLineValue`
-- :php:`inBrace`
-- :php:`lastConditionTrue`
-- :php:`syntaxHighLight`
-- :php:`highLightData`
-- :php:`highLightData_bracelevel`
-- :php:`highLightStyles`
-- :php:`highLightBlockStyles`
-- :php:`highLightBlockStyles_basecolor`
-- :php:`nextDivider()`
-- :php:`parseSub()`
-- :php:`rollParseSub()`
-- :php:`setVal()`
-- :php:`error()`
-- :php:`regHighLight()`
-- :php:`syntaxHighlight_print()`
-
-
-Impact
-======
-
-Calling any of the methods or accessing any of the properties will trigger a deprecation notice.
-
-
-Affected Installations
-======================
-
-TYPO3 installations with custom TypoScript Parsers or extensions which make heavy use of internal
-TypoScript parsings.
-
-
-Migration
-=========
-
-Ensure to only use public entry-points of the TypoScript parsers.
-
-.. index:: TypoScript, FullyScanned, PHP-API
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Deprecation-86466-AbstractUserAuthentication-fetchUserRecord.rst b/typo3/sysext/core/Documentation/Changelog/master/Deprecation-86466-AbstractUserAuthentication-fetchUserRecord.rst
deleted file mode 100644 (file)
index c8a1a20..0000000
+++ /dev/null
@@ -1,38 +0,0 @@
-.. include:: ../../Includes.txt
-
-=================================================================
-Deprecation: #86466 - AbstractUserAuthentication->fetchUserRecord
-=================================================================
-
-See :issue:`86466`
-
-Description
-===========
-
-Method :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->fetchUserRecord()`
-has been marked as deprecated.
-
-
-Impact
-======
-
-Calling the method will trigger a PHP :php:`E_USER_DEPRECATED` error.
-
-
-Affected Installations
-======================
-
-The methods has been called indirectly via
-:php:`TYPO3\CMS\Core\Authentication\AbstractAuthenticationService->fetchUserRecord()` as
-:php:`$this->pObj->fetchUserRecord()`. It has usually not been called directly through
-custom authentication services. Instances are usually not affected by the change, the
-extension scanner will find possible usages.
-
-
-Migration
-=========
-
-If used within authentication services, use :php:`$this->fetchUserRecord()` instead, otherwise
-copy the method around.
-
-.. index:: PHP-API, FullyScanned
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Deprecation-86486-TypoScriptFrontendController-processOutput.rst b/typo3/sysext/core/Documentation/Changelog/master/Deprecation-86486-TypoScriptFrontendController-processOutput.rst
deleted file mode 100644 (file)
index 0471133..0000000
+++ /dev/null
@@ -1,34 +0,0 @@
-.. include:: ../../Includes.txt
-
-===================================================================
-Deprecation: #86486 - TypoScriptFrontendController->processOutput()
-===================================================================
-
-See :issue:`86486`
-
-Description
-===========
-
-The method :php:`TypoScriptFrontendController->processOutput()` has been
-marked as deprecated.
-
-
-Impact
-======
-
-Calling this method will trigger a PHP deprecation notice.
-
-
-Affected Installations
-======================
-
-TYPO3 installations with extensions, which use the method.
-
-
-Migration
-=========
-
-Use :php:`TypoScriptFrontendController->applyHttpHeadersToResponse()` and
-:php:`TypoScriptFrontendController->processContentForOutput()` instead, if necessary.
-
-.. index:: Frontend, PHP-API, FullyScanned
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-86160-PageTypeEnhancerForMappingTypeParameter.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-86160-PageTypeEnhancerForMappingTypeParameter.rst
deleted file mode 100644 (file)
index 95a3512..0000000
+++ /dev/null
@@ -1,81 +0,0 @@
-.. include:: ../../Includes.txt
-
-==============================================================
-Feature: #86160 - PageTypeEnhancer for mapping &type parameter
-==============================================================
-
-See :issue:`86160`
-
-Description
-===========
-
-A new Route Enhancer is added to the newly introduced Routing functionality which allows to add
-a suffix to the existing route (including existing other enhancers) to map a page type (GET parameter &type=)
-to a suffix.
-
-It is now possible to map various page types to endings.
-
-Example TypoScript:
-
-.. code-block:: typoscript
-
-   page = PAGE
-   page.typeNum = 0
-   page.10 = TEXT
-   page.10.value = Default page
-
-   rssfeed = PAGE
-   rssfeed.typeNum = 13
-   rssfeed.10 < plugin.tx_myplugin
-   rssfeed.config.disableAllHeaderCode = 1
-   rssfeed.config.additionalHeaders.10.header = Content-Type: xml/rss
-
-   jsonview = PAGE
-   jsonview.typeNum = 26
-   jsonview.10 = USER
-   jsonview.10.userFunc = MyVendor\MyExtension\Controller\JsonPageController->renderAction
-   jsonview.10.config.disableAllHeaderCode = 1
-   jsonview.10.config.additionalHeaders.10.header = Content-Type: application/json
-
-Now configure the Route Enhancer in your site's `config.yaml` file like this:
-
-.. code-block:: yaml
-
-   routeEnhancers:
-      PageTypeSuffix:
-         type: PageType
-         default: ''
-         map:
-            'rss.feed': 13
-            '.json': 26
-
-
-The `map` allows to add a filename or a file ending and map this to a `page.typeNum` value.
-
-It is also possible to set `default` to e.g. ".html" to add a ".html" suffix to all default pages.
-
-.. code-block:: yaml
-
-   routeEnhancers:
-      PageTypeSuffix:
-         type: PageType
-         default: '.json'
-         index: 'index'
-         map:
-            'rss.feed': 13
-            '.json': 26
-
-The `index` property is used when generating links on root-level page, thus, instead of e.g. having
-`/en/.json` thus would then result in `/en/index.json`.
-
-Impact
-======
-
-The TYPO3 Frontend-internal `&type` parameter can now also be part of a speaking URL with a simple
-line of configuration.
-
-Please note that the implementation is a Decorator Enhancer, which means that the PageTypeEnhancer
-is only there for adding suffixes to an existing route / variant, but not to substitute something
-within the middle of a speaking URL segment.
-
-.. index:: Frontend
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-86365-RoutingEnhancersAndAspects.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-86365-RoutingEnhancersAndAspects.rst
deleted file mode 100644 (file)
index 3b29609..0000000
+++ /dev/null
@@ -1,453 +0,0 @@
-.. include:: ../../Includes.txt
-.. highlight:: yaml
-
-===============================================
-Feature: #86365 - Routing Enhancers and Aspects
-===============================================
-
-See :issue:`86365`
-
-Description
-===========
-
-Page-based routing is now flexible by adding enhancers to Routes that are generated or resolved with parameters, which
-were previously appended as GET parameters.
-
-An enhancer creates variants of a specific page-base route for a specific purpose (e.g. one plugin, one Extbase plugin)
-and enhance the existing route path which can contain flexible values, so-called "placeholders".
-
-On top, aspects can be registered to a specific enhancer to modify a specific placeholder, like static speaking names
-within the route path, or dynamically generated.
-
-To give you an overview of what the distinction are, we take a regular page which is available under
-
-`https://www.example.com/path-to/my-page`
-
-to access the Page with ID 13.
-
-Enhancers are ways to extend this route with placeholders on top of this specific route to a page.
-
-`https://www.example.com/path-to/my-page/products/{product-name}`
-
-The suffix `/products/{product-name}` to the base route of the page is added by an enhancer. The placeholder variable
-which is added by the curly braces can then be statically or dynamically resolved or built by an Aspect or more
-commonly known a Mapper.
-
-Enhancers and aspects are activated and configured in a site configuration, currently possible by modifying the
-site's `config.yml` and adding the `routeEnhancers` section manually, as there is no UI for doing this. See
-examples below.
-
-It is possible to use the same enhancers multiple times with different configurations, however, be aware that
-it is not possible to combine multiple variants / enhancers that match multiple configurations. @todo: How to describe this the best?
-
-However, custom enhancers can be built to overcome special use cases where e.g. two plugins with multiple parameters
-each could be configured. Otherwise, the first variant that matches the URL parameters is used for generation and
-resolving.
-
-Enhancers
-^^^^^^^^^
-
-TYPO3 comes with the following enhancers out of the box:
-
-- Simple Enhancer (enhancer type "Simple")
-- Plugin Enhancer (enhancer type "Plugin")
-- Extbase Plugin Enhancer (enhancer type "Extbase")
-
-Custom enhancers can be registered by adding an entry to an extensions` :php:`ext_localconf.php`.
-
-:php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['routing']['CustomPlugin'] = \MyVendor\MyPackage\Routing\CustomEnhancer::class;`
-
-Within a configuration, an enhancer always evaluates the following properties:
-- `type` - the short name of the enhancer as registered within `$TYPO3_CONF_VARS`. This is mandatory.
-- `limitToPages` - an array of page IDs where this enhancer should be called. This is optional. This property (array)
-  evaluates to only trigger an enhancers for specific pages. In case of special plugin pages it is
-  useful to only enhance pages with IDs, to speed up performance for building page routes of all other pages.
-
-Simple Enhancer
----------------
-
-The Simple Enhancer works with various route arguments to map them to a argument to be used later-on.
-
-   `index.php?id=13&category=241&tag=Benni`
-
-
-`https://www.example.com/path-to/my-page/241/Benni`
-
-The configuration looks like this::
-
-   routeEnhancers:
-     # Unique name for the enhancers, used internally for referencing
-     CategoryListing:
-       type: Simple
-       limitToPages: [13]
-       routePath: '/show-by-category/{category_id}/{tag}'
-       defaults:
-         tag: ''
-         requirements:
-           category_id: '[0-9]{1..3}'
-           tag: '^[a-zA-Z0-9].*$'
-         _arguments:
-           category_id: 'category'
-
-The configuration option `routePath` defines the static keyword (previously known to some as "postVarSets" keyword for
-some TYPO3 folks), and the available placeholders.
-
-The `requirements` section exactly specifies what kind of parameter should be added to that route as regular expression.
-This way, it is configurable to only allow integer values for e.g. pagination. If the requirements are too loose, a
-URL signature parameter ("cHash") is added to the end of the URL which cannot be removed.
-
-The `defaults` section defines which URL parameters are optional. If the parameters are omitted on generation, they
-can receive a default value, and do not need a placeholder - it is also possible to add them at the very end of the
-`routePath`.
-
-The `_arguments` section defines what Route Parameters should be available to the system. In this example, the
-placeholder is called `category_id` but the URL generation receives the argument `category`, so this is mapped to
-this very name.
-
-An enhancer is only there to replace a set of placeholders and fill in URL parameter or resolve them properly
-later-on, but not to substitute the values with aliases, this can be achieved by Aspects.
-
-
-Plugin Enhancer
----------------
-
-The Plugin Enhancer works with plugins on a page that are commonly known as `Pi-Based Plugins`, where previously
-the following GET/POST variables were used:
-
-   `index.php?id=13&tx_felogin_pi1[forgot]=1&&tx_felogin_pi1[user]=82&tx_felogin_pi1[hash]=ABCDEFGHIJKLMNOPQRSTUVWXYZ012345`
-
-The base for the plugin enhancer is to configure a so-called "namespace", in this case `tx_felogin_pi1` - the plugin's
-namespace.
-
-The Plugin Enhancer explicitly sets exactly one additional variant for a specific use-case. In case of Frontend Login,
-we would need to set up multiple configurations of Plugin Enhancer for forgot and recover passwords.
-
-::
-
-   routeEnhancers:
-     ForgotPassword:
-       type: Plugin
-       limitToPages: [13]
-       routePath: '/forgot-password/{user}/{hash}'
-       namespace: 'tx_felogin_pi1'
-       defaults:
-         forgot: "1"
-       requirements:
-         user: '[0-9]{1..3}'
-         hash: '^[a-zA-Z0-9]{32}$'
-
-If a URL is generated with the given parameters to link to a page, the result will look like this:
-
-   `https://www.example.com/path-to/my-page/forgot-password/82/ABCDEFGHIJKLMNOPQRSTUVWXYZ012345`
-
-If the input given to generate the URL does not meet the requirements, the route enhancer does not offer the
-variant and the parameters are added to the URL as regular query parameters. If e.g. the user parameter would be more
-than three characters, or non-numeric, this enhancer would not match anymore.
-
-As you see, the Plugin Enhancer is used to specify placeholders and requirements, with a given namespace.
-
-If you want to replace the user ID (in this example "82") with the username, you would need an aspect that can be
-registered within any enhancer, but see below for details on Aspects.
-
-
-Extbase Plugin Enhancer
------------------------
-
-When creating extbase plugins, it is very common to have multiple controller/action combinations. The Extbase Plugin
-Enhancer is therefore an extension to the regular Plugin Enhancer, except for the functionality that multiple variants
-are generated, typically built on the amount of controller/action pairs.
-
-The `namespace` option is omitted, as this is built with `extension` and `plugin` name.
-
-The Extbase Plugin enhancer with the configuration below would now apply to the following URLs:
-
-   `index.php?id=13&tx_news_pi1[controller]=News&tx_news_pi1[action]=list`
-   `index.php?id=13&tx_news_pi1[controller]=News&tx_news_pi1[action]=list&tx_news_pi1[page]=5`
-   `index.php?id=13&tx_news_pi1[controller]=News&tx_news_pi1[action]=detail&tx_news_pi1[news]=13`
-   `index.php?id=13&tx_news_pi1[controller]=News&tx_news_pi1[action]=archive&tx_news_pi1[year]=2018&&tx_news_pi1[month]=8`
-
-And generate the following URLs
-
-   `https://www.example.com/path-to/my-page/list/`
-   `https://www.example.com/path-to/my-page/list/5`
-   `https://www.example.com/path-to/my-page/detail/13`
-   `https://www.example.com/path-to/my-page/archive/2018/8`
-
-::
-
-   routeEnhancers:
-     NewsPlugin:
-       type: Extbase
-       limitToPages: [13]
-       extension: News
-       plugin: Pi1
-       routes:
-         - { routePath: '/list/{page}', _controller: 'News::list', _arguments: {'page': '@widget_0/currentPage'} }
-         - { routePath: '/tag/{tag_name}', '_controller': 'News::list', '_arguments': {'tag_name': 'overwriteDemand/tags'}}
-         - { routePath: '/blog/{news_title}', _controller: 'News::detail', _arguments: {'news_title': 'news'} }
-         - { routePath: '/archive/{year}/{month}', _controller: 'News::archive' }
-       defaultController: 'News::list'
-       defaults:
-         page: '0'
-       requirements:
-         page: '\d+'
-
-In this example, you also see that the `_arguments` parameter can be used to bring them into sub properties of an array,
-which is typically the case within demand objects for filtering functionality.
-
-Aspects
-^^^^^^^
-
-Now that we've looked into ways on how to extend a route to a page with arguments, and to put them into the URL
-path as segments, the detailed logic within one placeholder is in an aspect. The most common practice of an aspect
-is a so-called mapper. Map `{news_title}` which is a UID within TYPO3 to the actual news title, which is a field
-within the database table.
-
-An aspect can be a way to modify, beautify or map an argument from the URL generation into a placeholder. That's why
-the terms "Mapper" and "Modifier" will pop up, depending on the different cases.
-
-Aspects are registered within one single enhancer configuration with the option `aspects` and can be used with any
-enhancer.
-
-Let's start with some simpler examples first:
-
-
-StaticValueMapper
------------------
-
-The StaticValueMapper replaces values simply on a 1:1 mapping list of an argument into a speaking segment, useful
-for a checkout process to define the steps into "cart", "shipping", "billing", "overview" and "finish", or in a
-simpler example to create speaking segments for all available months.
-
-The configuration could look like this:
-
-::
-
-   routeEnhancers:
-     NewsArchive:
-       type: Extbase
-       limitToPages: [13]
-       extension: News
-       plugin: Pi1
-       routes:
-         - { routePath: '/{year}/{month}', _controller: 'News::archive' }
-       defaultController: 'News::list'
-       defaults:
-         month: ''
-       aspects:
-         month:
-           type: StaticValueMapper
-           map:
-             january: 1
-             february: 2
-             march: 3
-             april: 4
-             may: 5
-             june: 6
-             july: 7
-             august: 8
-             september: 9
-             october: 10
-             november: 11
-             december: 12
-
-
-You'll see the placeholder "month" where the aspect replaces the value to a speaking segment.
-
-It is possible to add an optional `localeMap` to that aspect to use the locale of a value to use in multi-language
-setups.
-
-::
-
-    routeEnhancers:
-      NewsArchive:
-        type: Extbase
-        limitToPages: [13]
-        extension: News
-        plugin: Pi1
-        routes:
-          - { routePath: '/{year}/{month}', _controller: 'News::archive' }
-        defaultController: 'News::list'
-        defaults:
-          month: ''
-        aspects:
-          month:
-            type: StaticValueMapper
-            map:
-              january: 1
-              february: 2
-              march: 3
-              april: 4
-              may: 5
-              june: 6
-              july: 7
-              august: 8
-              september: 9
-              october: 10
-              november: 11
-              december: 12
-          localeMap:
-            - locale: 'de_.*'
-              map:
-                januar: 1
-                februar: 2
-                maerz: 3
-                april: 4
-                mai: 5
-                juni: 6
-                juli: 7
-                august: 8
-                september: 9
-                oktober: 10
-                november: 11
-                dezember: 12
-
-
-LocaleModifier
---------------
-
-The enhanced part of a route path could be `/archive/{year}/{month}` - however, in multi-language setups, it should be
-possible to rename `/archive/` depending on the language that is given for this page translation. This modifier is a
-good example where a route path is modified but is not affected by arguments.
-
-The configuration could look like this::
-
-   routeEnhancers:
-     NewsArchive:
-       type: Extbase
-       limitToPages: [13]
-       extension: News
-       plugin: Pi1
-       routes:
-         - { routePath: '/{localized_archive}/{year}/{month}', _controller: 'News::archive' }
-       defaultController: 'News::list'
-       aspects:
-         localized_archive:
-           type: LocaleModifier
-           default: 'archive'
-           localeMap:
-             - locale: 'fr_FR.*|fr_CA.*'
-               value: 'archives'
-             - locale: 'de_DE.*'
-                value: 'archiv'
-
-You'll see the placeholder "localized_archive" where the aspect replaces the localized archive based on the locale of
-the language of that page.
-
-
-StaticRangeMapper
------------------
-
-A static range mapper allows to avoid the `cHash` and narrow down the available possibilities for a placeholder,
-and to explicitly define a range for a value, which is recommended for all kinds of pagination functionalities.
-
-::
-
-   routeEnhancers:
-     NewsPlugin:
-       type: Extbase
-       limitToPages: [13]
-       extension: News
-       plugin: Pi1
-       routes:
-         - { routePath: '/list/{page}', _controller: 'News::list', _arguments: {'page': '@widget_0/currentPage'} }
-       defaultController: 'News::list'
-       defaults:
-         page: '0'
-       requirements:
-         page: '\d+'
-       aspects:
-         page:
-           type: StaticRangeMapper
-           start: 1
-           end: 100
-
-This limits down the pagination to max. 100 pages, if a user calls the news list with page 101, then the route enhancer
-does not match and would not apply the placeholder.
-
-PersistedAliasMapper
---------------------
-
-If an extension ships with a slug field, or a different field used for the speaking URL path, this database field
-can be used to build the URL::
-
-    routeEnhancers:
-      NewsPlugin:
-        type: Extbase
-        limitToPages: [13]
-        extension: News
-        plugin: Pi1
-        routes:
-          - { routePath: '/detail/{news_title}', _controller: 'News::detail', _arguments: {'news_title': 'news'} }
-        defaultController: 'News::detail'
-        aspects:
-          news_title:
-            type: PersistedAliasMapper
-            tableName: 'tx_news_domain_model_news'
-            routeFieldName: 'path_segment'
-            routeValuePrefix: '/'
-
-The PersistedAliasMapper looks up (via a so-called delegate pattern under the hood) to map the given value to a
-a URL. The property `tableName` points to the database table, property `routeFieldName` is the field which will be
-used within the route path for example.
-
-The special `routeValuePrefix` is used for TCA type `slug` fields where the prefix `/` is within all fields of the
-field names, which should be removed in the case above.
-
-If a field is used for `routeFieldName` that is not prepared to be put into the route path, e.g. the news title field,
-it still must be ensured that this is unique. On top, if there are special characters like spaces they will be
-URL-encoded, to ensure a definitive value, a slug TCA field is recommended.
-
-PersistedPatternMapper
-----------------------
-
-When a placeholder should be fetched from multiple fields of the database, the PersistedPatternMapper is for you.
-It allows to combine various fields into one variable, ensuring a unique value by e.g. adding the UID to the field
-without having the need of adding a custom slug field to the system.
-
-::
-
-   routeEnhancers:
-     Blog:
-       type: Extbase
-       limitToPages: [13]
-       extension: BlogExample
-       plugin: Pi1
-       routes:
-         - { routePath: '/blog/{blogpost}', _controller: 'Blog::detail', _arguments: {'blogpost': 'post'} }
-       defaultController: 'Blog::detail'
-       aspects:
-         blogpost:
-           type: PersistedPatternMapper
-           tableName: 'tx_blogexample_domain_model_post'
-           routeFieldPattern: '^(?P<title>.+)-(?P<uid>\d+)$'
-           routeFieldResult: '{title}-{uid}'
-
-The `routeFieldPattern` option builds the title and uid fields from the database, the `routeFieldResult` shows
-how the placeholder will be output.
-
-Impact
-======
-
-Some notes to the implementation:
-
-While accessing a page in TYPO3 in the Frontend, all arguments are currently built back into the global
-GET parameters, but also available as so-called `PageArguments` object, which is then used to be signed and verified
-that they are valid, when handing them to process a frontend request further.
-
-If there are dynamic parameters (= parameters which are not strictly limited), a verification GET parameter `cHash`
-is added, which can and should not be removed from the URL. The concept of manually activating or deactivating
-the generation of a `cHash` is not optional anymore, but strictly built-in to ensure proper URL handling. If you
-really have the requirement to never have a cHash argument, ensure that all placeholders are having strict definitions
-on what could be the result of the page segment (e.g. pagination), and feel free to build custom mappers.
-
-Setting the TypoScript option `typolink.useCacheHash` is not necessary anymore when running with a site configuration.
-
-Please note that Enhancers and Page-based routing is only available for pages that are built with a site configuration.
-
-All existing APIs like `typolink` or functionality evaluate the new Page Routing API directly and come with route
-enhancers.
-
-Please note that if you update the Site configuration with enhancers that you need to clear all caches.
-
-.. index:: Frontend, PHP-API
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-86457-TCATypeSlugAddsAPrependingSlash.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-86457-TCATypeSlugAddsAPrependingSlash.rst
deleted file mode 100644 (file)
index 219d6ee..0000000
+++ /dev/null
@@ -1,43 +0,0 @@
-.. include:: ../../Includes.txt
-
-=======================================================
-Feature: #86457 - TCA Type Slug adds a prepending slash
-=======================================================
-
-See :issue:`86457`
-
-Description
-===========
-
-The new TCA type slug field now hard-codes a slash as a prefix for all pages, as this is
-mandatory for URL resolving and ensuring a uniqueness within a site.
-
-However, for slug types within regular records, it is not necessary to do so, therefore, the slash
-is never prepended on a "regular" slug field.
-
-If - in some special cases - the "slug" field should contain a slash (due to e.g. nested categories
-with speaking segments), a new option `prependSlash` is added to TCA type slug.
-
-
-Impact
-======
-
-Third-party extensions using the slug field now receive a slug value without a slash, and
-can use this as a regular - sanitized - slug field. It is however, recommended to use the
-`uniqueInPid` eval option to ensure uniqueness.
-
-If a nested record structure is given, it is recommended to use the new option `prependSlash`
-by setting it to :php:`true`.
-
-:php:
-       'type' => 'slug',
-       'config' => [
-               'generatorOptions' => [
-                       'fields' => ['title'],
-               ]
-               'fallbackCharacter' => '-',
-               'prefixSlash' => '/',
-               'eval' => 'uniqueInPid'
-       ]
-
-.. index:: TCA
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Important-82363-MakeExtBaseTranslationHandlingConsistentWithTyposcript.rst b/typo3/sysext/core/Documentation/Changelog/master/Important-82363-MakeExtBaseTranslationHandlingConsistentWithTyposcript.rst
deleted file mode 100644 (file)
index 659b99d..0000000
+++ /dev/null
@@ -1,229 +0,0 @@
-.. include:: ../../Includes.txt
-
-================================================================================
-Important: #82363 - Make Extbase translation handling consistent with TypoScript
-================================================================================
-
-See :issue:`82363`
-
-Description
-===========
-
-Extbase now renders the translated records in the same way TypoScript rendering does.
-The new behaviour is controlled by the Extbase feature switch `consistentTranslationOverlayHandling`.
-
-.. code-block:: typoscript
-
-     config.tx_extbase.features.consistentTranslationOverlayHandling = 1
-
-The new behaviour is default in v9. The feature switch will be removed in v10, so there will be just
-one way of fetching records.
-You can override the setting using normal TypoScript.
-
-
-Impact
-======
-
-Users relying on the old behaviour can disable the feature switch.
-
-The change modifies how Extbase interprets the TypoScript settings
-:ts:`config.sys_language_mode` and :ts:`config.sys_language_overlay` and the
-:php:`Typo3QuerySettings` properties :php:`languageOverlayMode` and :php:`languageMode`.
-
-Changes in the rendering:
-
-1) Setting :php:`Typo3QuerySettings->languageMode` does **not** influence how Extbase queries records anymore.
-   The corresponding TypoScript setting :ts:`config.sys_language_mode` is used by the core
-   to decide what to do when a page is not translated to the given language (display 404, or try page with different language).
-   Users who used to set :php:`Typo3QuerySettings->languageMode` to `strict` should use
-   :php:`Typo3QuerySettings->setLanguageOverlayMode('hideNonTranslated')` to get translated records only.
-
-   The old behavior was confusing, because `languageMode` had different meaning and accepted different
-   values in TS context and in Extbase context.
-
-2) Setting :php:`Typo3QuerySettings->languageOverlayMode` to :php:`true` makes Extbase fetch records
-   from default language and overlay them with translated values. So e.g. when a record is hidden in
-   the default language, it will not be shown. Also records without translation parents will not be shown.
-   For relations, Extbase reads relations from a translated record (so it’s not possible to inherit
-   a field value from translation source) and then passes the related records through :php:`$pageRepository->getRecordOverlay()`.
-   So e.g. when you have a translated `tt_content` with FAL relation, Extbase will show only those
-   `sys_file_reference` records which are connected to the translated record (not caring whether some of
-   these files have `l10n_parent` set).
-
-   Previously :php:`Typo3QuerySettings->languageOverlayMode` had no effect.
-   Extbase always performed an overlay process on the result set.
-
-3) Setting :php:`Typo3QuerySettings->languageOverlayMode` to :php:`false` makes Extbase fetch aggregate
-   root records from a given language only. Extbase will follow relations (child records) as they are,
-   without checking their `sys_language_uid` fields, and then it will pass these records through
-   :php:`$pageRepository->getRecordOverlay()`.
-   This way the aggregate root record's sorting and visibility doesn't depend on default language records.
-   Moreover, the relations of a record, which are often stored using default language uids,
-   are translated in the final result set (so overlay happens).
-
-   For example:
-   Given a translated `tt_content` having relation to 2 categories (in the mm table translated
-   tt_content record is connected to category uid in default language), and one of the categories is translated.
-   Extbase will return a `tt_content` model with both categories.
-   If you want to have just translated category shown, remove the relation in the translated `tt_content`
-   record in the TYPO3 Backend.
-
-Note that by default :php:`Typo3QuerySettings` uses the global TypoScript configuration like
-:ts:`config.sys_language_overlay` and :php:`$GLOBALS['TSFE']->sys_language_content`
-(calculated based on :ts:`config.sys_language_uid` and :ts:`config.sys_language_mode`).
-So you need to change :php:`Typo3QuerySettings` manually only if your Extbase code should
-behave different than other `tt_content` rendering.
-
-Setting :php:`setLanguageOverlayMode()` on a query influences **only** fetching of the aggregate root. Relations are always
-fetched with :php:`setLanguageOverlayMode(true)`.
-
-When querying data in translated language, and having :php:`setLanguageOverlayMode(true)`, the relations
-(child objects) are overlaid even if aggregate root is not translated.
-See :php:`QueryLocalizedDataTest->queryFirst5Posts()`.
-
-Following examples show how to query data in Extbase in different scenarios, independent of the global TS settings:
-
-1) Fetch records from the language uid=1 only, with no overlays.
-   Previously (:ts:`consistentTranslationOverlayHandling = 0`):
-
-   It was not possible.
-
-
-   Now (:ts:`consistentTranslationOverlayHandling = 1`):
-
-   ::
-
-      $querySettings = $query->getQuerySettings();
-      $querySettings->setLanguageUid(1);
-      $querySettings->setLanguageOverlayMode(false);
-
-2) Fetch records from the language uid=1, with overlay, but hide non-translated records
-   Previously (:ts:`consistentTranslationOverlayHandling = 0`):
-
-   ::
-
-      $querySettings = $query->getQuerySettings();
-      $querySettings->setLanguageUid(1);
-      $querySettings->setLanguageMode('strict');
-
-   Now (:ts:`consistentTranslationOverlayHandling = 1`):
-
-   ::
-
-      $querySettings = $query->getQuerySettings();
-      $querySettings->setLanguageUid(1);
-      $querySettings->setLanguageOverlayMode('hideNonTranslated');
-
-
-+------------------------+-------------------------------------------------------------------------------------------------+----------------------------------------------+------------------------------+
-| QuerySettings property | old behaviour                                                                                   | new behaviour                                | default value (TSFE|Extbase) |
-+------------------------+-------------------------------------------------------------------------------------------------+----------------------------------------------+------------------------------+
-| languageUid            |                                                                                                 | same                                         | 0                            |
-+------------------------+-------------------------------------------------------------------------------------------------+----------------------------------------------+------------------------------+
-| respectSysLanguage     |                                                                                                 | same                                         | `true`                       |
-+------------------------+-------------------------------------------------------------------------------------------------+----------------------------------------------+------------------------------+
-| languageOverlayMode    | not used                                                                                        | values: `true`, `false`, `hideNonTranslated` | 0|`true`                     |
-|                        |                                                                                                 |                                              |                              |
-+------------------------+-------------------------------------------------------------------------------------------------+----------------------------------------------+------------------------------+
-| languageMode           | documented values: `null`, `content_fallback`, `strict` or `ignore`.                            | not used                                     | `null`                       |
-|                        | Only `strict` was evaluated. Setting `LanguageMode` to `strict`                                 |                                              |                              |
-|                        | caused passing `hideNonTranslated` param to `getRecordOverlay` in :php:`Typo3DbBackend`         |                                              |                              |
-|                        | and changing the query to work similar to TypoScript `sys_language_overlay = hideNonTranslated` |                                              |                              |
-+------------------------+-------------------------------------------------------------------------------------------------+----------------------------------------------+------------------------------+
-
-
-Identifiers
------------
-
-Domain models have a main identifier `uid` and two additional properties `_localizedUid` and `_versionedUid`.
-Depending on whether the `languageOverlayMode` mode is enabled (`true` or `'hideNonTranslated'`) or disabled (`false`),
-the identifier contains different values.
-When `languageOverlayMode` is enabled then `uid` property contains `uid` value of the default language record,
-the `uid` of the translated record is kept in the `_localizedUid`.
-
-+----------------------------------------------------------+-------------------------+---------------------------+
-| Context                                                  | Record in language 0    | Translated record         |
-+==========================================================+=========================+===========================+
-| Database                                                 | uid:2                   | uid:11, l10n_parent:2     |
-+----------------------------------------------------------+-------------------------+---------------------------+
-| Domain Object values with `languageOverlayMode` enabled  | uid:2, _localizedUid:2  | uid:2, _localizedUid:11   |
-+----------------------------------------------------------+-------------------------+---------------------------+
-| Domain Object values with `languageOverlayMode` disabled | uid:2, _localizedUid:2  | uid:11, _localizedUid:11  |
-+----------------------------------------------------------+-------------------------+---------------------------+
-
-See tests in :file:`extbase/Tests/Functional/Persistence/QueryLocalizedDataTest.php`.
-
-The :php:`$repository->findByUid()` method takes current rendering language into account (e.g. L=1). It does not take
-`defaultQuerySetting` set on the repository into account.
-The result of this method also depends on whether `languageOverlayMode` is set or not.
-Values in brackets show previous behaviour (disabled flag) if different than current.
-
-The bottom line is that with the feature flag on, you can now use  :php:`findByUid()` using translated record uid to get
-translated content independently from language set in global context.
-
-+-------------------+----------------+----------------------+----------------------+----------------------+----------------------+
-|                   |                | L=0                                         | L=1                                         |
-+-------------------+----------------+----------------------+----------------------+----------------------+----------------------+
-| repository method | property       | Overlay              | No overlay           | Overlay              | No overlay           |
-+===================+================+======================+======================+======================+======================+
-| findByUid(2)      | title          | Post 2               | Post 2               | Post 2 (Post 2 - DK) | Post 2 (Post 2 - DK) |
-+-------------------+----------------+----------------------+----------------------+----------------------+----------------------+
-|                   | uid            | 2                    | 2                    | 2                    | 2                    |
-+-------------------+----------------+----------------------+----------------------+----------------------+----------------------+
-|                   | _localizedUid  | 2                    | 2                    | 2 (11)               | 2 (11)               |
-+-------------------+----------------+----------------------+----------------------+----------------------+----------------------+
-| findByUid(11)     | title          | Post 2 - DK (Post 2) | Post 2 - DK (Post 2) | Post 2 - DK          | Post 2 - DK          |
-+-------------------+----------------+----------------------+----------------------+----------------------+----------------------+
-|                   | uid            | 2 (2)                | 11 (2)               | 2                    | 11 (2)               |
-+-------------------+----------------+----------------------+----------------------+----------------------+----------------------+
-|                   | _localizedUid  | 11 (2)               | 11 (2)               | 11                   | 11                   |
-+-------------------+----------------+----------------------+----------------------+----------------------+----------------------+
-
-.. note::
-
-   Note that :php:`$repository->findByUid()` behaves differently than a custom query by an `uid`
-   like :php:`$query->matching($query->equals('uid', 11));` The custom query will return `null` if passed `uid` doesn't match
-   language set in the :php:`$querySettings->setLanguageUid()` method.
-
-Filtering & sorting
--------------------
-
-When filtering by aggregate root property like `Post->title`,
-both filtering and sorting takes translated values into account and you will get correct results, also with pagination.
-
-When filtering or ordering by child object property, then Extbase does a left join between aggregate root
-table and child record table.
-Then the filter is applied as where clause. This means that filtering or ordering by child record property
-only takes values from child records which uids are stored in db (in most cases its default language record).
-See :php:`TranslationTest::fetchingTranslatedPostByBlogTitle()`
-
-This limitation also applies to Extbase with feature flag being disabled.
-
-Summary of the important code changes
-=====================================
-
-1) :php:`DataMapper` gets a :php:`Query` as a constructor parameter. This allows to use aggregate root :php:`QuerySettings` (language)
-   when fetching child records/relations. Later, in a separate patch we can pass other settings too e.g. :php:`setIgnoreEnableFields`
-   to fix issue around this setting. See :php:`DataMapper->getPreparedQuery` method.
-2) :php:`DataMapper` is passed to  :php:`LazyLoadingProxy` and  :php:`LazyObjectStorage`, so the settings don't get lost when fetching data lazily.
-3) :php:`Query` object gets a new property `parentQuery` which is useful to detect whether we're fetching aggregate root or child object.
-4) Extbase model for  :php:`FileReference` uses `_localizedUid` for fetching `OriginalResource`
-5) :php:`DataMapper` forces child records to be fetched using  :php:`setLanguageOverlayMode(true)`.
-6) When getRespectSysLanguage is set,  :php:`DataMapper` uses aggregate root language to overlay child records to correct language.
-7) The `where` clause used for finding translated records in overlay mode (`true`, `hideNonTranslated`) has been fixed.
-   It filters out the non translated records on db side in case `hideNonTranslated` is set.
-   It allows for filtering and sorting by translated values. See :php:`Typo3DbQueryParser->getLanguageStatement()`
-
-
-Most important known issues (ones this patch doesn't solve)
-===========================================================
-
-- Persistence session uses the same key for default language record and the translation - https://forge.typo3.org/issues/59992
-- Extbase allows to fetch deleted/hidden records - https://forge.typo3.org/issues/86307
-
-
-For more information about rendering please refer to the TypoScript reference_.
-
-.. _reference: https://docs.typo3.org/typo3cms/TyposcriptReference/Setup/Config/Index.html?highlight=sys_language_mode#sys-language-overlay
-
-.. index:: Database, TCA, TypoScript, ext:extbase
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Important-85560-LocationOfXLFLabelsDownloaded.rst b/typo3/sysext/core/Documentation/Changelog/master/Important-85560-LocationOfXLFLabelsDownloaded.rst
deleted file mode 100644 (file)
index 775b76c..0000000
+++ /dev/null
@@ -1,18 +0,0 @@
-.. include:: ../../Includes.txt
-
-=====================================================
-Important: #85560 - Location of XLF labels downloaded
-=====================================================
-
-See :issue:`85560`
-
-Description
-===========
-
-Downloaded files for XLF language files are usually stored within `typo3conf/l10n`, however, if the environment
-variable `TYPO3_PATH_ROOT` is set, which is common for all composer-based installations, the XLF language files
-are now found outside the document root, available under `var/labels/`.
-
-The Environment API :php:`Environment::getLabelsPath()` resolves the correct full location path prefix.
-
-.. index:: PHP-API
\ No newline at end of file
index ae00ae2..bb4e9b1 100644 (file)
@@ -132,12 +132,12 @@ return [
     ],
     'TYPO3\CMS\Core\Page\PageRenderer::JQUERY_VERSION_LATEST' => [
         'restFiles' => [
-            'Deprecation-86438-DeprecatePageRenderer-loadJQuery.rst',
+            'Deprecation-86438-PageRenderer-loadJQuery.rst',
         ],
     ],
     'TYPO3\CMS\Core\Page\PageRenderer::JQUERY_NAMESPACE_NONE' => [
         'restFiles' => [
-            'Deprecation-86438-DeprecatePageRenderer-loadJQuery.rst',
+            'Deprecation-86438-PageRenderer-loadJQuery.rst',
         ],
     ],
 ];
index 9f4dc35..6fe244d 100644 (file)
@@ -3765,7 +3765,7 @@ return [
         'numberOfMandatoryArguments' => 0,
         'maximumNumberOfArguments' => 3,
         'restFiles' => [
-            'Deprecation-86438-DeprecatePageRenderer-loadJQuery.rst'
+            'Deprecation-86438-PageRenderer-loadJQuery.rst'
         ],
     ],
     'TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->fetchUserRecord' => [