[TASK] Move documentation files into 9.4 folder - part 2 31/58131/5
authorAnja <aleichsenring@ab-softlab.de>
Sun, 2 Sep 2018 18:29:24 +0000 (20:29 +0200)
committerChristian Kuhn <lolli@schwarzbu.ch>
Mon, 3 Sep 2018 09:05:20 +0000 (11:05 +0200)
The change also contains some documentation related improvements
in some code files, where the need occured.

Change-Id: I2f587b405fea331c2e73342c879a4a20a5133351
Resolves: #86075
Releases: master
Reviewed-on: https://review.typo3.org/58131
Tested-by: TYPO3com <no-reply@typo3.com>
Reviewed-by: Björn Jacob <bjoern.jacob@tritum.de>
Tested-by: Björn Jacob <bjoern.jacob@tritum.de>
Reviewed-by: Christian Kuhn <lolli@schwarzbu.ch>
Tested-by: Christian Kuhn <lolli@schwarzbu.ch>
114 files changed:
typo3/sysext/core/Classes/Context/DateTimeAspect.php
typo3/sysext/core/Classes/Context/LanguageAspect.php
typo3/sysext/core/Classes/Context/WorkspaceAspect.php
typo3/sysext/core/Documentation/Changelog-9.rst
typo3/sysext/core/Documentation/Changelog/9.4/Deprecation-85678-ConfigTitleTagFunction.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Deprecation-85678-TsfeAltPageTitle.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Deprecation-85793-SeveralConstantsFromSystemEnvironmentBuilder.rst
typo3/sysext/core/Documentation/Changelog/9.4/Deprecation-85796-SaltedPasswordsCleanups.rst
typo3/sysext/core/Documentation/Changelog/9.4/Deprecation-85802-MoveFlexFormServiceFromEXTextbaseToEXTcore.rst
typo3/sysext/core/Documentation/Changelog/9.4/Deprecation-85822-PageGenerator.rst
typo3/sysext/core/Documentation/Changelog/9.4/Deprecation-85878-EidUtilityAndVariousTSFEMethods.rst
typo3/sysext/core/Documentation/Changelog/9.4/Deprecation-85892-VariousMethodsRegardingSysDomainResolving.rst
typo3/sysext/core/Documentation/Changelog/9.4/Deprecation-85902-IMGMENUGMENU.rst
typo3/sysext/core/Documentation/Changelog/9.4/Deprecation-85960-CompareUidentDeprecated.rst
typo3/sysext/core/Documentation/Changelog/9.4/Deprecation-85971-DeprecatePageRepository-getFirstWebPage.rst
typo3/sysext/core/Documentation/Changelog/9.4/Deprecation-85996-ExtensionManagerCommandController.rst
typo3/sysext/core/Documentation/Changelog/9.4/Deprecation-86001-WorkspacesTasksMigratedToSymfonyCommands.rst
typo3/sysext/core/Documentation/Changelog/9.4/Deprecation-86046-AdditionalArgumentsInSeveralTypoScriptFrontendControllerMethods.rst
typo3/sysext/core/Documentation/Changelog/9.4/Feature-13265-MakeFirstOptionToolbarOpenByDefaultInThePageTree.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-44297-IntervalPresetsForCronCommandOfSchedulerTask.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-57331-SupportMdashInCurrencyViewHelper.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-83476-LoadMergedJSFilesAsynchronous.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-83749-FilteringAndPaginationInTheRedirectsModule.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-84133-IntroduceVariants.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-84584-Re-DesignTheAdminPanel.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-84606-AddLogModuleToAdminPanel.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-84609-AddSQLLogModuleToAdminPanel.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-84704-OpenSpecificFieldWhenFixingLinksInLinkvalidator.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-84729-NewTCATypeSlug.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-85080-AddPropertyDisableFormElementsAndFinishers.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-85146-ReadEnvironmentVariablesInTypoScript.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-85164-AvailableLanguagesRespectsSiteConfigurationSettings.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-85164-EnableLanguagesPerSite.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-85236-InfixOptionToDefaultLogFileNamesForFileWriter.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-85247-TraitToDetectPublicDeprecatedMethods.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-85256-InstallTYPO3OnSQLite.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-85313-AddNotesFieldToPagesTable.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-85355-SupportBasicHTML5FieldsInFormEngine.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-85389-ContextAPIForConsistentDataHandling.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-85410-AllowTCADescriptionProperty.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-85550-IntroduceContextForTypoScriptDataGetTextProperty.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-85590-AddHooksForDatabaseRecordListCSVActions.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-85678-AddAPIForTitleTags.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-85691-ShowPagePathForReferencesInRecordInfo.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-85698-NewTypeinputEvalSaltedPassword.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-85719-AllowSitesWithoutSchemeOrDomain.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-85828-MoveSymfonyExpressionLanguageHandlingIntoEXTcore.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-85829-ImplementSymfonyExpressionLanguageForTypoScriptConditions.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-85894-FeatureTogglesInAdminToolsSettings.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-85900-PseudoSiteHandling.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-85928-UpgradeWizardToMigratePagesToSpeakingURLs.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-85947-PageBasedURLHandling.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-85991-ExcludeSymfonyCommandsFromScheduler.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-86001-RegularWorkspaceCleanupTasksAvailableViaCLICommands.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-86003-AdminpanelCompositionApi.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-86051-ShowExtensionsViaCLI.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Feature-86066-CLICommandsForListingAndShowingSites.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Important-84280-UnitTestSuppressNoticesRemoved.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Important-84623-ConfigurationFilesMovedFromTypo3confToConfigDirectory.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Important-85196-RemovedSimulateUserFromUserSettings.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Important-85393-ExtensionManagerOnlyImportsExtensionsCompatibleWithTYPO3V7LTSOrHigher.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Important-85683-DroppedSaltedpasswordOptions.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Important-85719-PHPPackagesSymfonyComponentsRequirementsRaisedToSymfony41.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Important-85833-SaltedpasswordsExtensionMergedIntoCoreExtension.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/9.4/Index.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/master/Deprecation-85678-ConfigTitleTagFunction.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Deprecation-85678-TsfeAltPageTitle.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-13265-MakeFirstOptionToolbarOpenByDefaultInThePageTree.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-44297-IntervalPresetsForCronCommandOfSchedulerTask.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-57331-SupportMdashInCurrencyViewHelper.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-83476-LoadMergedJSFilesAsynchronous.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-83749-FilteringAndPaginationInTheRedirectsModule.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-84133-IntroduceVariants.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-84584-Re-DesignTheAdminPanel.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-84606-AddLogModuleToAdminPanel.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-84609-AddSQLLogModuleToAdminPanel.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-84704-OpenSpecificFieldWhenFixingLinksInLinkvalidator.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-84729-NewTCATypeSlug.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-85080-AddPropertyDisableFormElementsAndFinishers.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-85146-ReadEnvironmentVariablesInTypoScript.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-85164-AllowToOnlyShowSiteLanguagesInBE.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-85164-EnableLanguagesPerSite.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-85236-AddedInfixOptionToDefaultLogFileNamesForFileWriter.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-85247-TraitToDetectPublicDeprecatedMethods.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-85256-InstallTYPO3OnSQLite.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-85313-AddNotesFieldToPagesTable.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-85355-SupportBasicHTML5FieldsInFormEngine.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-85389-ContextAPIForConsistentDataHandling.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-85410-AllowTCADescriptionProperty.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-85550-IntroduceContextForTypoScriptDataGetTextProperty.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-85590-AddHooksForDatabaseRecordListCSVActions.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-85678-AddAPIForTitleTags.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-85691-ShowPagePathForReferencesInRecordInfo.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-85698-NewTypeinputEvalSaltedPassword.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-85719-AllowSitesWithoutSchemeOrDomain.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-85828-MoveSymfonyExpressionLanguageHandlingIntoEXTcore.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-85829-ImplementSymfonyExpressionLanguageForTypoScriptConditions.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-85894-FeatureTogglesInAdminToolsSettings.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-85900-PseudoSiteHandling.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-85928-UpgradeWizardToMigratePagesToSpeakingURLs.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-85947-PageBasedURLHandling.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-85991-ExcludeSymfonyCommandsFromScheduler.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-86001-RegularWorkspaceCleanupTasksAvailableViaCLICommands.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-86003-AdminpanelCompositionApi.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-86051-ShowExtensionsViaCLI.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-86066-CLICommandsForListingAndShowingSites.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Important-84280-UnitTestSuppressNoticesRemoved.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Important-84623-ConfigurationFilesMovedFromTypo3confToConfigDirectory.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Important-85196-RemovedSimulateUserFromUserSettings.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Important-85393-ExtensionManagerOnlyImportsExtensionsCompatibleWithTYPO3V7LTSOrHigher.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Important-85683-DroppedSaltedpasswordOptions.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Important-85719-PHPPackagesSymfonyComponentsRequirementsRaisedToSymfony41.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Important-85833-SaltedpasswordsExtensionMergedIntoCoreExtension.rst [deleted file]
typo3/sysext/fluid/Classes/ViewHelpers/Format/CurrencyViewHelper.php

index 684c103..8ba2e67 100644 (file)
@@ -26,8 +26,8 @@ use TYPO3\CMS\Core\Context\Exception\AspectPropertyNotFoundException;
  * Allowed properties:
  * - timestamp - unix timestamp number
  * - timezone - America/Los_Angeles
- * - iso - ISO 8601
- * - full - the DateTime object
+ * - iso - datetime as string in ISO 8601 format, e.g. `2004-02-12T15:19:21+00:00`
+ * - full - the DateTimeImmutable object
  */
 class DateTimeAspect implements AspectInterface
 {
index 19f67c4..f45b7e8 100644 (file)
@@ -42,7 +42,7 @@ use TYPO3\CMS\Core\Context\Exception\AspectPropertyNotFoundException;
  *   - "fallback" if current page is not available, check the fallbackChain"
  *   - "fallbackAndIgnore"
  *
- * "overlays"
+ * "overlayType"
  * - defines which way the records should be fetched from ($TSFE->sys_language_contentOL and config.sys_language_overlay)
  * - usually you fetch language 0 and -1, then take the "contentId" and "overlay" them
  *    - here you have two choices
index 9325444..4e542b7 100644 (file)
@@ -18,7 +18,7 @@ namespace TYPO3\CMS\Core\Context;
 use TYPO3\CMS\Core\Context\Exception\AspectPropertyNotFoundException;
 
 /**
- * The aspect contains the workspace ID.
+ * The aspect contains information about the currently accessed workspace.
  *
  * Allowed properties:
  * - id
index cb6d72d..6d21f41 100644 (file)
@@ -11,6 +11,7 @@ Every change to the TYPO3 Core which might affect your site is documented here.
 .. toctree::
    :titlesonly:
 
+   Changelog/9.4/Index
    Changelog/9.3/Index
    Changelog/9.2/Index
    Changelog/9.1/Index
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Deprecation-85678-ConfigTitleTagFunction.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Deprecation-85678-ConfigTitleTagFunction.rst
new file mode 100644 (file)
index 0000000..1eef2b5
--- /dev/null
@@ -0,0 +1,32 @@
+.. include:: ../../Includes.txt
+
+=============================================
+Deprecation: #85678 - config.titleTagFunction
+=============================================
+
+See :issue:`85678`
+
+Description
+===========
+
+The TypoScript option :ts:`config.titleTagFunction` has been marked as deprecated and will be removed with TYPO3 v10.
+
+
+Impact
+======
+
+Installations using the option will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Instances using the option.
+
+
+Migration
+=========
+
+Please use the new TitleTag API to alter the title tag.
+
+.. index:: TypoScript, NotScanned
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Deprecation-85678-TsfeAltPageTitle.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Deprecation-85678-TsfeAltPageTitle.rst
new file mode 100644 (file)
index 0000000..db1fab2
--- /dev/null
@@ -0,0 +1,32 @@
+.. include:: ../../Includes.txt
+
+====================================================
+Deprecation: #85678 - $GLOBALS['TSFE']->altPageTitle
+====================================================
+
+See :issue:`85678`
+
+Description
+===========
+
+The PHP property :php:`$GLOBALS['TSFE']->altPageTitle` has been marked as deprecated and will be removed with TYPO3 v10.
+
+
+Impact
+======
+
+Installations using this property will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Instances using the property.
+
+
+Migration
+=========
+
+Please use the new TitleTag API to alter the title tag.
+
+.. index:: TypoScript, NotScanned
index a2beabd..f42f52e 100644 (file)
@@ -11,14 +11,11 @@ Description
 
 The following constants have been deprecated and should not be used any longer:
 
-* :php:`NUL`
-  Use :php:`"\0"` instead
+* :php:`NUL` (Use :php:`"\0"` instead)
 
-* :php:`TAB`
-  Use :php:`"\t"` instead
+* :php:`TAB` (Use :php:`"\t"` instead)
 
-* :php:`SUB`
-  Use :php:`chr(26)` instead
+* :php:`SUB` (Use :php:`chr(26)` instead)
 
 * :php:`TYPO3_URL_MAILINGLISTS`
 
index 7bdd638..260d74e 100644 (file)
@@ -11,17 +11,21 @@ Description
 
 These methods have been marked as deprecated:
 
-* :php:`TYPO3\CMS\Saltedpasswords\Salt\SaltFactory::getSaltingInstance()` - Use :php:`SaltFactory->get()` to
-  retrieve a hash instance of for a given password hash. Use :php:`SaltFactory->getDefaultHashInstance()`
-  to retrieve an instance of the configured default hash algorithm for a given context. See the method comments
-  for usage details.
-* :php:`TYPO3\CMS\Saltedpasswords\Salt\SaltFactory::determineSaltingHashingMethod()` - Use
-  :php:`SaltFactory->getDefaultHashInstance()` instead.
-* :php:`TYPO3\CMS\Saltedpasswords\Salt\SaltFactory::setPreferredHashingMethod()` - This method was only used
-  for unit testing and has been marked as deprecated without substitution since object instances of :php:`SaltFactory` can
-  now be properly mocked. Use :php:`Prophecy` to do that in unit tests that have :php:`SaltFactory` as dependency.
-* :php:`TYPO3\CMS\Saltedpasswords\Utility\SaltedPasswordsUtility->getNumberOfBackendUsersWithInsecurePassword()` -
-  This internal method is unused and there is no new implementation to substitute it.
+:php:`TYPO3\CMS\Saltedpasswords\Salt\SaltFactory::getSaltingInstance()`
+   Use :php:`SaltFactory->get()` to retrieve a hash instance of for a given password hash.
+   Use :php:`SaltFactory->getDefaultHashInstance()` to retrieve an instance of the configured default hash algorithm
+   for a given context. See the method comments for usage details.
+
+:php:`TYPO3\CMS\Saltedpasswords\Salt\SaltFactory::determineSaltingHashingMethod()`
+   Use :php:`SaltFactory->getDefaultHashInstance()` instead.
+
+:php:`TYPO3\CMS\Saltedpasswords\Salt\SaltFactory::setPreferredHashingMethod()`
+   This method was only used for unit testing and has been marked as deprecated without substitution since
+   object instances of :php:`SaltFactory` can  now be properly mocked.
+   Use :php:`Prophecy` to do that in unit tests that have :php:`SaltFactory` as dependency.
+
+:php:`TYPO3\CMS\Saltedpasswords\Utility\SaltedPasswordsUtility->getNumberOfBackendUsersWithInsecurePassword()`
+   This internal method is unused and there is no new implementation to substitute it.
 
 
 Impact
index bc178e3..c385130 100644 (file)
@@ -29,6 +29,6 @@ Any TYPO3 installation where this PHP class is in use within a TYPO3 extension.
 Migration
 =========
 
-Use the new namespace to reference the :php:`TYPO3\CMS\Core\Service\FlexFormService`
+Use the new namespace to reference the :php:`TYPO3\CMS\Core\Service\FlexFormService`.
 
 .. index:: PHP-API, FullyScanned, ext:extbase
index 89e45a7..db40d9f 100644 (file)
@@ -33,7 +33,8 @@ Migration
 Move the render logic to your own extension or use the RequestHandler to compile the functionality.
 
 The unrelated method :php:`PageRenderer::inline2TempFile()` has been moved into proper methods found at
-- :php:`GeneralUtility::writeJavaScriptContentToTemporaryFile($content)`
-- :php:`GeneralUtility::writeStyleSheetContentToTemporaryFile($content)`
+
+* :php:`GeneralUtility::writeJavaScriptContentToTemporaryFile($content)`
+* :php:`GeneralUtility::writeStyleSheetContentToTemporaryFile($content)`
 
 .. index:: Frontend, FullyScanned, ext:frontend
index b8df877..c8d197f 100644 (file)
@@ -12,6 +12,7 @@ Description
 The Utility class :php:`TYPO3\CMS\Frontend\Utility\EidUtility` has been marked as deprecated.
 
 The following methods have been marked as deprecated:
+
 * :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->initFEuser()`
 * :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->storeSessionData()`
 * :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->previewInfo()`
@@ -20,7 +21,8 @@ The following methods have been marked as deprecated:
 * :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->sendCacheHeaders()`
 
 The following hook has been marked as deprecated:
-`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['hook_previewInfo']`
+
+* `$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['hook_previewInfo']`
 
 
 Impact
@@ -41,7 +43,7 @@ Migration
 As all functionality has been set up via PSR-15 middlewares, use a PSR-15 middleware instead.
 
 The methods :php:`addTempContentHttpHeaders()` and :php:`sendCacheHeaders()` are now incorporated
-within :php:`TSFE->processOutput()`, this function should be used, or rather add custom headers
+within :php:`TSFE->processOutput()`. This function should be used, or rather add custom headers
 to a PSR-15 Response object if available.
 
 On top, the hook is superseded by the Frontend Hook `hook_eofe` which is executed in the Frontend rendering
index 94658b2..c7da3d7 100644 (file)
@@ -16,6 +16,7 @@ Instead, generating URLs should be done via the new PageUriBuilder and Routing A
 site handling and the specific sys_domain record.
 
 The following methods have been marked as deprecated:
+
 * :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->domainNameMatchesCurrentRequest()`
 * :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->getDomainDataForPid()`
 * :php:`TYPO3\CMS\Backend\Utility\BackendUtility::getDomainStartPage()`
index afa269a..2d2d20c 100644 (file)
@@ -16,6 +16,7 @@ nowadays - images with a fixed width, and text within images has various drawbac
 responsive renderings.
 
 The following PHP classes have been marked as deprecated:
+
 * :php:`TYPO3\CMS\Frontend\ContentObject\Menu\GraphicalMenuContentObject`
 * :php:`TYPO3\CMS\Frontend\ContentObject\Menu\ImageMenuContentObject`
 
@@ -23,22 +24,25 @@ The related TypoScript menu objects `GMENU` and `GMENUITEM` as well as `IMGMENU`
 marked as deprecated.
 
 On top the following TypoScript options within a MENU item, regarding TMENU have been marked as deprecated:
+
 * imgNamePrefix
 * imgNameNotRandom
 
 The following TMENU item properties should not be used anymore.
-- RO_chBgColor
-- beforeImg
-- beforeImgTagParams
-- beforeImgLink
-- beforeROImg
-- RO
-- afterImg
-- afterImgTagParams
-- afterImgLink
-- afterROImg
+
+* RO_chBgColor
+* beforeImg
+* beforeImgTagParams
+* beforeImgLink
+* beforeROImg
+* RO
+* afterImg
+* afterImgTagParams
+* afterImgLink
+* afterROImg
 
 The following item states have been marked as deprecated ("RO" for "rollover" in graphics-related items).
+
 * IFSUBRO
 * ACTRO
 * ACTIFSUBRO
@@ -51,6 +55,7 @@ The following item states have been marked as deprecated ("RO" for "rollover" in
 The following previously public properties are now marked as internal and trigger a PHP :php:`E_USER_DEPRECATED` error,
 partly due to preparations of refactoring the PHP code once GMENU functionality is removed, and partly
 due to the highly connected functionality within the PHP classes:
+
 * :php:`TYPO3\CMS\Frontend\ContentObject\Menu\AbstractMenuContentObject->menuNumber`
 * :php:`TYPO3\CMS\Frontend\ContentObject\Menu\AbstractMenuContentObject->entryLevel`
 * :php:`TYPO3\CMS\Frontend\ContentObject\Menu\AbstractMenuContentObject->spacerIDList`
@@ -83,6 +88,7 @@ due to the highly connected functionality within the PHP classes:
 * :php:`TYPO3\CMS\Frontend\ContentObject\Menu\AbstractMenuContentObject->nameAttribute`
 
 The following methods have changed visibility:
+
 * :php:`TYPO3\CMS\Frontend\ContentObject\Menu\AbstractMenuContentObject->subMenu()`
 * :php:`TYPO3\CMS\Frontend\ContentObject\Menu\AbstractMenuContentObject->link()`
 * :php:`TYPO3\CMS\Frontend\ContentObject\Menu\AbstractMenuContentObject->procesItemStates()`
@@ -101,7 +107,6 @@ The following methods have changed visibility:
 * :php:`TYPO3\CMS\Frontend\ContentObject\Menu\AbstractMenuContentObject->getBannedUids()`
 * :php:`TYPO3\CMS\Frontend\ContentObject\Menu\AbstractMenuContentObject->menuTypoLink()`
 
-
 * :php:`TYPO3\CMS\Frontend\ContentObject\Menu\GraphicalMenuContentObject->extProc_RO()`
 * :php:`TYPO3\CMS\Frontend\ContentObject\Menu\GraphicalMenuContentObject->extProc_init()`
 * :php:`TYPO3\CMS\Frontend\ContentObject\Menu\GraphicalMenuContentObject->extProc_beforeLinking()`
@@ -109,7 +114,6 @@ The following methods have changed visibility:
 * :php:`TYPO3\CMS\Frontend\ContentObject\Menu\GraphicalMenuContentObject->extProc_beforeAllWrap()`
 * :php:`TYPO3\CMS\Frontend\ContentObject\Menu\GraphicalMenuContentObject->extProc_finish()`
 
-
 * :php:`TYPO3\CMS\Frontend\ContentObject\Menu\TextMenuContentObject->getBeforeAfter()`
 * :php:`TYPO3\CMS\Frontend\ContentObject\Menu\TextMenuContentObject->extProc_init()`
 * :php:`TYPO3\CMS\Frontend\ContentObject\Menu\TextMenuContentObject->extProc_beforeLinking()`
@@ -118,6 +122,7 @@ The following methods have changed visibility:
 * :php:`TYPO3\CMS\Frontend\ContentObject\Menu\TextMenuContentObject->extProc_finish()`
 
 The following functionality has been marked as deprecated as well:
+
 * :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->setJS('mouseOver')`
 
 
index 0c9b9c8..b1c13d5 100644 (file)
@@ -12,8 +12,8 @@ Description
 Two methods related to old plain text or simple md5 related password checking have
 been marked as deprecated after those have been unused or overriden for a while already:
 
-* php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->compareUident()`
-* php:`TYPO3\CMS\Core\Authentication\AbstractAuthenticationService->compareUident()`
+* :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->compareUident()`
+* :php:`TYPO3\CMS\Core\Authentication\AbstractAuthenticationService->compareUident()`
 
 
 Impact
index 6d298da..bee0a43 100644 (file)
@@ -10,8 +10,10 @@ Description
 ===========
 
 The method php:`PageRepository->getFirstWebPage()` is only used when no "?id" parameter is given, and no rootpage was resolved.
-As this is the only use-case, a more generic "getMenu" method can be used, which does the same except for not "limiting" the query to one result, so there is a minimal memory penalty when doing so, however due to Pseudo-Site functionality
-this drawback only applies to rare cases.
+
+As this is the only use-case, a more generic "getMenu" method can be used, which does the
+same except for not "limiting" the query to one result, so there is a minimal memory penalty when doing so.
+However due to Pseudo-Site functionality this drawback only applies to rare cases.
 
 
 Impact
index 4f20dc9..87e49e1 100644 (file)
@@ -12,9 +12,9 @@ Description
 The following Extension Manager CLI commands have been reimplemented internally with Symfony console
 commands:
 
-* :bash:`extensionmanager:extension:install`, now :bash:`extension:activate`
-* :bash:`extensionmanager:extension:uninstall`, now :bash:`extension:deactivate`
-* :bash:`extensionmanager:extension:dumpclassloadinginformation`, now :bash:`dumpautoload`
+* :shell:`extensionmanager:extension:install`, now :shell:`extension:activate`
+* :shell:`extensionmanager:extension:uninstall`, now :shell:`extension:deactivate`
+* :shell:`extensionmanager:extension:dumpclassloadinginformation`, now :shell:`dumpautoload`
 
 The left-over command controller PHP class :php:`TYPO3\CMS\Extensionmanager\Command\ExtensionCommandController`
 is not in use anymore, and therefore has been marked as deprecated.
@@ -36,9 +36,9 @@ Installations simply using the CLI entrypoint are not affected.
 Migration
 =========
 
-* use :bash:`extension:activate` instead of :bash:`extensionmanager:extension:install`
-* use :bash:`extension:deactivate` instead of :bash:`extensionmanager:extension:uninstall`
-* use :bash:`dumpautoload` instead of :bash:`extensionmanager:extension:dumpclassloadinginformation`
+* use :shell:`extension:activate` instead of :shell:`extensionmanager:extension:install`
+* use :shell:`extension:deactivate` instead of :shell:`extensionmanager:extension:uninstall`
+* use :shell:`dumpautoload` instead of :shell:`extensionmanager:extension:dumpclassloadinginformation`
 
 In order to achieve the same functionality within custom PHP code, it is recommended to use the
 underlying logic within the commands instead of calling or extending the command controller class.
index 73e7975..06c9878 100644 (file)
@@ -17,6 +17,7 @@ The following tasks should not be used anymore:
 * Workspaces cleanup preview links
 
 The following related classes have been marked as deprecated:
+
 * :php:`TYPO3\CMS\Workspaces\Service\AutoPublishService`
 * :php:`TYPO3\CMS\Workspaces\Task\AutoPublishTask`
 * :php:`TYPO3\CMS\Workspaces\Task\CleanupPreviewLinkTask`
index 5e2bae4..cf147d0 100644 (file)
@@ -10,9 +10,10 @@ Description
 ===========
 
 The following public methods within :php:`TypoScriptFrontendController` now expect an argument:
-- :php:`makeCacheHash(ServerRequestInterface $request)`
-- :php:`calculateLinkVars(array $queryParams)`
-- :php:`preparePageContentGeneration(ServerRequestInterface $request)`
+
+* :php:`makeCacheHash(ServerRequestInterface $request)`
+* :php:`calculateLinkVars(array $queryParams)`
+* :php:`preparePageContentGeneration(ServerRequestInterface $request)`
 
 This is necessary to avoid usage of the PHP global variables $_GET/$_POST.
 
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-13265-MakeFirstOptionToolbarOpenByDefaultInThePageTree.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-13265-MakeFirstOptionToolbarOpenByDefaultInThePageTree.rst
new file mode 100644 (file)
index 0000000..9083d57
--- /dev/null
@@ -0,0 +1,21 @@
+.. include:: ../../Includes.txt
+
+============================================================================
+Feature: #13265 - Select first element of PageTree toolbar on initialization
+============================================================================
+
+See :issue:`13265`
+
+Description
+===========
+
+The first element of the PageTree toolbar is now selected when initialized. The possibility to
+close/hide a toolbar option has been removed. Either the page type or the filter/search is displayed.
+
+
+Impact
+======
+
+The user always sees an open element of the PageTree toolbar.
+
+.. index:: Backend, JavaScript, ext:backend
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-44297-IntervalPresetsForCronCommandOfSchedulerTask.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-44297-IntervalPresetsForCronCommandOfSchedulerTask.rst
new file mode 100644 (file)
index 0000000..904a914
--- /dev/null
@@ -0,0 +1,25 @@
+.. include:: ../../Includes.txt
+
+=====================================================================
+Feature: #44297 - Interval presets for cron command of scheduler task
+=====================================================================
+
+See :issue:`44297`
+
+Description
+===========
+
+To support administrators creating scheduler tasks, presets have been added to the frequency field.
+
+The default presets are:
+
+.. code-block:: php
+
+   $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['scheduler']['frequencyOptions'] = [
+      '0 9,15 * * 1-5' => 'LLL:EXT:scheduler/Resources/Private/Language/locallang.xlf:command.example1',
+      '0 */2 * * *' =>  'LLL:EXT:scheduler/Resources/Private/Language/locallang.xlf:command.example2',
+      '*/20 * * * *' =>  'LLL:EXT:scheduler/Resources/Private/Language/locallang.xlf:command.example3',
+      '0 7 * * 2' =>  'LLL:EXT:scheduler/Resources/Private/Language/locallang.xlf:command.example4',
+];
+
+.. index:: Backend, ext:scheduler
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-57331-SupportMdashInCurrencyViewHelper.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-57331-SupportMdashInCurrencyViewHelper.rst
new file mode 100644 (file)
index 0000000..547f397
--- /dev/null
@@ -0,0 +1,27 @@
+.. include:: ../../Includes.txt
+
+=====================================================
+Feature: #57331 - Support dash in CurrencyViewHelper
+=====================================================
+
+See :issue:`57331`
+
+Description
+===========
+
+The :php:`useDash` option has been added to the CurrencyViewHelper.
+
+
+Impact
+======
+
+If the option :php:`useDash` is set and a value without decimals (see example) is given, the decimal place is rendered as a dash.
+
+Example:
+
+.. code-block:: html
+
+       <!-- Renders "54321.-" -->
+       <f:format.currency useDash="true">54321.00</f:format.currency>
+
+.. index:: Fluid, ext:fluid
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-83476-LoadMergedJSFilesAsynchronous.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-83476-LoadMergedJSFilesAsynchronous.rst
new file mode 100644 (file)
index 0000000..da24a12
--- /dev/null
@@ -0,0 +1,30 @@
+.. include:: ../../Includes.txt
+
+===================================================
+Feature: #83476 - Load merged JS files asynchronous
+===================================================
+
+See :issue:`83476`
+
+Description
+===========
+
+The async attribute is now assigned to the script tag of the concatenated JS files if all files have the async attribute enabled in TypoScript.
+
+Example:
+--------
+
+.. code-block:: typoscript
+
+   config.concatenateJs = 1
+
+   page = PAGE
+   page.includeJSFooter {
+       test = fileadmin/user_upload/test.js
+       test.async = 1
+
+       test2 = fileadmin/user_upload/test2.js
+       test2.async = 1
+   }
+
+.. index:: Frontend, TypoScript, ext:core
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-83749-FilteringAndPaginationInTheRedirectsModule.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-83749-FilteringAndPaginationInTheRedirectsModule.rst
new file mode 100644 (file)
index 0000000..ff2118a
--- /dev/null
@@ -0,0 +1,37 @@
+.. include:: ../../Includes.txt
+
+==================================================================
+Feature: #83749 - Filtering and Pagination in the redirects module
+==================================================================
+
+See :issue:`83749`
+
+Description
+===========
+
+The backend module "Redirects" received filtering and pagination to improve the overall usability.
+
+The list of redirects can be filtered by:
+
+- The source host
+- The source path
+- The destination (either the path or the Page ID)
+- The target status code
+
+All filters are concatenated by a logical AND.
+
+Pagination is set to 50 records per page.
+
+Some minor usability improvements have been made as well:
+
+- The source path crops after 100 characters to keep the table from expanding too much.
+- The destination column also shows the Page ID if the target is a page.
+- Redirects are sorted by source host (1st) and source path (2nd).
+
+
+Impact
+======
+
+With these improvements it is now possible to easily manage a big amount of redirect records.
+
+.. index:: Backend, ext:redirects
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-84133-IntroduceVariants.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-84133-IntroduceVariants.rst
new file mode 100644 (file)
index 0000000..79b5975
--- /dev/null
@@ -0,0 +1,490 @@
+.. include:: ../../Includes.txt
+
+====================================
+Feature: #84133 - Introduce variants
+====================================
+
+See :issue:`84133`
+
+Description
+===========
+
+
+Short Description
+-----------------
+
+Variants allow you to change properties of a form element and can be activated based on conditions.
+
+This makes it possible to manipulate form element properties, validator options, and finisher options based on conditions.
+
+This allows you among other things:
+
+* translate form element values depending on the frontend language
+* set and remove validators of one form element depending on the value of another form element
+* hide entire steps (form pages) depending on the value of a form element
+* set finisher options depending on the value of a form element
+* hiding a form element in certain finishers and on the summary step
+
+This feature implements variants for frontend rendering and the ability to define variants in form definitions.
+The implementation to define variants graphically in the form editor is out of scope of this patchset.
+
+
+Basics
+------
+
+Variants allow you to change properties of form elements, validators, and finishers and are activated by conditions.
+They are defined on the form element level either statically in form definitions or created programmatically through an API.
+
+The variants defined within a form definition are automatically applied to the form based on their conditions at runtime.
+Programmatically, variants can be applied at any time.
+
+Furthermore, the conditions of a variant can be evaluated programmatically at any time. However, some conditions are only
+available at runtime, for example a check for a form element value.
+
+Custom conditions and operators can be added easily.
+
+Only the form element properties listed in a variant are applied to the form element, all other properties are retained.
+An exception to this rule are finishers and validators. If finishers or validators are **not** defined within a variant, the
+original finishers and validators will be used. If at least one finisher or validator is defined in a variant, the
+originally defined finishers or validators are overwritten by the list of finishers and validators of the variant.
+
+Variants defined within a form definition are **all** processed and applied in the order of their condition matches. This means
+if variant 1 sets the label of a form element to "X" and variant 2 sets the label to "Y", then variant 2 is applied, i.e. the label
+will be "Y".
+
+
+Variants definition
+-------------------
+
+Variants are defined on the form element level. Check the following - incomplete - example:
+
+.. code-block:: yaml
+
+    type: Text
+    identifier: text-1
+    label: ''
+    variants:
+      -
+        identifier: variant-1
+        condition: 'formValues["checkbox-1"] == 1'
+        # If the condition matches, the label property of the form element is set to the value 'foo'
+        label: foo
+
+
+As usual :yaml:`identifier` must be a unique name of the variant on the form element level.
+
+Each variant has a single :yaml:`condition` which lets the variants' changes get applied if it matches.
+
+If the :yaml:`condition` of a variant matches, the remaining properties are applied to the form element. In the
+aforementioned example the label of the form element :yaml:`text-1` is changed to ``foo`` if the checkbox
+:yaml:`checkbox-1` is checked.
+
+The following properties can be overwritten by variants within the topmost element (:yaml:`Form`):
+
+* :yaml:`label`
+* :yaml:`renderingOptions`
+* :yaml:`finishers`
+* :yaml:`rendererClassName`
+
+The following properties can be overwritten by variants within all of the other form elements:
+
+* :yaml:`enabled`
+* :yaml:`label`
+* :yaml:`defaultValue`
+* :yaml:`properties`
+* :yaml:`renderingOptions`
+* :yaml:`validators`
+
+
+Conditions
+----------
+
+The form framework uses the Symfony component `expression language` to match the conditions. (@see https://symfony.com/doc/4.1/components/expression_language.html)
+An expression is a one-liner that returns a boolean value like :yaml:`applicationContext matches "#Production/Local#"`.
+Please read https://symfony.com/doc/4.1/components/expression_language/syntax.html to learn more about this topic.
+The form framework extends the expression language with some variables which can be used to access form values and environment settings.
+
+
+``formRuntime`` (object)
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+You can access every public method from the :php:`\TYPO3\CMS\Form\Domain\Runtime\FormRuntime` (@see https://docs.typo3.org/typo3cms/extensions/form/ApiReference/Index.html#typo3-cms-form-domain-model-formruntime).
+
+Example
+'''''''
+
+:yaml:`formRuntime.getIdentifier() == "test"`.
+
+
+``formValues`` (array)
+^^^^^^^^^^^^^^^^^^^^^^
+
+:yaml:`formValues` holds all of the submitted form element values. Each key within this array represents a form element identifier.
+
+Example
+'''''''
+
+:yaml:`formValues["text-1"] == "yes"`.
+
+
+``stepIdentifier`` (string)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+:yaml:`stepIdentifier` is set to the :yaml:`identifier` of the current step.
+
+Example
+'''''''
+
+:yaml:`stepIdentifier == "page-1"`.
+
+
+``stepType`` (string)
+^^^^^^^^^^^^^^^^^^^^^
+
+:yaml:`stepType` is set to the :yaml:`type` of the current step.
+
+Example
+'''''''
+
+:yaml:`stepType == "SummaryPage"`.
+
+
+``finisherIdentifier`` (string)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+:yaml:`finisherIdentifier` is set to the :yaml:`identifier` of the current finisher or an empty string (while no finishers are executed).
+
+Example
+'''''''
+
+:yaml:`finisherIdentifier == "EmailToSender"`.
+
+
+``siteLanguage`` (object)
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+You can access every public method from :php:`\TYPO3\CMS\Core\Site\Entity\SiteLanguage`.
+The most needed ones are probably:
+
+* getLanguageId() / Aka sys_language_uid.
+* getLocale() / The language locale. Something like 'en_US.UTF-8'.
+* getTypo3Language() / The language key for XLF files. Something like 'de' or 'default'.
+* getTwoLetterIsoCode() / Returns the ISO-639-1 language ISO code. Something like 'de'.
+
+Example
+'''''''
+
+:yaml:`siteLanguage.getLocale() == "de_DE"`.
+
+
+``applicationContext`` (string)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+:yaml:`applicationContext` is set to the application context (@see GeneralUtility::getApplicationContext()).
+
+Example
+'''''''
+
+:yaml:`applicationContext matches "#Production/Local#"`.
+
+
+``contentObject`` (array)
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+:yaml:`contentObject` is set to the data of the current content object or to an empty array if no content object is available.
+
+Example
+'''''''
+
+:yaml:`contentObject["pid"] in [23, 42]`.
+
+
+Working with variants programmatically
+--------------------------------------
+
+Create a variant with conditions through the PHP API:
+
+.. code-block:: php
+
+    /** @var TYPO3\CMS\Form\Domain\Model\Renderable\RenderableVariantInterface $variant */
+    $variant = $formElement->createVariant([
+        'identifier' => 'variant-1',
+        'condition' => 'formValues["checkbox-1"] == 1',
+        'label' => 'foo',
+    ]);
+
+Get all variants of a form element:
+
+.. code-block:: php
+
+    /** @var TYPO3\CMS\Form\Domain\Model\Renderable\RenderableVariantInterface[] $variants */
+    $variants = $formElement->getVariants();
+
+Apply a variant to a form element regardless of its defined conditions:
+
+.. code-block:: php
+
+    $formElement->applyVariant($variant);
+
+
+Examples
+--------
+
+Translate form element values depending on the frontend language:
+
+.. code-block:: yaml
+
+    type: Form
+    identifier: test
+    prototypeName: standard
+    label: DE
+    renderingOptions:
+      submitButtonLabel: Abschicken
+    variants:
+      -
+        identifier: language-variant-1
+        condition: 'siteLanguage.getLocale() == "en_US.UTF-8"'
+        label: EN
+        renderingOptions:
+          submitButtonLabel: Submit
+    renderables:
+      -
+        type: Page
+        identifier: page-1
+        label: DE
+        renderingOptions:
+          previousButtonLabel: 'zurück'
+          nextButtonLabel: 'weiter'
+        variants:
+          -
+            identifier: language-variant-1
+            condition: 'siteLanguage.getLocale() == "en_US.UTF-8"'
+            label: EN
+            renderingOptions:
+              previousButtonLabel: 'Previous step'
+              nextButtonLabel: 'Next step'
+        renderables:
+          -
+            type: Text
+            identifier: text-1
+            label: DE
+            properties:
+              fluidAdditionalAttributes:
+                placeholder: Platzhalter
+            variants:
+              -
+                identifier: language-variant-1
+                condition: 'siteLanguage.getLocale() == "en_US.UTF-8"'
+                label: EN
+                properties:
+                  fluidAdditionalAttributes:
+                    placeholder: Placeholder
+
+Set validators of one form element depending on the value of another form element:
+
+.. code-block:: yaml
+
+
+    type: Form
+    identifier: test
+    label: test
+    prototypeName: standard
+    renderables:
+      -
+        type: Page
+        identifier: page-1
+        label: Step
+        renderables:
+          -
+            defaultValue: ''
+            type: Text
+            identifier: text-1
+            label: 'Email address'
+            variants:
+              -
+                identifier: variant-1
+                condition: 'formValues["checkbox-1"] == 1'
+                properties:
+                  fluidAdditionalAttributes:
+                    required: 'required'
+                validators:
+                  -
+                    identifier: NotEmpty
+                  -
+                    identifier: EmailAddress
+          -
+            type: Checkbox
+            identifier: checkbox-1
+            label: 'Subscribe to newsletter'
+
+Hide entire steps depending on the value of a form element:
+
+.. code-block:: yaml
+
+    type: Form
+    identifier: test
+    prototypeName: standard
+    label: Test
+    renderables:
+      -
+        type: Page
+        identifier: page-1
+        label: 'Page 1'
+        renderables:
+          -
+            type: Text
+            identifier: text-1
+            label: 'Text 1'
+          -
+            type: Checkbox
+            identifier: checkbox-1
+            label: 'Skip page 2'
+            variants:
+              -
+                identifier: hide-1
+                condition: 'stepType == "SummaryPage"'
+                renderingOptions:
+                  enabled: false
+      -
+        type: Page
+        identifier: page-2
+        label: 'Page 2'
+        variants:
+          -
+            identifier: variant-1
+            condition: 'formValues["checkbox-1"] == 1'
+            renderingOptions:
+              enabled: false
+        renderables:
+          -
+            type: Text
+            identifier: text-2
+            label: 'Text 2'
+      -
+        type: SummaryPage
+        identifier: summarypage-1
+        label: 'Summary step'
+
+Set finisher values depending on the application context:
+
+.. code-block:: yaml
+
+    type: Form
+    identifier: test
+    prototypeName: standard
+    label: Test
+    renderingOptions:
+      submitButtonLabel: Submit
+    finishers:
+      -
+        identifier: Confirmation
+        options:
+          message: 'Thank you'
+    variants:
+      -
+        identifier: variant-1
+        condition: 'applicationContext matches "#Production/Local#"'
+        finishers:
+          -
+            identifier: Confirmation
+            options:
+              message: 'ouy knahT'
+    renderables:
+      -
+        type: Page
+        identifier: page-1
+        label: 'Page 1'
+        renderingOptions:
+          previousButtonLabel: 'Previous step'
+          nextButtonLabel: 'Next step'
+
+Hide a form element in certain finishers and on the summary step:
+
+.. code-block:: yaml
+
+    type: Form
+    identifier: test
+    prototypeName: standard
+    label: Test
+    finishers:
+      -
+        identifier: EmailToReceiver
+        options:
+          subject: Testmail
+          recipientAddress: tritum@example.org
+          recipientName: 'Test'
+          senderAddress: tritum@example.org
+          senderName: tritum@example.org
+    renderables:
+      -
+        type: Page
+        identifier: page-1
+        label: 'Page 1'
+        renderables:
+          -
+            type: Text
+            identifier: text-1
+            label: 'Text 1'
+            variants:
+              -
+                identifier: hide-1
+                renderingOptions:
+                  enabled: false
+                condition: 'stepType == "SummaryPage" || finisherIdentifier in ["EmailToSender", "EmailToReceiver"]'
+          -
+            type: Text
+            identifier: text-2
+            label: 'Text 2'
+      -
+        type: SummaryPage
+        identifier: summarypage-1
+        label: 'Summary step'
+
+
+Adding own expression language provider
+---------------------------------------
+
+If you need to extend the expression language with custom functions you can extend it. For more
+information @see https://symfony.com/doc/4.1/components/expression_language/extending.html#using-expression-providers.
+
+First of all, you have to register the expression language provider within the form setup:
+
+.. code-block:: yaml
+
+    TYPO3:
+      CMS:
+        Form:
+          prototypes:
+            standard:
+              conditionContextDefinition:
+                expressionLanguageProvider:
+                  MyCustomExpressionLanguageProvider:
+                    implementationClassName: '\Vendor\MyExtension\CustomExpressionLanguageProvider'
+
+Your expression language provider must implement :php`Symfony\Component\ExpressionLanguage\ExpressionFunctionProviderInterface`.
+
+
+Adding own expression language variables
+----------------------------------------
+
+If you need to add custom variables to the expression language you can extend it.
+Then the variables are ready to be checked in conditions.
+
+First of all, you have to register the variable provider within the form setup:
+
+.. code-block:: yaml
+
+    TYPO3:
+      CMS:
+        Form:
+          prototypes:
+            standard:
+              conditionContextDefinition:
+                expressionLanguageVariableProvider:
+                  MyCustomExpressionLanguageVariableProvider:
+                    implementationClassName: '\Vendor\MyExtension\CustomExpressionLanguageVariableProvider'
+
+Your expression language variable provider must implement :php`TYPO3\CMS\Form\Domain\Condition\ExpressionLanguageVariableProviderInterface`.
+
+
+.. index:: Frontend, ext:form
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-84584-Re-DesignTheAdminPanel.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-84584-Re-DesignTheAdminPanel.rst
new file mode 100644 (file)
index 0000000..0560398
--- /dev/null
@@ -0,0 +1,28 @@
+.. include:: ../../Includes.txt
+
+===========================================
+Feature: #84584 - Re-Design the admin panel
+===========================================
+
+See :issue:`84584`
+
+Description
+===========
+
+The admin panel got a complete overhaul regarding its design as well as the underlying code and extensibility.
+
+UI wise the following changes were done
+
+- Ajax is used to save configuration options, so only a single reload is triggered even if multiple settings changed.
+- Settings influencing page rendering are grouped together.
+- Most important info is available at a glance with possibilities to show extended information.
+
+
+Impact
+======
+
+The new admin panel provides a better look and feel as well as more convenient access to information and more flexible extensibility.
+For backwards compatibility enabling and disabling modules or options for editors is still possible via User TSConfig.
+
+
+.. index:: Frontend, PHP-API, ext:adminpanel
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-84606-AddLogModuleToAdminPanel.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-84606-AddLogModuleToAdminPanel.rst
new file mode 100644 (file)
index 0000000..1894ca2
--- /dev/null
@@ -0,0 +1,26 @@
+.. include:: ../../Includes.txt
+
+==============================================
+Feature: #84606 - Add Log Module to AdminPanel
+==============================================
+
+See :issue:`84606`
+
+Description
+===========
+
+A log module has been added to the adminPanel to display log entries generated during the current request.
+
+It displays all log entries generated via the logging framework during the request.
+
+Display options include grouping by log level and component, additionally the log level
+which shall be logged has been made configurable.
+
+
+Impact
+======
+
+A new AdminPanel sub module displaying log entries has been added in a new main module "Debug" which may
+be extended with further debug information.
+
+.. index:: Frontend, ext:adminpanel
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-84609-AddSQLLogModuleToAdminPanel.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-84609-AddSQLLogModuleToAdminPanel.rst
new file mode 100644 (file)
index 0000000..5f1b72f
--- /dev/null
@@ -0,0 +1,26 @@
+.. include:: ../../Includes.txt
+
+==================================================
+Feature: #84609 - Add SQL Log Module to AdminPanel
+==================================================
+
+See :issue:`84609`
+
+Description
+===========
+
+A new AdminPanel module has been introduced which shows SQL queries done to generate the current page.
+The module includes a short trace of the query so developers may locate where it was initiated as well as - in case
+it's a prepared statement - the placeholder values to enable checking variations of the query.
+
+Logging of queries is done via the Doctrine SQL Logger capabilities and enabled whenever the AdminPanel is activated /
+open in the frontend. Logging is only done for the currently logged in backend user, this way the overall performance
+impact is negligible.
+
+
+Impact
+======
+
+The AdminPanel has a new sub module "Query Information" in the "Debug" section.
+
+.. index:: Backend, Database, Frontend, ext:adminpanel
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-84704-OpenSpecificFieldWhenFixingLinksInLinkvalidator.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-84704-OpenSpecificFieldWhenFixingLinksInLinkvalidator.rst
new file mode 100644 (file)
index 0000000..74c954c
--- /dev/null
@@ -0,0 +1,24 @@
+.. include:: ../../Includes.txt
+
+========================================================================
+Feature: #84704 - Open specific field when fixing links in Linkvalidator
+========================================================================
+
+See :issue:`84704`
+
+Description
+===========
+
+When fixing links in Linkvalidator, a click on the edit icon
+for the respective broken link opens an edit form.
+
+The whole form opening provided too much information, where just the problematic field would have been enough.
+Now only the required field is open for editing, with an additional option to switch to the whole form if necessary.
+
+
+Impact
+======
+
+Only affects Linkvalidator. Editing broken links should be easier now.
+
+.. index:: Backend, ext:linkvalidator
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-84729-NewTCATypeSlug.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-84729-NewTCATypeSlug.rst
new file mode 100644 (file)
index 0000000..477937c
--- /dev/null
@@ -0,0 +1,65 @@
+.. include:: ../../Includes.txt
+
+=====================================
+Feature: #84729 - New TCA type "slug"
+=====================================
+
+See :issue:`84729`
+
+Description
+===========
+
+A new TCA field type called `slug` has been added to TYPO3 Core. Its main purpose is to define parts of a URL
+path to generate and resolve URLs.
+
+With a URL like `https://www.typo3.org/ch/community/values/core-values/` a URL slug is typically a part like
+`/community` or `/community/values/core-values`.
+
+Within TYPO3, a slug is always part of the URL "path" - it does not contain scheme, host, HTTP verb, etc.
+
+A slug is usually added to a TCA-based database table, containing some rules for evaluation and definition.
+
+In contrast to concepts within RealURL of "URL segments", a slug is a segment of a URL, but it is not limited
+to be separated by slashes. Therefore, a slug can contain slashes.
+
+In the future, it could be possible to generate slugs for any TCA table, but its's main usage will be for the "pages"
+TCA structure.
+
+If a TCA table contains a field called "slug", it needs to be filled for every existing record. It can
+be shown and edited via regular Backend Forms, and is also evaluated during persistence via DataHandler.
+
+The default behaviour of a slug is as follows:
+* A slug only contains characters which are allowed within URLs. Spaces, commas and other special characters are
+  converted to a fallback character.
+* A slug is always lower-cased.
+* A slug is unicode-aware.
+
+The following options apply to the new TCA type::
+
+       'type' => 'slug',
+       'config' => [
+               'generatorOptions' => [
+                       'fields' => ['title', 'nav_title'],
+                       'fieldSeparator' => '/',
+                       'prefixParentPageSlug' => true
+               ]
+               'fallbackCharacter' => '-',
+               'eval' => 'uniqueInSite'
+       ]
+
+The new `eval` option `uniqueInSite` has been introduced to evaluate if a record is unique in a page tree (specific to a
+language).
+
+The new slug TCA type allows for two `eval` options `uniqueInSite` or `uniqueInPid` (useful for third-party
+records), and no other eval setting is checked for. It is possible to set both eval options, however it is
+recommended not to do so.
+
+It is possible to build a default value from the rootline (very helpful for pages, or categorized slugs),
+but also to just generate a "speaking" segment from e.g. a news title.
+
+Sanitation and Validation configuration options apply when persisting a record via DataHandler.
+
+In the backend forms a validation happens by an AJAX call, which immediately checks any input and receives
+a new proposal in case the slug is already used.
+
+.. index:: TCA, ext:core
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85080-AddPropertyDisableFormElementsAndFinishers.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85080-AddPropertyDisableFormElementsAndFinishers.rst
new file mode 100644 (file)
index 0000000..045ca31
--- /dev/null
@@ -0,0 +1,84 @@
+.. include:: ../../Includes.txt
+
+=====================================================================
+Feature: #85080 - Add property to disable form elements and finishers
+=====================================================================
+
+See :issue:`85080`
+
+Description
+===========
+
+A a new rendering option for form elements and finishers has been introduced named :yaml:`enabled`
+which takes a boolean value (:yaml:`true` or :yaml:`false`).
+
+Setting :yaml:`enabled: true` for a form element renders it in the frontend and enables processing
+of its value including property mapping and validation. Setting :yaml:`enabled: false` instead
+disables the form element in the frontend.
+
+Setting :yaml:`enabled: true` for a finisher executes it when submitting forms, setting :yaml:`enabled: false`
+skips the finisher instead.
+
+By default :yaml:`enabled` is set to :yaml:`true`.
+
+
+Usage:
+======
+
+All form elements and finishers except the root form element and the first form page can be enabled
+or disabled.
+
+An example:
+
+.. code-block:: yaml
+
+    type: Form
+    identifier: test
+    label: test
+    prototypeName: standard
+    renderables:
+      -
+        type: Page
+        identifier: page-1
+        label: Step
+        renderables:
+          -
+            type: Text
+            identifier: text-1
+            label: Text
+            defaultValue: ''
+          -
+            type: Checkbox
+            identifier: checkbox-1
+            label: Checkbox
+            renderingOptions:
+              enabled: true
+      -
+        type: SummaryPage
+        identifier: summarypage-1
+        label: 'Summary step'
+        renderingOptions:
+          enabled: false
+    finishers:
+      -
+        identifier: Confirmation
+        options:
+          message: thx
+      -
+        identifier: Confirmation
+        options:
+          message: 'thx again'
+          renderingOptions:
+            enabled: '{checkbox-1}'
+
+In this example the form element :yaml:`checkbox-1` has been enabled explicitly but it is fine to
+leave this out since this is the default state (which can be seen in the element :yaml:`text-1`).
+
+The :yaml:`summarypage-1` has been disabled completely, for example to temporarily remove it from
+the form.
+
+The second :yaml:`Confirmation` finisher takes the fact into account that finishers can refer to
+form values. It is only enabled if the form element :yaml:`checkbox-1` has been activated by the
+user. Otherwise the finisher is skipped.
+
+.. index:: Frontend, ext:form, NotScanned
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85146-ReadEnvironmentVariablesInTypoScript.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85146-ReadEnvironmentVariablesInTypoScript.rst
new file mode 100644 (file)
index 0000000..cf3c4e9
--- /dev/null
@@ -0,0 +1,35 @@
+.. include:: ../../Includes.txt
+
+==========================================================
+Feature: #85146 - Read environment variables in TypoScript
+==========================================================
+
+See :issue:`85146`
+
+Description
+===========
+
+There is a new TypoScript value modifier `getEnv()`. The modifier checks if the variable given as its argument is set
+and reads the value if so, overriding any existing value. If the environment variable is not set, the variable given on
+the left-hand side of the expression is not changed.
+
+
+Impact
+======
+
+Write a TypoScript statement like this to use environment values in your TypoScript:
+
+.. code-block:: typoscript
+
+    # Define default value
+    myConstant = defaultValue
+    # Enable overriding by environment variable
+    myConstant := getEnv(TS_MYCONSTANT)
+
+To have a value actually inserted, your PHP execution environment (webserver, PHP-FPM) needs to have these variables
+set, or you need a mechanism like dotenv to set them in your running TYPO3.
+
+As it is a syntax feature you can use it in both constants and setup plus it gets cached, as opposed to the getText
+`getenv` feature.
+
+.. index:: TypoScript, ext:core
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85164-AvailableLanguagesRespectsSiteConfigurationSettings.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85164-AvailableLanguagesRespectsSiteConfigurationSettings.rst
new file mode 100644 (file)
index 0000000..f85e90f
--- /dev/null
@@ -0,0 +1,25 @@
+.. include:: ../../Includes.txt
+
+==========================================================================
+Feature: #85164 - Available languages respects site configuration settings
+==========================================================================
+
+See :issue:`85164`
+
+Description
+===========
+
+When the backend shows the list of available languages - for instance in the page module
+language selector, when editing records and in the list module - the list of languages
+is now restricted to those defined by the site module.
+
+If there are for instance five language records in the system, but a site configures
+only three of them for a page tree, only those three are considered when rendering
+language drop downs.
+
+In case no site configuration has been created for a tree, all language records are shown. In
+this case the Page TSconfig options :typoscript:`mod.SHARED.defaultLanguageFlag`,
+:typoscript:`mod.SHARED.defaultLanguageLabel` and :typoscript:`mod.SHARED.disableLanguages` settings
+are also considered - those are obsolete if a site configuration exists.
+
+.. index:: Backend, ext:backend
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85164-EnableLanguagesPerSite.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85164-EnableLanguagesPerSite.rst
new file mode 100644 (file)
index 0000000..5efb3c2
--- /dev/null
@@ -0,0 +1,22 @@
+.. include:: ../../Includes.txt
+
+======================================================
+Feature: #85164 - Enable Languages on a per-site basis
+======================================================
+
+See :issue:`85164`
+
+Description
+===========
+
+When configuring a new site with multiple languages, is it now possible to not allow a language to be rendered
+in the TYPO3 Frontend. A new checkbox in the Site Handling module allows to add a language but not render it in
+Frontend to allow to prepare a new translation of a website before it is going live.
+
+
+Impact
+======
+
+Going live with a new language is now as easy as turning on one checkbox.
+
+.. index:: Frontend
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85236-InfixOptionToDefaultLogFileNamesForFileWriter.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85236-InfixOptionToDefaultLogFileNamesForFileWriter.rst
new file mode 100644 (file)
index 0000000..8576212
--- /dev/null
@@ -0,0 +1,35 @@
+.. include:: ../../Includes.txt
+
+=======================================================================
+Feature: #85236 - Infix option to default log file names for FileWriter
+=======================================================================
+
+See :issue:`85236`
+
+Description
+===========
+
+A new option :php:`logFileInfix` for the :php:`FileWriter` has been introduced.
+This allows to set a different name for the log file that is created by the :php:`FileWriter`
+without having to define a full path to the file.
+
+The example configuration will use the log file named :file:`typo3\_special\_<hash>.log`
+for any log message stemming from a class from the :php:`\Vendor\ExtName\` namespace.
+
+.. code-block:: php
+
+   $GLOBALS['TYPO3_CONF_VARS']['LOG']['Vendor']['ExtName']['writerConfiguration'] = [
+     \TYPO3\CMS\Core\Log\LogLevel::INFO => [
+       \TYPO3\CMS\Core\Log\Writer\FileWriter::class => [
+         'logFileInfix' => 'special'
+       ]
+     ]
+   ];
+
+
+Impact
+======
+
+The behaviour for existing :php:`FileWriter` configurations is not changed.
+
+.. index:: LocalConfiguration, ext:core
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85247-TraitToDetectPublicDeprecatedMethods.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85247-TraitToDetectPublicDeprecatedMethods.rst
new file mode 100644 (file)
index 0000000..ed652a0
--- /dev/null
@@ -0,0 +1,29 @@
+.. include:: ../../Includes.txt
+
+===========================================================
+Feature: #85247 - Trait to detect public deprecated methods
+===========================================================
+
+See :issue:`85247`
+
+Description
+===========
+
+The trait :php:`TYPO3\CMS\Core\Compatibility\PublicMethodDeprecationTrait` has been added
+to allow setting public methods to protected in a backwards compatible way.
+
+The core uses this trait to set public methods that should be protected or private but
+are accessible code wise for historical reasons, while extensions using the methods do not
+break, but a PHP :php:`E_USER_DEPRECATED` error is triggered.
+
+Classes using this trait have a property :php:`$deprecatedPublicMethods` that lists all
+methods covered by the trait.
+
+
+Impact
+======
+
+Core classes using this trait trigger PHP :php:`E_USER_DEPRECATED` errors if an extension uses a method that
+has been made protected using the trait functionality.
+
+.. index:: PHP-API
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85256-InstallTYPO3OnSQLite.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85256-InstallTYPO3OnSQLite.rst
new file mode 100644 (file)
index 0000000..1eb3699
--- /dev/null
@@ -0,0 +1,45 @@
+.. include:: ../../Includes.txt
+
+=========================================
+Feature: #85256 - Install TYPO3 on SQLite
+=========================================
+
+See :issue:`85256`
+
+Description
+===========
+
+The TYPO3 web installer allows to install the system on `SQLite` DBMS.
+
+This platform can be selected if :php:`pdo_sqlite` is available in PHP, which is
+often the case. SQLite can be a nice DBMS for relatively small instances and has
+the advantage that no further server side daemon is needed.
+
+Administrators must keep an eye on security if using this platform:
+
+In SQLite, a database is stored in a single file. In TYPO3, its default location
+is the var/sqlite path of the instance which is derived from environment variable
+:php:`TYPO3_PATH_APP`. If that variable is **not** set which is
+often the case in non-composer instances, **the database file will end up in the
+web server accessible document root directory :file:`typo3conf/`**!
+
+To prevent guessing the database name and simply downloading it, the installer appends
+a random string to the database filename during installation. Additionally, the demo
+Apache :file:`_.htaccess` file prevents downloading :file:`.sqlite` files. The demo
+MicroSoft IIS web server configuration in file :file:`_web.config` comes with the same
+restriction.
+
+Administrators installing TYPO3 using the SQLite platform should thus test if the
+database is downloadable from the web and take measures to prevent this by either
+configuring the web server to deny this file, or - better - by moving the config folder
+out of the web root, which is good practice anyway.
+
+
+Impact
+======
+
+TYPO3 can be installed to run on SQLite. If choosing this option, administrators
+must check the file is never delivered by the web server.
+
+
+.. index:: Database
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85313-AddNotesFieldToPagesTable.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85313-AddNotesFieldToPagesTable.rst
new file mode 100644 (file)
index 0000000..d5027bb
--- /dev/null
@@ -0,0 +1,20 @@
+.. include:: ../../Includes.txt
+
+================================================
+Feature: #85313 - Add notes field to pages table
+================================================
+
+See :issue:`85313`
+
+Description
+===========
+
+A :php:`descriptionColumn` has been added to the pages table.
+
+
+Impact
+======
+
+Users can add notes to each page record to inform other users of important facts or similar.
+
+.. index:: Backend
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85355-SupportBasicHTML5FieldsInFormEngine.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85355-SupportBasicHTML5FieldsInFormEngine.rst
new file mode 100644 (file)
index 0000000..87ef2e4
--- /dev/null
@@ -0,0 +1,23 @@
+.. include:: ../../Includes.txt
+
+==========================================================
+Feature: #85355 - Support basic HTML5 fields in FormEngine
+==========================================================
+
+See :issue:`85355`
+
+Description
+===========
+
+The FormEngine renders now HTML5 specific field types and attributes.
+
+
+Impact
+======
+
+Depending on the :php:`eval` configuration, the input types may be :html:`text`, :html:`number`
+or :html:`email.`
+If :php:`range` is configured, its values are stored in :html:`min` and :html:`max` attributes
+for number fields.
+
+.. index:: Backend, ext:backend
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85389-ContextAPIForConsistentDataHandling.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85389-ContextAPIForConsistentDataHandling.rst
new file mode 100644 (file)
index 0000000..dd8e43d
--- /dev/null
@@ -0,0 +1,125 @@
+.. include:: ../../Includes.txt
+
+==========================================================
+Feature: #85389 - Context API for consistent data handling
+==========================================================
+
+See :issue:`85389`
+
+Description
+===========
+
+A new Context API is introduced, which encapsulates various information for data retrieval (e.g. inside
+the database) and analysis of current permissions and caching information.
+
+Previously, various information was distributed inside globally accessible objects (:php:`$TSFE` or :php:`$BE_USER`)
+like the current workspace ID or if a frontend or backend user is authenticated. Having a global object
+available was also dependent on the current request type (frontend or backend), instead of having
+one consistent place where all this data is located.
+
+The context is currently instantiated at the very beginning of each TYPO3 entry point, keeping track
+of the current time (formally known as :php:`$GLOBALS['EXEC_TIME']`, if a user is logged in,
+and which workspace is currently accessed.
+
+This information is separated in so-called "Aspects", each being responsible for a certain area:
+
+- :php:`VisibilityAspect`, holding information if hidden/deleted records should be fetched from the database
+- :php:`DateTimeAspect`, keeping the current date as immutable datetime object
+- :php:`UserAspect`, holding frontend/backend user IDs, usernames and usergroups
+- :php:`WorkspaceAspect`, holding the currently visible workspace (default to "0"/ live)
+- :php:`LanguageAspect`, holding information about the currently used language/overlay/fallback strategy
+
+Extensions can add their own Aspects as well, as they only need to implement the AspectInterface.
+
+The Context object is used as a Singleton, available via :php:`GeneralUtility::makeInstance(Context::class)`.
+
+Adding or replacing an aspect has implications on the whole further request. The recommended way on doing
+so is using a PSR-15 middleware. In the future (TYPO3 v10), the global context will have a "frozen" state
+after all PSR-15 middlewares are run through, to ensure a consistent object throughout all renderings
+within a backend.
+
+However, if, for a certain retrieval part a custom context is needed, the necessary PHP classes, like
+:php:`PageRepository` can receive a custom Context object. For this to work, a new Context object can be
+created via :php:`new Context()` or cloned from the master context via
+:php:`$myContext = clone GeneralUtility::makeInstance(Context::class);` to keep all existing aspects and only to
+override a certain aspect locally.
+
+A huge benefit when using the Context API is a strong decoupling of various architectural failures within
+TYPO3 Core, which are now "Context aware" and do not depend on a certain global object being available.
+
+This will not only unify the code quality, but also introduce a better standard, where hard intermingling within
+Extbase, PageRepository and TypoScriptFrontendController can be found.
+
+Impact
+======
+
+The new Context API replaces lots of places known for a very long time:
+
+* :php:`DateTimeAspect` replaces :php:`$GLOBALS['SIM_EXEC_TIME']` and :php:`$GLOBALS['EXEC_TIME']`
+* :php:`VisibilityAspect` replaces :php:`$GLOBALS['TSFE']->showHiddenPages` and :php:`$GLOBALS['TSFE']->showHiddenRecords`
+* :php:`WorkspaceAspect` replaces :php:`$GLOBALS['BE_USER']->workspace`
+* :php:`LanguageAspect` replaces various properties related to language Id, overlay and fallback logic, mostly within Frontend
+* :php:`UserAspect` replaces various calls and checks on :php:`$GLOBALS['BE_USER']` and :php:`$GLOBALS['TSFE']->fe_user`
+options when only some information is needed.
+
+
+TYPO3 Core comes with the following Aspects within the global context:
+
+* date
+* frontend.user
+* backend.user
+* workspace
+* visibility
+* language
+
+Usage
+=====
+
+As for TYPO3 v9, the old properties can be used the same way as before, but will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+It is recommended to read data from the current global Context for custom extensions:
+
+.. code-block:: php
+
+    $context = GeneralUtility::makeInstance(Context::class);
+
+    // Reading the current data instead of $GLOBALS['EXEC_TIME']
+    $currentTimestamp = $context->getPropertyFromAspect('date', 'timestamp');
+
+    // Checking if a user is logged in
+    $userIsLoggedIn = $context->getPropertyFromAspect('frontend.user', 'isLoggedIn');
+
+
+If an aspect needs to be added, or a middleware replaces an aspect, the main context object can be altered.
+
+However, if custom DB queries need to be made, it is strongly recommended to clone the context object:
+
+.. code-block:: php
+
+    // Current global context
+    $context = GeneralUtility::makeInstance(Context::class);
+    $localContextWithoutFrontendUser = clone $context;
+    $localContextWithoutFrontendUser->setAspect('frontend.user', GeneralUtility::makeInstance(UserAspect::class, null);
+
+    // Fetch a page which is publicly available, but not accessible when logged in
+    $sysPage = GeneralUtility::makeInstance(PageRepository::class, $localContextWithoutFrontendUser);
+    $pageRow = $sysPage->getPage($pageId);
+
+
+As a rule of thumb:
+- If new code is written that depends on external factors for querying data, ensure that a context object
+can be handed in via e.g. the constructor.
+- If you are sure, that the consuming class is NOT altering the context object, the main context object can be used
+- If the consuming class, e.g. ContentObjectRenderer is altering the context object, it is recommended to hand in a clone
+of a context.
+
+Further development
+===================
+
+There will be additional aspects that will be introduced in TYPO3 Core. Also see PSR-15 middlewares shipped with TYPO3
+Frontend or Backend to see how aspects can be modified and set.
+
+Aspects eventually will become the successor of Database Restrictions, as they contain all information
+necessary to restrict a database query.
+
+.. index:: PHP-API, ext:core
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85410-AllowTCADescriptionProperty.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85410-AllowTCADescriptionProperty.rst
new file mode 100644 (file)
index 0000000..21dca74
--- /dev/null
@@ -0,0 +1,40 @@
+.. include:: ../../Includes.txt
+
+================================================
+Feature: #85410 - Allow TCA description property
+================================================
+
+See :issue:`85410`
+
+Description
+===========
+
+The new `TCA` property `description` on column field level has been introduced.
+The value data type is a localized string, similar and on the same level as `label`.
+
+The property can be used to display an additional help text between the field label and
+the user input when editing records. As an example, the core uses the description property
+in the site configuration module when editing a site on some properties like `identifier`.
+
+The property is available on all common `TCA` types like `input` and `select` and so on.
+
+Example::
+
+    'columns' => [
+        'myField' => [
+            'label' => 'My label',
+            'description' => 'LLL:EXT:my_ext/Resources/Private/Language/locallang_tca.xlf:field.description',
+            'config' => [
+                'type' => 'input',
+            ],
+        ],
+    ],
+
+
+Impact
+======
+
+The change is fully backwards compatible and can be used by integrators or administrators
+to hint editors for expected field input.
+
+.. index:: Backend, FlexForm, TCA
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85550-IntroduceContextForTypoScriptDataGetTextProperty.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85550-IntroduceContextForTypoScriptDataGetTextProperty.rst
new file mode 100644 (file)
index 0000000..e0748df
--- /dev/null
@@ -0,0 +1,31 @@
+.. include:: ../../Includes.txt
+
+========================================================================
+Feature: #85550 - Introduce context for TypoScript data getText property
+========================================================================
+
+See :issue:`85550`
+
+Description
+===========
+
+The new context API can now be accessed via the :ts:`getText` property in TypoScript.
+
+Example:
+
+.. code-block:: typoscript
+
+       page.10 = TEXT
+       page.10.data = context:workspace:id
+       page.10.wrap = You are in workspace: |
+
+Where as `context` is the keyword for accessing an aspect, the second part is the name of the aspect,
+and the third part is the property of the aspect.
+
+.. code-block:: typoscript
+
+       data = context:[aspectName]:[propertyName]
+
+If a property is an array, it is converted into a comma-separated list.
+
+.. index:: TypoScript, ext:frontend
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85590-AddHooksForDatabaseRecordListCSVActions.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85590-AddHooksForDatabaseRecordListCSVActions.rst
new file mode 100644 (file)
index 0000000..0440a19
--- /dev/null
@@ -0,0 +1,27 @@
+.. include:: ../../Includes.txt
+
+==============================================================
+Feature: #85590 - Add hooks for DatabaseRecordList CSV actions
+==============================================================
+
+See :issue:`85590`
+
+Description
+===========
+
+It is now possible to customize the csv output in the DatabaseRecordList with hooks.
+
+The following two hooks were implemented:
+
+- customizeCsvHeader for the header
+- customizeCsvRow for a single row
+
+
+Example:
+
+.. code-block:: php
+
+    $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS'][DatabaseRecordList::class]['customizeCsvRow'][] = \Vendor\ExtName\Hooks\CsvExport::class . '->customizeCsvRow';
+    $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS'][DatabaseRecordList::class]['customizeCsvHeader'][] = \Vendor\ExtName\Hooks\CsvExport::class . '->customizeCsvHeader';
+
+.. index:: Backend, PHP-API
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85678-AddAPIForTitleTags.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85678-AddAPIForTitleTags.rst
new file mode 100644 (file)
index 0000000..6c0c2c4
--- /dev/null
@@ -0,0 +1,96 @@
+.. include:: ../../Includes.txt
+
+===================================
+Feature: #85678 - Add PageTitle API
+===================================
+
+See :issue:`85678`
+
+Description
+===========
+
+In order to keep setting the titles in control, a new API to set the page title has been introduced.
+
+The API uses :php:`PageTitleProviders` to define the page title based on page record and the content on the page.
+
+Based on the priority of the providers, the :php:`PageTitleProviderManager` will check the providers if a title
+is given by the provider. It will start with the highest priority PageTitleProviders and will end with the lowest
+in priority.
+
+By default, the core ships three providers. The provider with the (by default) highest priority will be the
+:php:`AltPageTitleProvider`. This provider handles the (since TYPO3 v9 deprecated) property
+:php:`$GLOBALS['TSFE']->altPageTitle`. If an extension has set a value to this property, this provider will return
+that value.
+
+If you have installed the system extension SEO, the second provider will be the :php:`SeoTitlePageTitleProvider`.
+When an editor has set a value for the SEO title in the page properties of the page, this provider will provide
+that title to the :php:`PageTitleProviderManager`. If you have not installed the SEO system extension, this fields
+and provider are not available.
+
+The fallback provider with the lowest priority is the :php:`RecordPageTitleProvider`. When no other title is set
+by a provider, this provider will return the title of the page.
+
+Besides the providers shipped by core, you can add own providers. An integrator can define the priority of the
+providers for his project.
+
+Create your own PageTitleProvider
+=================================
+
+Extension developers may want to have an own provider for page titles. For example if you have an extension with
+records and a detail view, the title of the page record will not be the correct title. To make sure to display
+the correct page title, you have to create your own :php:`PageTitleProvider`. It is quite easy to create one.
+
+First of all create a PHP class in your extension that implements the :php:`PageTitleProviderInterface`. This will
+force you to have at least the :php:`getTitle()` method in your class. Within this method you can create your
+own logic to define the correct title.
+
+Define priority of PageTitleProviders
+=====================================
+
+The priority of the providers are set by the TypoScript property :typoscript:`config.pageTitleProviders`. This
+way an integrator is able to set the priorities for his project and can even have conditions in place.
+
+By default, the core has the following setup:
+
+.. code-block:: typoscript
+
+   config.pageTitleProviders {
+        altPageTitle {
+            provider = TYPO3\CMS\Core\PageTitle\AltPageTitleProvider
+            before = record
+        }
+        record {
+            provider = TYPO3\CMS\Core\PageTitle\RecordPageTitleProvider
+        }
+   }
+
+The ordering of the providers is based on the `before` and `after` parameters. If you want a provider to be handled
+before a specific other provider, just set that provider in the `before`, do the same with `after`.
+
+If you have installed the system extension SEO, you will also get a third provider. The configuration will be:
+
+.. code-block:: typoscript
+
+   config.pageTitleProviders {
+      altPageTitle {
+         provider = TYPO3\CMS\Core\PageTitle\AltPageTitleProvider
+         before = record
+      }
+      record {
+         provider = TYPO3\CMS\Core\PageTitle\RecordPageTitleProvider
+      }
+      seo {
+         provider = TYPO3\CMS\Seo\PageTitle\SeoTitlePageTitleProvider
+         before = record
+         after = altPageTitle
+      }
+   }
+
+First the :php:`AltPageTitleProvider` will be checked, then the :php:`SeoTitlePageTitleProvider` (because it will be
+handled before record and after altPageTitle) and if both providers didn't provide a title, the
+:php:`RecordPageTitleProvider` will be checked.
+
+You can override these settings within your own installation. You can add as many providers as you want. Be aware
+that if a provider returns a non-empty value, all provider with a lower priority won't be checked.
+
+.. index:: Frontend, ext:core, ext:seo
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85691-ShowPagePathForReferencesInRecordInfo.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85691-ShowPagePathForReferencesInRecordInfo.rst
new file mode 100644 (file)
index 0000000..8e1e30e
--- /dev/null
@@ -0,0 +1,22 @@
+.. include:: ../../Includes.txt
+
+==============================================================
+Feature: #85691 - Show page path for references in record info
+==============================================================
+
+See :issue:`85691`
+
+Description
+===========
+
+The page path of record references is displayed into the table found in the record info.
+This field will display the full path to the record referencing the record in order to
+make it easier for an editor to follow to the target.
+
+
+Impact
+======
+
+Record references via the record info are easier to find.
+
+.. index:: Backend, ext:backend
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85698-NewTypeinputEvalSaltedPassword.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85698-NewTypeinputEvalSaltedPassword.rst
new file mode 100644 (file)
index 0000000..ccd138d
--- /dev/null
@@ -0,0 +1,31 @@
+.. include:: ../../Includes.txt
+
+====================================================
+Feature: #85698 - New type=input eval saltedPassword
+====================================================
+
+See :issue:`85698`
+
+Description
+===========
+
+Setting passwords and storing them as salted passwords in the database
+is now supported by adding the eval option :php:`saltedPassword` to :php:`TCA` :php:`type=input`
+fields.
+
+Fields having this eval set will get their value evaluated to a salted
+hash before they are stored by the :php:`DataHandler`.
+
+Note the salt configuration for backend (BE) is considered when using this eval
+on tables that is not the :php:`fe_users` table.
+
+
+Impact
+======
+
+The new eval substitutes custom code that has been done within the
+salted passwords extension before. It has no impact on instances
+being upgraded.
+
+
+.. index:: Backend, TCA
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85719-AllowSitesWithoutSchemeOrDomain.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85719-AllowSitesWithoutSchemeOrDomain.rst
new file mode 100644 (file)
index 0000000..bb10dbc
--- /dev/null
@@ -0,0 +1,41 @@
+.. include:: ../../Includes.txt
+
+======================================================
+Feature: #85719 - Allow sites without scheme or domain
+======================================================
+
+See :issue:`85719`
+
+Description
+===========
+
+Since the inception of site handling, the definition of a site base - the URL prefix - was limited to
+only allow a full URI with scheme (HTTP/HTTPS) and domain. This didn't allow to run TYPO3 on multiple
+domains, basically limiting the URL-resolving ("Site Routing") compared to previous URL handling
+solutions in the past.
+
+A new site routing based on symfony/routing component allows to have a flexible routing based on
+specific schemes.
+
+
+Impact
+======
+
+It is now possible to set a site base prefix to just "/site1" and "/site2" or "www.mydomain.com" instead
+of entering a full URI.
+
+This allows to have a Site base e.g. `www.mydomain.com` to be detected with http and https protocols,
+although it is recommended to do a HTTP to HTTPS redirect either on the webserver level, via a
+.htaccess rewrite rule, or by adding a redirect in TYPO3.
+
+Please also note that this improved flexibility will introduce side-effects when having multiple sites
+with mixed configuration settings as Site base:
+
+- Site 1: `/mysite/`
+- Site 2: `www.mydomain.com`
+
+will be unspecific when detecting a URL like `www.mydomain/mysite/` and can lead to side-effects.
+
+In this case, it is necessary by the Site Administrator to define unique Site base prefixes.
+
+.. index:: Frontend
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85828-MoveSymfonyExpressionLanguageHandlingIntoEXTcore.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85828-MoveSymfonyExpressionLanguageHandlingIntoEXTcore.rst
new file mode 100644 (file)
index 0000000..243f629
--- /dev/null
@@ -0,0 +1,37 @@
+.. include:: ../../Includes.txt
+
+=========================================================================
+Feature: #85828 - Move symfony expression language handling into EXT:core
+=========================================================================
+
+See :issue:`85828`
+
+Description
+===========
+
+The symfony expression language handling has been moved out of EXT:form into EXT:core.
+Thus, it is available to be used throughout the core and also for extension developers.
+
+To use the expression language, a provider definition is required which implements the
+:php:`\TYPO3\CMS\Core\ExpressionLanguage\ProviderInterface`.
+The core comes with a :php:`\TYPO3\CMS\Core\ExpressionLanguage\DefaultProvider` class which can be used directly.
+For a custom implementation the :php:`\TYPO3\CMS\Core\ExpressionLanguage\AbstractProvider` class can be extended.
+
+The provider can provide additional variables and expression functions to extend the expression language.
+For a custom implementation check out the :php:`\TYPO3\CMS\Form\Domain\Condition\ConditionProvider` class.
+
+A usage example:
+
+.. code-block:: php
+
+   $provider = GeneralUtility::makeInstance(\TYPO3\CMS\Core\ExpressionLanguage\DefaultProvider::class);
+   $conditionResolver = GeneralUtility::makeInstance(\TYPO3\CMS\Core\ExpressionLanguage\Resolver::class, $provider);
+   $conditionResolver->evaluate('1 < 2'); // result is true
+
+
+Impact
+======
+
+The expression language can now be used in other scopes and has no dependency to EXT:form.
+
+.. index:: Backend, Frontend, PHP-API, ext:core
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85829-ImplementSymfonyExpressionLanguageForTypoScriptConditions.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85829-ImplementSymfonyExpressionLanguageForTypoScriptConditions.rst
new file mode 100644 (file)
index 0000000..c199f49
--- /dev/null
@@ -0,0 +1,196 @@
+.. include:: ../../Includes.txt
+
+=================================================================================
+Feature: #85829 - Implement symfony expression language for TypoScript conditions
+=================================================================================
+
+See :issue:`85829`
+
+Description
+===========
+
+The `symfony expression language <https://symfony.com/doc/current/components/expression_language.html>`__
+has been implemented for TypoScript conditions in both frontend and backend.
+The existing conditions are available as variables and/or functions. Please check the following tables in detail.
+
+General Usage
+-------------
+
+To learn the full power of the symfony expression language please check the `documentation for the common expression syntax <https://symfony.com/doc/current/components/expression_language/syntax.html>`__.
+Here are some examples to understand the power of the expression language:
+
+.. code-block:: typoscript
+
+   [page["uid"] in 18..45]
+   # This condition matches if current page uid is between 18 and 45
+   [END]
+
+   [userId in [1,5,7]]
+   # This condition matches if current logged in user has the uid 1, 5 or 7
+   [END]
+
+   [not ("foo" matches "/bar/")]
+   # This condition does match if "foo" **not** matches the regExp: `/bar/`
+   [END]
+
+   [applicationContext == "Production"] && [userId == 15] && [globalVar('TSFE:id') == 125]
+   # This condition match if application context is "Production" AND logged in user has the uid 15 AND current page is 125
+   # This condition could also be combined in one condition:
+   # [applicationContext("Production") && userId == 15 && globalVar('TSFE:id') == 125]
+   [END]
+
+   [request.getNormalizedParams().getHttpHost() == 'typo3.org']
+   # This condition matches if current hostname is typo3.org
+   [END]
+
+   [like(request.getNormalizedParams().getHttpHost(), "*.devbox.local")]
+   # This condition matches if current hostname is any subdomain of devbox.local
+   [END]
+
+   [request.getNormalizedParams().isHttps() == false]
+   # This condition matches if current request is **not** https
+   [END]
+
+
+Variables
+---------
+
+The following variables are available. The values are context related.
+
++---------------------+------------+----------------------------------------------------------------+
+| Variable            | Type       | Description                                                    |
++=====================+============+================================================================+
+| applicationContext  | String     | current application context as string                          |
++---------------------+------------+----------------------------------------------------------------+
+| page                | Array      | current page record as array                                   |
++---------------------+------------+----------------------------------------------------------------+
+| {$foo.bar}          | Constant   | Any TypoScript constant is available like before.              |
+|                     |            | Depending on the type of the constant you have to use          |
+|                     |            | different conditions, see examples below:                      |
+|                     |            | - if constant is an integer:                                   |
+|                     |            | - [{$foo.bar} == 4711]                                         |
+|                     |            | - if constant is a string put constant in quotes:              |
+|                     |            | - ["{$foo.bar}" == "4711"]                                     |
++---------------------+------------+----------------------------------------------------------------+
+| tree                | Object     | object with tree information                                   |
+| .level              | Integer    | current tree level                                             |
+| .rootLine           | Array      | array of arrays with uid and pid                               |
+| .rootLineIds        | Array      | an array with UIDs of the rootline                             |
++---------------------+------------+----------------------------------------------------------------+
+| backend             | Object     | object with backend information (available in BE only)         |
+| .user               | Object     | object with current backend user information                   |
+| .user.isAdmin       | Boolean    | true if current user is admin                                  |
+| .user.isLoggedIn    | Boolean    | true if current user is logged in                              |
+| .user.userId        | Integer    | UID of current user                                            |
+| .user.userGroupList | String     | comma list of group UIDs                                       |
++---------------------+------------+----------------------------------------------------------------+
+| frontend            | Object     | object with frontend information (available in FE only)        |
+| .user               | Object     | object with current frontend user information                  |
+| .user.isLoggedIn    | Boolean    | true if current user is logged in                              |
+| .user.userId        | Integer    | UID of current user                                            |
+| .user.userGroupList | String     | comma list of group UIDs                                       |
++---------------------+------------+----------------------------------------------------------------+
+| typo3               | Object     | object with TYPO3 related information                          |
+| .version            | String     | TYPO3_version (e.g. 9.4.0-dev)                                 |
+| .branch             | String     | TYPO3_branch (e.g. 9.4)                                        |
+| .devIpMask          | String     | $GLOBALS['TYPO3_CONF_VARS']['SYS']['devIPmask']                |
++---------------------+------------+----------------------------------------------------------------+
+
+
+Functions
+---------
+
+Functions take over the logic of the old conditions which do more than a simple comparison check.
+The following functions are available in **any** context:
+
++------------------------+-----------------------+--------------------------------------------------+
+| Function               | Parameter             | Description                                      |
++========================+=======================+==================================================+
+| request                | Custom Object         | This object provides 4 methods                   |
+| .getQueryParams()      |                       | - [request.getQueryParams()['foo'] == 1]         |
+| .getParsedBody()       |                       | - [request.getParsedBody()['foo'] == 1]          |
+| .getHeaders()          |                       | - [request.getHeaders()['Accept'] == 'json']     |
+| .getCookieParams()     |                       | - [request.getCookieParams()['foo'] == 1]        |
+| .getNormalizedParams() |                       | - [request.getNormalizedParams().isHttps()]      |
++------------------------+-----------------------+--------------------------------------------------+
+| date                   | String                | Get current date in given format.                |
+|                        |                       | Examples:                                        |
+|                        |                       | - true if day of current month is 7:             |
+|                        |                       | - [date("j") == 7]                               |
+|                        |                       | - true if day of current week is 7:              |
+|                        |                       | - [date("w") == 7]                               |
+|                        |                       | - true if day of current year is 7:              |
+|                        |                       | - [date("z") == 7]                               |
+|                        |                       | - true if current hour is 7:                     |
+|                        |                       | - [date("G") == 7]                               |
++------------------------+-----------------------+--------------------------------------------------+
+| like                   | String                | This function has two parameters:                |
+|                        |                       | the first parameter is the string to search in   |
+|                        |                       | the second parameter is the search string        |
+|                        |                       | Example:                                         |
+|                        |                       | - [like("foobarbaz", "*bar*")]                   |
++------------------------+-----------------------+--------------------------------------------------+
+| ip                     | String                | Value or Constraint, Wildcard or RegExp possible |
+|                        |                       | special value: devIP (match the devIPMask        |
++------------------------+-----------------------+--------------------------------------------------+
+| compatVersion          | String                | version constraint, e.g. 9.4 or 9.4.0            |
++------------------------+-----------------------+--------------------------------------------------+
+| loginUser              | String                | value or constraint, wildcard or RegExp possible |
+|                        |                       | Examples:                                        |
+|                        |                       | - [loginUser('*')]          // any logged in user|
+|                        |                       | - [loginUser(1)]            // user with uid 1   |
+|                        |                       | - [loginUser('1,3,5')]      // user 1, 3 or 5    |
+|                        |                       | - [loginUser('*') == false] // not logged in     |
++------------------------+-----------------------+--------------------------------------------------+
+| getTSFE                | Object                | TypoScriptFrontendController ($GLOBALS['TSFE'])  |
++------------------------+-----------------------+--------------------------------------------------+
+| getenv                 | String                | PHP function: getenv()                           |
++------------------------+-----------------------+--------------------------------------------------+
+| usergroup              | String                | value or constraint, wildcard or RegExp possible |
++------------------------+-----------------------+--------------------------------------------------+
+
+
+The following functions are only available in **frontend** context:
+
++--------------------+------------+-----------------------------------------------------------------+
+| Function           | Parameter  | Description                                                     |
++====================+============+=================================================================+
+| session            | String     | Get value from session                                          |
+|                    |            | Example, matches if session value = 1234567                     |
+|                    |            | - [session("session:foo|bar") == 1234567]                       |
++--------------------+------------+-----------------------------------------------------------------+
+| site               | String     | get value from site configuration, or null if                   |
+|                    |            | no site was found or property does not exists                   |
+|                    |            | Example, matches if site identifier = foo                       |
+|                    |            | - [site("identifier") == "foo"]                                 |
+|                    |            | Example, matches if site base = http://localhost                |
+|                    |            | - [site("base") == "http://localhost"]                          |
++--------------------+------------+-----------------------------------------------------------------+
+| siteLanguage       | String     | get vale from siteLanguage configuration, or                    |
+|                    |            | null if no site was found or property not exists                |
+|                    |            | Example, match if siteLanguage locale = foo                     |
+|                    |            | - [siteLanguage("locale") == "de_CH"]                           |
+|                    |            | Example, match if siteLanguage title = Italy                    |
+|                    |            | - [siteLanguage("title") == "Italy"]                            |
++--------------------+------------+-----------------------------------------------------------------+
+
+
+Extending the expression language with own functions (like old userFunc)
+------------------------------------------------------------------------
+
+It is possible to extend the expression language with own functions like before userFunc in the old conditions.
+An example could be :php:`TYPO3\CMS\Core\ExpressionLanguage\TypoScriptConditionFunctionsProvider` which implements
+the most core functions.
+
+Add new methods by implementing own providers which implement the :php:`ExpressionFunctionProviderInterface` and
+register the provider in :file:`ext_localconf.php`:
+
+.. code-block:: php
+
+   if (!is_array($GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['TYPO3\CMS\Core\ExpressionLanguage\TypoScriptConditionProvider']['additionalExpressionLanguageProvider'])) {
+      $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['TYPO3\CMS\Core\ExpressionLanguage\TypoScriptConditionProvider']['additionalExpressionLanguageProvider'] = [];
+   }
+   $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['TYPO3\CMS\Core\ExpressionLanguage\TypoScriptConditionProvider']['additionalExpressionLanguageProvider'][] = \My\NameSpace\Provider\TypoScriptConditionProvider::class;
+
+
+.. index:: Backend, Frontend, TypoScript, ext:core
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85894-FeatureTogglesInAdminToolsSettings.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85894-FeatureTogglesInAdminToolsSettings.rst
new file mode 100644 (file)
index 0000000..99f317e
--- /dev/null
@@ -0,0 +1,22 @@
+.. include:: ../../Includes.txt
+
+=========================================================
+Feature: #85894 - Feature toggles in Admin Tools Settings
+=========================================================
+
+See :issue:`85894`
+
+Description
+===========
+
+Feature toggles registered in :file:`DefaultConfiguration.php` and documented
+in :file:`DefaultConfigurationDescription.yml` can now be toggled using
+the interface Admin Tools -> Settings -> Feature toggles.
+
+
+Impact
+======
+
+Toggling core features is possible using the backend.
+
+.. index:: Backend, LocalConfiguration, ext:install
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85900-PseudoSiteHandling.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85900-PseudoSiteHandling.rst
new file mode 100644 (file)
index 0000000..7688cbe
--- /dev/null
@@ -0,0 +1,27 @@
+.. include:: ../../Includes.txt
+
+======================================
+Feature: #85900 - Pseudo Site Handling
+======================================
+
+See :issue:`85900`
+
+Description
+===========
+
+The new site handling functionality has a counterpart for usages within PHP code where no site configuration
+can be found, which is named "Pseudo Site", a site without configuration.
+
+For a pseudo-site it is not possible to determine all available languages (as they are only configured in
+TypoScript), or the proper labels for the default language (as this is done in PageTSconfig), however, a
+PseudoSite or Site object (both instances of "SiteInterface") is now always attached to every Frontend or
+Backend request via a PSR-15 middleware.
+
+
+Impact
+======
+
+Extension Developers can now access a site and determine the base URL / Entry Point URL for a site, or access
+all available languages via the SiteInterface object, instead of querying sys_domain or sys_language respectively.
+
+.. index:: PHP-API
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85928-UpgradeWizardToMigratePagesToSpeakingURLs.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85928-UpgradeWizardToMigratePagesToSpeakingURLs.rst
new file mode 100644 (file)
index 0000000..1edde54
--- /dev/null
@@ -0,0 +1,42 @@
+.. include:: ../../Includes.txt
+
+==================================================================
+Feature: #85928 - Upgrade wizard to migrate pages to speaking URLs
+==================================================================
+
+See :issue:`85928`
+
+Description
+===========
+
+TYPO3 now supports "Speaking URLs" for pages, and in order to fully make use of this feature, an
+upgrade wizard builds up the URL segment (pagepath) for all pages that do not have a value
+set already.
+
+In order to ease the pain when upgrading from previous versions that supported RealURL,
+the upgrade wizard checks for additional tables "tx_realurl_pathcache" (realurl v1) and
+"tx_realurl_pathdata" (realurl v2+). If they exist in the database, these values are used to fill the page paths,
+however they will get sanitized to match the slug layout with a prefixed "/".
+
+Pages that contain value in their "alias" database field, this takes priority over "regular" pages
+and values from RealURL, whereas alias fields will result in a slug like "/my-alias-value".
+
+
+Impact
+======
+
+After running the upgrade wizard, it is possible to use all of the speaking URL functionality for
+all pages that support a site configuration.
+
+The upgrade wizard also runs through all pages that do not have a site configuration yet, in
+order to ensure consistent state throughout the database. It is encouraged to create a site
+configuration for a pagepath before running this upgrade wizard.
+
+Please take note that running the upgrade wizard does not migrate a previously configured RealURL
+project fully to the new structure. It only eases the migration, but the full migration depends
+on many more previous URL generation configurations used.
+
+Also: if `simulate_static`, `realurl` or `cooluri` or any other extension for URL rewriting was
+used, it is highly possible that pages are now available under different URLs than before.
+
+.. index:: Database
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85947-PageBasedURLHandling.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85947-PageBasedURLHandling.rst
new file mode 100644 (file)
index 0000000..d347c61
--- /dev/null
@@ -0,0 +1,45 @@
+.. include:: ../../Includes.txt
+
+=========================================
+Feature: #85947 - Page based URL handling
+=========================================
+
+See :issue:`85947`
+
+Description
+===========
+
+Page records now have a field called "slug" that contains the website
+frontend path to the page, like "/team/about-us/". When a page has the
+field filled, the URL which the site is linked to, will receive a full URL
+to that page, instead of the common :php:`index.php?id=xy` that TYPO3 builds
+by default.
+
+When using Site Handling for a page tree, this page-based URL handling is
+enabled by default and requires proper URL Rewrite Rules from the server.
+
+The slug field is shown when editing page records in the backend and is
+resolved to the page uid in the frontend if a "Site configuration" in the
+site module has been set up.
+
+Note: Page-based URL handling only works if a Site configuration
+has been set up since otherwise neither the domain nor the language can
+be properly resolved which is a requirement to resolve the page path part
+of the URL.
+
+Note #2: If a page has the path segment "/team/about-us", but there is no
+other page with a path segment "/team/about-us/", then an automatic 307
+HTTP redirect to the proper URI is triggered.
+
+Note #3: Since #85900 any request is always connected to either a Site or a
+PseudoSite Object, so even if the site configuration is missing, basic values
+are available for processing. Nonetheless, it is recommended to provide a proper site
+configurations for any site.
+
+Impact
+======
+
+Integrators should configure their sites in the Sites module to take advantage
+of the core internal page based routing.
+
+.. index:: Backend, Database, Frontend, TCA
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85991-ExcludeSymfonyCommandsFromScheduler.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-85991-ExcludeSymfonyCommandsFromScheduler.rst
new file mode 100644 (file)
index 0000000..4bfc5ec
--- /dev/null
@@ -0,0 +1,43 @@
+.. include:: ../../Includes.txt
+
+=========================================================
+Feature: #85991 - Exclude Symfony Commands from Scheduler
+=========================================================
+
+See :issue:`85991`
+
+Description
+===========
+
+TYPO3's Scheduler system extension added a feature to call a Symfony / command repeatedly, however
+it is very helpful if an extension author can decide to explicitly define a command to be
+"non-schedulable" like the installation of an extension or the listing of syslog information which
+act as helpers on the command line.
+
+This feature is the equivalent to Extbase's `@cli` annotation for command controllers, and thus
+finishes the Scheduler integration for Symfony commands in TYPO3.
+
+
+Impact
+======
+
+A registered Symfony command can now have a new option :php:`schedulable` which can be set to
+:php:`false` for commands that should only be executed specifically by TYPO3's CLI interface.
+
+The default value is :php:`true` which means that every Symfony command can be used in the Scheduler.
+
+An example file within :file:`EXT:myextension/Configuration/Commands.php` could look like this:
+
+.. code-block:: php
+
+   return [
+       'admins:delete' => [
+           'class' => \ACME\MyExtension\Command\DeleteAllAdministratorsCommand::class,
+           'schedulable' => false,
+       ]
+   ];
+
+The command could still be executed via :shell:`.../typo3 admins:delete` but not be set up as
+Scheduler task in the TYPO3 backend.
+
+.. index:: CLI, ext:scheduler
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-86001-RegularWorkspaceCleanupTasksAvailableViaCLICommands.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-86001-RegularWorkspaceCleanupTasksAvailableViaCLICommands.rst
new file mode 100644 (file)
index 0000000..12bcb1f
--- /dev/null
@@ -0,0 +1,30 @@
+.. include:: ../../Includes.txt
+
+============================================================================
+Feature: #86001 - Regular Workspace cleanup tasks available via CLI commands
+============================================================================
+
+See :issue:`86001`
+
+Description
+===========
+
+TYPO3 now supports two new symfony-based commands to trigger regular tasks, which were previously only
+available when the scheduler component was available.
+
+* typo3/sysext/core/bin/typo3 workspace:autopublish
+
+Checks for workspaces with auto-publishing configured and does a publishing/swapping process.
+
+* typo3/sysext/core/bin/typo3 cleanup:previewlinks
+
+Removes expired previewlinks stored within `sys_preview` from the database.
+
+
+Impact
+======
+
+It is possible to execute these commands from the CLI context without having to install the scheduler extension
+and to create a scheduler task for that.
+
+.. index:: CLI, ext:workspaces
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-86003-AdminpanelCompositionApi.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-86003-AdminpanelCompositionApi.rst
new file mode 100644 (file)
index 0000000..e638077
--- /dev/null
@@ -0,0 +1,520 @@
+.. include:: ../../Includes.txt
+
+==========================================================
+Feature: #86003 - Composition based API for the Adminpanel
+==========================================================
+
+See :issue:`86003`
+
+Description
+===========
+
+A new API to extend the adminpanel for extension authors has been introduced.
+Enabling future enhancements for the adminpanel without having to make breaking changes for existing module providers
+is a key ingredient for providing a future proof extensible solution. Using single big interfaces that need to change on
+updates break backwards compatibility and do not provide sufficient feature encapsulation.
+
+The adminpanel APIs have been refactored to use a composition pattern to allow modules more flexibility.
+Modules can now only implement the interfaces they need instead of implementing all functionality.
+For example an adminpanel module that only provides page related settings does no longer have to implement
+the :php:`getContent()` method.
+
+Small interfaces have been provided as building blocks for modules with rich functionality.
+Easy addition of new interfaces that _can_ (not must) be implemented allow future improvements.
+
+Additionally the API has been modified to allow a more object-oriented approach using simple DTOs instead
+of associative arrays for better type-hinting and a better developer experience. Storing and rendering data
+have been separated in two steps allowing to completely disconnect the rendered adminpanel from the current page.
+This can be used as a base for building a complete standalone adminpanel without API changes.
+
+General Request Flow and the Adminpanel
+=======================================
+
+To better understand how the adminpanel stores and renders data, let's take a short look at how the adminpanel
+is initialized and rendered.
+
+Since TYPO3 v9 TYPO3 uses PSR-15 middlewares. The adminpanel brings three that are relevant to its rendering process:
+
+- :php:`AdminPanelInitiator` - Called early in the request stack to allow initialisation of modules to catch
+most of the request data (for example log entries)
+- :php:`AdminPanelDataPersister` - Called at nearly the end of a frontend request to store the collected data
+(this is where module data gets saved)
+- :php:`AdminPanelRenderer` - Called as one of the last steps in the rendering process, currently replacing
+the closing body tag with its own code (this is where module content gets rendered)
+
+When building own modules keep in mind at which step your modules` methods get called.
+In the last step for example (the rendering), you should not depend on any data outside of
+that provided to the module directly (for example do not rely on :php:`$GLOBALS` to be filled).
+
+Current Design Considerations
+------------------------------
+
+While the API of the adminpanel is very flexible in combining interfaces, the UI has a fixed structure
+and therefor a few things to consider when implementing own modules.
+
+- The bottom bar of the adminpanel will only be rendered for modules that have submodules
+and implement the :php:`SubmoduleProviderInterface`
+- ShortInfo (see below) is only displayed for "TopLevel" modules
+- Content is only rendered for submodules
+
+
+How-To add own modules
+======================
+
+Adding custom adminpanel modules always follows these steps:
+
+1. Create a class implementing the basic :php:`ModuleInterface`
+2. Register the class in :file:`ext_localconf.php`
+3. Implement further interfaces for additional capabilities
+
+
+1. Create module class
+----------------------
+
+To create your own admin panel module, create a
+new PHP class implementing :php:`\TYPO3\CMS\Adminpanel\ModuleApi\ModuleInterface`.
+The interface denotes your class as an adminpanel module and requires the
+implementation of :php:`getIdentifier()` and :php:`getLabel()` as a minimum of methods for a module.
+
+2. Register your module
+------------------------
+
+Displayed as a top level module:
+++++++++++++++++++++++++++++++++
+
+Register your module by adding the following in your :file:`ext_localconf.php`::
+
+    $GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['adminpanel']['modules']['mynamespace_modulename'] => [
+        'module' => \Your\Namespace\Adminpanel\Modules\YourModule::class,
+        'before' => ['cache'],
+    ];
+
+via :php:`before` or :php:`after` you can influence where your module will be displayed in the module menu
+by referencing the identifier / array key of other modules.
+
+Displayed as a sub module:
+++++++++++++++++++++++++++
+
+Register your module by adding the following in your :file:`ext_localconf.php`::
+
+    $GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['adminpanel']['modules']['info']['submodules']['mynamespace_modulename'] => [
+        'module' => \Your\Namespace\Adminpanel\Modules\YourModule::class
+    ];
+
+Note the :php:`submodules` key in the array allowing you to introduce hierarchical configuration.
+
+
+3. Add additional interfaces
+----------------------------
+
+Your module is currently registered but is not doing anything yet, as it has no additional capabilities.
+The adminpanel provides additional separate interfaces (see list below).
+By implementing multiple interfaces you have fine-grained control over how your module behaves, which
+data it stores and how it gets rendered.
+
+Adminpanel Interfaces
+=====================
+
+ModuleInterface
+---------------
+
+Purpose
++++++++
+Base interface all adminpanel modules share, defines common methods.
+
+Methods
++++++++
+
+- :php:`getIdentifier()` - Returns :php:`string` identifier of a module (for example `mynamespace_modulename`)
+- :php:`getLabel()` - Returns speaking label of a module (for example `My Module`)
+
+
+ConfigurableInterface
+---------------------
+
+Purpose
++++++++
+Used to indicate that an adminpanel module can be enabled or disabled via configuration
+
+Methods
++++++++
+
+- :php:`isEnabled` - Returns :php:`bool` depending on whether the module is enabled.
+
+Example implementation
+++++++++++++++++++++++
+
+:php:`\TYPO3\CMS\Adminpanel\ModuleApi\AbstractModule::isEnabled()`::
+
+    /**
+     * Returns true if the module is
+     * -> either enabled via TSConfig admPanel.enable
+     * -> or any setting is overridden
+     * override is a way to use functionality of the admin panel without displaying the panel to users
+     * for example: hidden records or pages can be displayed by default
+     *
+     * @return bool
+     */
+    public function isEnabled(): bool
+    {
+        $identifier = $this->getIdentifier();
+        $result = $this->isEnabledViaTsConfig();
+        if ($this->mainConfiguration['override.'][$identifier] ?? false) {
+            $result = (bool)$this->mainConfiguration['override.'][$identifier];
+        }
+        return $result;
+    }
+
+
+
+ContentProviderInterface
+------------------------
+
+Purpose
++++++++
+Adminpanel interface to denote that a module has content to be rendered
+
+Methods
++++++++
+
+- :php:`getContent(ModuleData $data)` - Return content as HTML. For modules implementing the :php:`DataProviderInterface`
+the "ModuleData" object is automatically filled with the stored data - if no data is given a "fresh" ModuleData object is injected.
+
+Example implementation
+++++++++++++++++++++++
+
+:php:`\TYPO3\CMS\Adminpanel\Modules\Debug\QueryInformation::getContent`::
+
+    public function getContent(ModuleData $data): string
+    {
+        $view = new StandaloneView();
+        $view->setTemplatePathAndFilename(
+            'typo3/sysext/adminpanel/Resources/Private/Templates/Modules/Debug/QueryInformation.html'
+        );
+        $this->getLanguageService()->includeLLFile('EXT:adminpanel/Resources/Private/Language/locallang_debug.xlf');
+        $view->assignMultiple($data->getArrayCopy());
+        return $view->render();
+    }
+
+
+DataProviderInterface
+------------------------
+
+Purpose
++++++++
+Adminpanel interface to denote that a module provides data to be stored for the current request.
+
+Adminpanel modules can save data to the adminpanel request cache and access this data in the rendering process.
+Data necessary for rendering the module content has to be returned via this interface implementation, as this allows
+for separate data collection and rendering and is a pre-requisite for a standalone debug tool.
+
+Methods
++++++++
+
+- :php:`getDataToStore(ServerRequestInterface $request): ModuleData` - Return a `ModuleData` instance with the data to store
+
+Example implementation
+++++++++++++++++++++++
+
+:php:`\TYPO3\CMS\Adminpanel\Modules\Info\RequestInformation::getDataToStore`::
+
+    public function getDataToStore(ServerRequestInterface $request): ModuleData
+    {
+        return new ModuleData(
+            [
+                'post' => $_POST,
+                'get' => $_GET,
+                'cookie' => $_COOKIE,
+                'session' => $_SESSION,
+                'server' => $_SERVER,
+            ]
+        );
+    }
+
+InitializableInterface
+------------------------
+
+Purpose
++++++++
+
+Adminpanel interface to denote that a module has tasks to perform on initialization of the request.
+
+Modules that need to set data / options early in the rendering process to be able to collect data, should implement
+this interface - for example the log module uses the initialization to register the adminpanel log collection early
+in the rendering process.
+
+Initialize is called in the PSR-15 middleware stack through adminpanel initialisation via the AdminPanel MainController.
+
+Methods
++++++++
+
+- :php:`initializeModule(ServerRequestInterface $request)` - Called on adminpanel initialization
+
+Example implementation
+++++++++++++++++++++++
+
+:php:`\TYPO3\CMS\Adminpanel\Modules\CacheModule::initializeModule`::
+
+    public function initializeModule(ServerRequestInterface $request): void
+    {
+        if ($this->configurationService->getConfigurationOption('cache', 'noCache')) {
+            $this->getTypoScriptFrontendController()->set_no_cache('Admin Panel: No Caching', true);
+        }
+    }
+
+
+ModuleSettingsProviderInterface
+-------------------------------
+
+Purpose
++++++++
+
+Adminpanel module settings interface denotes that a module has own settings.
+
+The adminpanel knows two types of settings:
+- ModuleSettings are relevant for the module itself and its representation (for example the log module provides settings
+  where displayed log level and grouping of the module can be configured)
+- PageSettings are relevant for rendering the page (for example the preview module provides settings showing or hiding
+  hidden content elements or simulating a specific rendering time)
+
+If a module provides settings relevant to its own content, use this interface.
+
+Methods
++++++++
+
+- :php:`getSettings(): string` - Return settings as rendered HTML form elements
+
+Example implementation
+++++++++++++++++++++++
+
+:php:`\TYPO3\CMS\Adminpanel\Modules\TsDebug\TypoScriptWaterfall::getSettings`::
+
+    public function getSettings(): string
+    {
+        $view = GeneralUtility::makeInstance(StandaloneView::class);
+        $templateNameAndPath = 'EXT:adminpanel/Resources/Private/Templates/Modules/TsDebug/TypoScriptSettings.html';
+        $view->setTemplatePathAndFilename(GeneralUtility::getFileAbsFileName($templateNameAndPath));
+        $view->setPartialRootPaths(['EXT:adminpanel/Resources/Private/Partials']);
+
+        $view->assignMultiple(
+            [
+                'tree' => (int)$this->getConfigurationOption('tree'),
+                ...
+            ]
+        );
+
+        return $view->render();
+    }
+
+
+OnSubmitActorInterface
+-----------------------
+
+Purpose
++++++++
+
+Adminpanel interface for modules that need to react on changed configuration
+(for example if fluid debug settings change, the frontend cache should be cleared).
+
+OnSubmitActors are currently called upon persisting new configuration _before_ the page is reloaded.
+
+Methods
++++++++
+
+- :php:`onSubmit(array $configurationToSave, ServerRequestInterface $request)` - Can act when configuration gets saved.
+Configuration form vars are provided in :php:`$configurationToSave` as an array.
+
+Example implementation
+++++++++++++++++++++++
+
+:php:`\TYPO3\CMS\Adminpanel\Modules\PreviewModule::onSubmit`::
+
+    /**
+     * Clear page cache if fluid debug output setting is changed
+     *
+     * @param array $input
+     * @param ServerRequestInterface $request
+     * @throws \TYPO3\CMS\Core\Cache\Exception\NoSuchCacheException
+     */
+    public function onSubmit(array $input, ServerRequestInterface $request): void
+    {
+        $activeConfiguration = (int)$this->getConfigOptionForModule('showFluidDebug');
+        if (isset($input['preview_showFluidDebug']) && (int)$input['preview_showFluidDebug'] !== $activeConfiguration) {
+            $pageId = (int)$request->getParsedBody()['TSFE_ADMIN_PANEL']['preview_clearCacheId'];
+            $cacheManager = GeneralUtility::makeInstance(CacheManager::class);
+            $cacheManager->getCache('cache_pages')->flushByTag('pageId_' . $pageId);
+            $cacheManager->getCache('fluid_template')->flush();
+        }
+    }
+
+
+
+PageSettingsProviderInterface
+-----------------------------
+
+Purpose
++++++++
+
+Adminpanel page settings interface denotes that a module has settings regarding the page rendering.
+
+The adminpanel knows two types of settings:
+- ModuleSettings are relevant for the module itself and its representation (for example the log module provides settings
+  where displayed log level and grouping of the module can be configured)
+- PageSettings are relevant for rendering the page (for example the preview module provides settings showing or hiding
+  hidden content elements or simulating a specific rendering time)
+
+If a module provides settings changing the rendering of the main page request, use this interface.
+
+Methods
++++++++
+
+- :php:`getSettings(): string` - Return HTML form elements for settings
+
+Example implementation
+++++++++++++++++++++++
+
+:php:`\TYPO3\CMS\Adminpanel\Modules\EditModule::getPageSettings`::
+
+    public function getPageSettings(): string
+    {
+        $editToolbarService = GeneralUtility::makeInstance(EditToolbarService::class);
+        $toolbar = $editToolbarService->createToolbar();
+        $view = GeneralUtility::makeInstance(StandaloneView::class);
+        $templateNameAndPath = 'EXT:adminpanel/Resources/Private/Templates/Modules/Settings/Edit.html';
+        $view->setTemplatePathAndFilename(GeneralUtility::getFileAbsFileName($templateNameAndPath));
+        $view->setPartialRootPaths(['EXT:adminpanel/Resources/Private/Partials']);
+        $view->assignMultiple(
+            [
+                'feEdit' => ExtensionManagementUtility::isLoaded('feedit'),
+                ...
+            ]
+        );
+        return $view->render();
+
+
+PageSettingsProviderInterface
+-----------------------------
+
+Purpose
++++++++
+
+Adminpanel interface to denote that a module has own resource files.
+
+An adminpanel module implementing this interface may deliver custom JavaScript and Css files to provide additional
+styling and JavaScript functionality
+
+Methods
++++++++
+
+- :php:`getJavaScriptFiles(): array` - Returns a string array with javascript files that will be rendered after the module
+- :php:`getCssFiles(): array` - Returns a string array with CSS files that will be rendered after the module
+
+Example implementation
+++++++++++++++++++++++
+
+:php:`\TYPO3\CMS\Adminpanel\Modules\TsDebugModule`::
+
+    public function getJavaScriptFiles(): array
+    {
+        return ['EXT:adminpanel/Resources/Public/JavaScript/Modules/TsDebug.js'];
+    }
+
+    public function getCssFiles(): array
+    {
+        return [];
+    }
+
+
+ShortInfoProviderInterface
+-----------------------------
+
+Purpose
++++++++
+
+Adminpanel shortinfo provider interface can be used to add the module to the short info bar of the adminpanel.
+
+Modules providing shortinfo will be displayed in the bottom bar of the adminpanel and may provide "at a glance" info
+about the current state (for example the log module provides the number of warnings and errors directly).
+
+Be aware that modules with submodules at the moment can only render one short info (the one of the "parent" module).
+This will likely change in v10.
+
+Methods
++++++++
+
+- :php:`getShortInfo(): string` - Info string (no HTML) that should be rendered
+- :php:`getIconIdentifier(): string` - An icon for this info line, needs to be registered in :php:`IconRegistry`
+
+Example implementation
+++++++++++++++++++++++
+
+:php:`\TYPO3\CMS\Adminpanel\Modules\InfoModule`::
+
+    public function getShortInfo(): string
+    {
+        $parseTime = $this->getTimeTracker()->getParseTime();
+        return sprintf($this->getLanguageService()->sL(
+            'LLL:EXT:adminpanel/Resources/Private/Language/locallang_info.xlf:module.shortinfo'
+        ), $parseTime);
+    }
+
+    public function getIconIdentifier(): string
+    {
+        return 'actions-document-info';
+    }
+
+
+
+SubmoduleProviderInterface
+-----------------------------
+
+Purpose
++++++++
+
+ Adminpanel interface providing hierarchical functionality for modules.
+
+ A module implementing this interface may have submodules. Be aware that the current implementation of the adminpanel
+ renders a maximum level of 2 for modules. If you need to render more levels, write your own module and implement
+ multi-hierarchical rendering in the getContent method.
+
+Methods
++++++++
+
+- :php:`setSubModules(array $subModules)` - Sets array of module instances (instances of :php:`ModuleInterface`) as submodules
+- :php:`getSubModules(): array` - Returns an array of module instances
+- :php:`hasSubmoduleSettings(): bool` - Return true if any of the submodules has settings to be rendered
+(can be used to render settings in a central place)
+
+Example implementation
+++++++++++++++++++++++
+
+:php:`\TYPO3\CMS\Adminpanel\ModuleApi\AbstractModule`::
+
+
+    public function setSubModules(array $subModules): void
+    {
+        $this->subModules = $subModules;
+    }
+
+    public function getSubModules(): array
+    {
+        return $this->subModules;
+    }
+
+    public function hasSubmoduleSettings(): bool
+    {
+        $hasSettings = false;
+        foreach ($this->subModules as $subModule) {
+            if ($subModule instanceof ModuleSettingsProviderInterface) {
+                $hasSettings = true;
+                break;
+            }
+            if ($subModule instanceof SubmoduleProviderInterface) {
+                $hasSettings = $subModule->hasSubmoduleSettings();
+            }
+        }
+        return $hasSettings;
+    }
+
+
+.. index:: Frontend, PHP-API, ext:adminpanel
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-86051-ShowExtensionsViaCLI.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-86051-ShowExtensionsViaCLI.rst
new file mode 100644 (file)
index 0000000..2f422d5
--- /dev/null
@@ -0,0 +1,28 @@
+.. include:: ../../Includes.txt
+
+=========================================
+Feature: #86051 - Show extensions via CLI
+=========================================
+
+See :issue:`86051`
+
+Description
+===========
+
+A new command :shell:`extension:list` is added, which can be executed via Command Line
+:shell:`typo3/sysext/core/bin/typo3 extension:list`.
+
+This command shows all currently installed (= active) extensions. The option :shell:`--all`
+also includes all inactive extensions. If the list of inactive extensions should
+be shown, the command :shell:`--inactive` will show only the extensions available for installation.
+
+Additional description of the extensions can be shown by :shell:`--verbose` / :shell:`-v`.
+
+
+Impact
+======
+
+In order to show which extensions can be uninstalled or installed via CLI, the new command
+is a good companion for the existing commands :shell:`extension:activate` and :shell:`extension:deactivate`.
+
+.. index:: CLI, ext:core
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Feature-86066-CLICommandsForListingAndShowingSites.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Feature-86066-CLICommandsForListingAndShowingSites.rst
new file mode 100644 (file)
index 0000000..90c71fa
--- /dev/null
@@ -0,0 +1,30 @@
+.. include:: ../../Includes.txt
+
+============================================================
+Feature: #86066 - CLI Commands for listing and showing sites
+============================================================
+
+See :issue:`86066`
+
+Description
+===========
+
+Two new CLI commands have been added:
+-  :shell:`site:list`
+-  :shell:`site:show`
+
+The list command can be executed via :shell:`typo3/sysext/core/bin/typo3 site:list` and will list all
+configured sites with their configured Identifier, root page, base URL, languages, locales and
+a flag whether or not the site is enabled.
+
+The show command can be executed via :shell:`typo3/sysext/core/bin/typo3 site:show <identifier>`.
+It needs an identifier of a configured site which must be provided after the command name.
+The command will output the complete configuration for the site in the YAML syntax.
+
+
+Impact
+======
+
+Reading access to the configured sites and their detailed configuration is now possible from CLI.
+
+.. index:: CLI, ext:core
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Important-84280-UnitTestSuppressNoticesRemoved.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Important-84280-UnitTestSuppressNoticesRemoved.rst
new file mode 100644 (file)
index 0000000..1ac8935
--- /dev/null
@@ -0,0 +1,22 @@
+.. include:: ../../Includes.txt
+
+=====================================================
+Important: #84280 - Unit test suppressNotices removed
+=====================================================
+
+See :issue:`84280`
+
+Description
+===========
+
+The property :php:`$suppressNotices` available for unit tests extending class
+:php:`UnitTestCase` has been removed. Unit tests that trigger :php:`E_NOTICE`
+level errors will now fail.
+
+The property has been introduced with core v9.2 and has been removed with v9.4
+after no core unit tests used that flag anymore.
+
+If extensions use the typo3/testing-framework for testing, they now may have
+to fix their tests or system under test to not throw notices, either.
+
+.. index:: PHP-API, FullyScanned
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Important-84623-ConfigurationFilesMovedFromTypo3confToConfigDirectory.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Important-84623-ConfigurationFilesMovedFromTypo3confToConfigDirectory.rst
new file mode 100644 (file)
index 0000000..9ce2046
--- /dev/null
@@ -0,0 +1,38 @@
+.. include:: ../../Includes.txt
+
+====================================================================================
+Important: #84623 - Configuration files moved from "typo3conf" to "config" directory
+====================================================================================
+
+See :issue:`84623`
+
+Description
+===========
+
+The TYPO3 configuration files for instances running in Composer Mode or having the environment
+variable `TYPO3_PATH_APP` set to a different location than :php:`PATH_site`, have been moved from
+the :file:`<web-dir>/typo3conf` to the :file:`config` directory.
+
+The following files are affected:
+
+- :file:`LocalConfiguration.php`
+- :file:`AdditionalConfiguration.php`
+- :file:`AdditionalFactoryConfiguration.php`
+
+The first access to the TYPO3 frontend or backend will redirect to the Install Tool which
+automatically creates the :file:`config` directory and moves all of the affected files currently
+present in :file:`<web-dir>/typo3conf` to :file:`config`. Afterwards backend and frontend are
+accessible as usual.
+
+Using the environment variable `TYPO3_PATH_APP` allows for storing relevant code like configuration
+outside of the document root / Composer `<web-dir>`. This effectively hardens a TYPO3 instance,
+as less files are accessible in public. All new installations in Composer Mode use this setup by
+default. Installations in Classic Mode (without Composer setup) will continue to use the previous
+setup since it cannot be ensured that they have access outside of the document root.
+
+If you have a setup with a :php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['trustedHostsPattern']` set, please
+go to the install tool first. The migration is done automatically and you can just go to the backend
+afterwards. If you have not set your trustedHostsPattern, you will be redirected automatically and
+you don't have to do anything.
+
+.. index:: LocalConfiguration
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Important-85196-RemovedSimulateUserFromUserSettings.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Important-85196-RemovedSimulateUserFromUserSettings.rst
new file mode 100644 (file)
index 0000000..4fbc2e0
--- /dev/null
@@ -0,0 +1,27 @@
+.. include:: ../../Includes.txt
+
+============================================================
+Important: #85196 - Removed simulate user from user settings
+============================================================
+
+See :issue:`85196`
+
+Description
+===========
+
+The user settings module that can be reached from the backend toolbar in
+the drop down behind the logged in user name had a functionality to
+show user settings of another backend user for admins.
+
+This simulate user switch has been dropped from the interface.
+
+Admins who want to check or change settings of other users should fully
+switch to the target user using the "Switch to user" of the "Backend users"
+module and then navigate to its user settings.
+
+Backend administrators who often need to change other backend user settings
+should consider using adapted User TSconfig :ts:`setup.` details to
+streamline this workflow.
+
+
+.. index:: Backend, ext:setup
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Important-85393-ExtensionManagerOnlyImportsExtensionsCompatibleWithTYPO3V7LTSOrHigher.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Important-85393-ExtensionManagerOnlyImportsExtensionsCompatibleWithTYPO3V7LTSOrHigher.rst
new file mode 100644 (file)
index 0000000..8c8f2cb
--- /dev/null
@@ -0,0 +1,23 @@
+.. include:: ../../Includes.txt
+
+====================================================================================================
+Important: #85393 - Extension Manager only imports extensions compatible with TYPO3 v7 LTS or higher
+====================================================================================================
+
+See :issue:`85393`
+
+Description
+===========
+
+The extension manager now includes a restriction when updating the list of current extensions
+within TER that have been uploaded later than November 10th, 2015 - the release of
+TYPO3 v7 LTS (7.6.0).
+
+This ensures that the database is drastically reduced, resulting in smaller footprint for the
+database and faster updating / searching / browsing the list of available extensions within the
+Extension Manager.
+
+Installing extensions older than this date is still possible by manually downloading an extension
+and importing it via a ZIP file or by uploading it into :file:`typo3conf/ext/[extension_name]`.
+
+.. index:: ext:extensionmanager
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Important-85683-DroppedSaltedpasswordOptions.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Important-85683-DroppedSaltedpasswordOptions.rst
new file mode 100644 (file)
index 0000000..0a45959
--- /dev/null
@@ -0,0 +1,40 @@
+.. include:: ../../Includes.txt
+
+====================================================
+Important: #85683 - Dropped salted passwords options
+====================================================
+
+See :issue:`85683`
+
+Description
+===========
+
+Some extension configuration of the salted passwords extension has been dropped:
+
+- FE.forceSalted and BE.forceSalted
+  By explicitly setting forceSalted to 1 (default 0) in the saltedpasswords extension configuration it was possible to
+  deny login of users who had not stored their password as salted password yet. This option has been removed.
+  User who have been upgraded to salted passwords using the "Convert user passwords to salted hashes" from
+  core version 8 are still able to login and will get their passwords updated to the configured salted password
+  mechanism upon first successful login. This upgrade will be dropped in TYPO3 v10. Other non salted passwords
+  mechanisms (simple md5 or plaintext) will however lead to a failed login. Administrators who did not yet upgrade
+  their user base to salted passwords must perform the "Convert user passwords to salted hashes" in TYPO3 v7
+  or TYPO3 v8 before upgrading to TYPO3 v9.
+
+- FE.updatePasswd and BE.updatePasswd
+  By explicitly setting updatePasswd to 0 (default 1) in the saltedpasswords extension configuration it was possible
+  to avoid updating a given hashed password to the currently configured hash algorithm, but still allow login. This option has
+  been dropped: A user submitting a valid password using an old salted passwords algorithm that is no longer configured
+  as current salted passwords algorithm will always get his password updated and stored using the currently
+  configured password salt.
+
+- FE.onlyAuthService and BE.onlyAuthService
+  By explicitly setting onlyAuthService to 1 (default 0), it was possible to deny any further authentication service
+  to successfully validate a user. This setting is mostly useless since any different authentication service is usually
+  configured to kick in before the native TYPO3 internal authentication service. It does not make sense to have this toggle
+  and a search in open extensions revealed no usage. On upgrading to v9, if you are running additional authentication services,
+  please verify those have a higher priority than the default :php:`SaltedPasswordService`, action is only needed if
+  additionally onlyAuthService has been set to 1 in salted passwords configuration, which is probably never the case.
+
+
+.. index:: Backend, Database, Frontend, ext:saltedpasswords
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Important-85719-PHPPackagesSymfonyComponentsRequirementsRaisedToSymfony41.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Important-85719-PHPPackagesSymfonyComponentsRequirementsRaisedToSymfony41.rst
new file mode 100644 (file)
index 0000000..38e8d8a
--- /dev/null
@@ -0,0 +1,33 @@
+.. include:: ../../Includes.txt
+
+=======================================================================================
+Important: #85719 - PHP Packages: Symfony Components requirements raised to Symfony 4.1
+=======================================================================================
+
+See :issue:`85719`
+
+Description
+===========
+
+Due to the introduction of the PHP requirement of `symfony/routing` with a minimum requirement of
+version 4.1, all other Symfony Components have been raised to have at least 4.1 as well.
+
+This includes the following symfony components:
+* symfony/finder
+* symfony/console
+* symfony/yaml
+* symfony/expression-language
+
+The package `symfony/routing` is a must-have for TYPO3 for Route Matching,
+which has been heavily improved in version 4.1 performance-wise. As TYPO3 should have the best experience
+with routing, it is critical to use at least 4.1, and no version lower than that.
+
+If a composer-based TYPO3 installation depends on a package that is not compatible with
+symfony components lower than 4.1, it is not possible to upgrade TYPO3 to v9.4 without fixing other
+requirements.
+
+In this case, evaluate if other third-party packages can be upgraded to be compatible with
+Symfony 4.1 components and require newer versions of these packages, or open up a support ticket
+in the respective package project website to ensure compatibility with newer symfony versions.
+
+.. index:: PHP-API
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Important-85833-SaltedpasswordsExtensionMergedIntoCoreExtension.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Important-85833-SaltedpasswordsExtensionMergedIntoCoreExtension.rst
new file mode 100644 (file)
index 0000000..12a3549
--- /dev/null
@@ -0,0 +1,34 @@
+.. include:: ../../Includes.txt
+
+========================================================================
+Important: #85833 - saltedpasswords extension merged into core extension
+========================================================================
+
+See :issue:`85833`
+
+Description
+===========
+
+The previously available system extension `saltedpasswords` has been removed as its
+functionality has been merged into `core`. All functionality is still available but
+renamed related to a better Hashing API.
+
+This resolves a hard cross-dependency between `EXT:core` and `EXT:saltedpasswords`
+since TYPO3 v6 as it was a sane default to properly use password hashes.
+
+Backwards compatibility is given by automatic upgrades of settings when visiting
+the Install Tool.
+
+For composer-based installations this means the dependency to `typo3/cms-saltedpasswords`
+can safely be removed via :shell:`composer remove typo3/cms-saltedpasswords`, although this is
+not mandatory due to the fact that `typo3/cms-core` is noted as a replacement for
+saltedpasswords in its :file:`composer.json` file.
+
+In some edge-cases for non-composer-based installations it might be necessary to remove
+the `saltedpasswords` entry from :php:`typo3conf/PackagesStates.php`.
+
+Any checks for :php:`ExtensionManagementUtility::isLoaded('saltedpasswords')` in
+third-party extensions which were not necessary (as saltedpasswords had to be installed
+at any time anyways), can safely be removed.
+
+.. index:: Backend, NotScanned, ext:saltedpasswords
diff --git a/typo3/sysext/core/Documentation/Changelog/9.4/Index.rst b/typo3/sysext/core/Documentation/Changelog/9.4/Index.rst
new file mode 100644 (file)
index 0000000..b2db830
--- /dev/null
@@ -0,0 +1,51 @@
+
+.. include:: ../../Includes.txt
+
+9.4 Changes
+===========
+
+**Table of contents**
+
+.. contents::
+   :local:
+   :depth: 1
+
+Breaking Changes
+^^^^^^^^^^^^^^^^
+
+.. toctree::
+   :maxdepth: 1
+   :titlesonly:
+   :glob:
+
+   Breaking-*
+
+Features
+^^^^^^^^
+
+.. toctree::
+   :maxdepth: 1
+   :titlesonly:
+   :glob:
+
+   Feature-*
+
+Deprecation
+^^^^^^^^^^^
+
+.. toctree::
+   :maxdepth: 1
+   :titlesonly:
+   :glob:
+
+   Deprecation-*
+
+Important
+^^^^^^^^^
+
+.. toctree::
+   :maxdepth: 1
+   :titlesonly:
+   :glob:
+
+   Important-*
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Deprecation-85678-ConfigTitleTagFunction.rst b/typo3/sysext/core/Documentation/Changelog/master/Deprecation-85678-ConfigTitleTagFunction.rst
deleted file mode 100644 (file)
index 1eef2b5..0000000
+++ /dev/null
@@ -1,32 +0,0 @@
-.. include:: ../../Includes.txt
-
-=============================================
-Deprecation: #85678 - config.titleTagFunction
-=============================================
-
-See :issue:`85678`
-
-Description
-===========
-
-The TypoScript option :ts:`config.titleTagFunction` has been marked as deprecated and will be removed with TYPO3 v10.
-
-
-Impact
-======
-
-Installations using the option will trigger a PHP :php:`E_USER_DEPRECATED` error.
-
-
-Affected Installations
-======================
-
-Instances using the option.
-
-
-Migration
-=========
-
-Please use the new TitleTag API to alter the title tag.
-
-.. index:: TypoScript, NotScanned
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Deprecation-85678-TsfeAltPageTitle.rst b/typo3/sysext/core/Documentation/Changelog/master/Deprecation-85678-TsfeAltPageTitle.rst
deleted file mode 100644 (file)
index db1fab2..0000000
+++ /dev/null
@@ -1,32 +0,0 @@
-.. include:: ../../Includes.txt
-
-====================================================
-Deprecation: #85678 - $GLOBALS['TSFE']->altPageTitle
-====================================================
-
-See :issue:`85678`
-
-Description
-===========
-
-The PHP property :php:`$GLOBALS['TSFE']->altPageTitle` has been marked as deprecated and will be removed with TYPO3 v10.
-
-
-Impact
-======
-
-Installations using this property will trigger a PHP :php:`E_USER_DEPRECATED` error.
-
-
-Affected Installations
-======================
-
-Instances using the property.
-
-
-Migration
-=========
-
-Please use the new TitleTag API to alter the title tag.
-
-.. index:: TypoScript, NotScanned
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-13265-MakeFirstOptionToolbarOpenByDefaultInThePageTree.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-13265-MakeFirstOptionToolbarOpenByDefaultInThePageTree.rst
deleted file mode 100644 (file)
index 9083d57..0000000
+++ /dev/null
@@ -1,21 +0,0 @@
-.. include:: ../../Includes.txt
-
-============================================================================
-Feature: #13265 - Select first element of PageTree toolbar on initialization
-============================================================================
-
-See :issue:`13265`
-
-Description
-===========
-
-The first element of the PageTree toolbar is now selected when initialized. The possibility to
-close/hide a toolbar option has been removed. Either the page type or the filter/search is displayed.
-
-
-Impact
-======
-
-The user always sees an open element of the PageTree toolbar.
-
-.. index:: Backend, JavaScript, ext:backend
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-44297-IntervalPresetsForCronCommandOfSchedulerTask.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-44297-IntervalPresetsForCronCommandOfSchedulerTask.rst
deleted file mode 100644 (file)
index 97f6bc9..0000000
+++ /dev/null
@@ -1,25 +0,0 @@
-.. include:: ../../Includes.txt
-
-=====================================================================
-Feature: #44297 - Interval presets for cron command of scheduler task
-=====================================================================
-
-See :issue:`44297`
-
-Description
-===========
-
-To support administrators creating scheduler tasks, presets have been added to the frequency field.
-
-The default presets are:
-
-.. code-block:: php
-
-       $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['scheduler']['frequencyOptions'] = [
-               '0 9,15 * * 1-5' => 'LLL:EXT:scheduler/Resources/Private/Language/locallang.xlf:command.example1',
-               '0 */2 * * *' =>  'LLL:EXT:scheduler/Resources/Private/Language/locallang.xlf:command.example2',
-               '*/20 * * * *' =>  'LLL:EXT:scheduler/Resources/Private/Language/locallang.xlf:command.example3',
-               '0 7 * * 2' =>  'LLL:EXT:scheduler/Resources/Private/Language/locallang.xlf:command.example4',
-];
-
-.. index:: Backend, ext:scheduler
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-57331-SupportMdashInCurrencyViewHelper.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-57331-SupportMdashInCurrencyViewHelper.rst
deleted file mode 100644 (file)
index 67f97f7..0000000
+++ /dev/null
@@ -1,27 +0,0 @@
-.. include:: ../../Includes.txt
-
-=====================================================
-Feature: #57331 - Support dash in CurrencyViewHelper
-=====================================================
-
-See :issue:`57331`
-
-Description
-===========
-
-The `useDash` option is added to the CurrencyViewHelper.
-
-
-Impact
-======
-
-If the option `useDash` is set and a round value is given, the decimal place is rendered as a dash.
-
-Example:
-
-.. code-block:: html
-
-       <!-- Renders "54321.-" -->
-       <f:format.currency useDash="1">54321.00</f:format.currency>
-
-.. index:: Fluid, ext:fluid
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-83476-LoadMergedJSFilesAsynchronous.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-83476-LoadMergedJSFilesAsynchronous.rst
deleted file mode 100644 (file)
index da24a12..0000000
+++ /dev/null
@@ -1,30 +0,0 @@
-.. include:: ../../Includes.txt
-
-===================================================
-Feature: #83476 - Load merged JS files asynchronous
-===================================================
-
-See :issue:`83476`
-
-Description
-===========
-
-The async attribute is now assigned to the script tag of the concatenated JS files if all files have the async attribute enabled in TypoScript.
-
-Example:
---------
-
-.. code-block:: typoscript
-
-   config.concatenateJs = 1
-
-   page = PAGE
-   page.includeJSFooter {
-       test = fileadmin/user_upload/test.js
-       test.async = 1
-
-       test2 = fileadmin/user_upload/test2.js
-       test2.async = 1
-   }
-
-.. index:: Frontend, TypoScript, ext:core
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-83749-FilteringAndPaginationInTheRedirectsModule.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-83749-FilteringAndPaginationInTheRedirectsModule.rst
deleted file mode 100644 (file)
index 16768e8..0000000
+++ /dev/null
@@ -1,35 +0,0 @@
-.. include:: ../../Includes.txt
-
-==================================================================
-Feature: #83749 - Filtering and Pagination in the redirects module
-==================================================================
-
-See :issue:`83749`
-
-Description
-===========
-
-The backend module "Redirects" received filtering and pagination to improve the overall usability.
-
-The list of redirects can be filtered by:
-- The source host
-- The source path
-- The destination (either the path or the Page ID)
-- The target status code
-
-All filters are concatenated by a logical AND.
-
-Pagination is set to 50 records per page.
-
-Some minor usability Improvements have been made as well:
-- The source path now crops after 100 characters to keep the table from expanding too much
-- The destination column now also shows the Page ID if the target is a page
-- Redirects are now sorted by source host (1st) and source path (2nd)
-
-
-Impact
-======
-
-With these improvements it is now possible to easily manage a big amount of redirect records.
-
-.. index:: Backend, ext:redirects
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-84133-IntroduceVariants.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-84133-IntroduceVariants.rst
deleted file mode 100644 (file)
index 5e67cf5..0000000
+++ /dev/null
@@ -1,490 +0,0 @@
-.. include:: ../../Includes.txt
-
-====================================
-Feature: #84133 - Introduce variants
-====================================
-
-See :issue:`84133`
-
-Description
-===========
-
-
-Short Description
------------------
-
-Variants allow you to change properties of a form element and can be activated based on conditions.
-
-This makes it possible to manipulate form element properties, validator options, and finisher options based on conditions.
-
-This allows you among other things:
-
-* translate form element values depending on the frontend language
-* set and remove validators of one form element depending on the value of another form element
-* hide entire steps (form pages) depending on the value of a form element
-* set finisher options depending on the value of a form element
-* hiding a form element in certain finishers and on the summary step
-
-This feature implements variants for frontend rendering and the ability to define variants in form definitions.
-The implementation to define variants graphically in the form editor is out of scope of this patchset.
-
-
-Basics
-------
-
-Variants allow you to change properties of form elements, validators, and finishers and are activated by conditions.
-They are defined on the form element level either statically in form definitions or created programmatically through an API.
-
-The variants defined within a form definition are automatically applied to the form based on their conditions at runtime.
-Programmatically, variants can be applied at any time.
-
-Furthermore, the conditions of a variant can be evaluated programmatically at any time. However, some conditions are only
-available at runtime, for example a check for a form element value.
-
-Custom conditions and operators can be added easily.
-
-Only the form element properties listed in a variant are applied to the form element, all other properties are retained.
-An exception to this rule are finishers and validators. If finishers or validators are **not** defined within a variant, the
-original finishers and validators will be used. If at least one finisher or validator is defined in a variant, the
-originally defined finishers or validators are overwritten by the list of finishers and validators of the variant.
-
-Variants defined within a form definition are **all** processed and applied in the order of their condition matches. This means
-if variant 1 sets the label of a form element to "X" and variant 2 sets the label to "Y", then variant 2 is applied, i.e. the label
-will be "Y".
-
-
-Variants definition
--------------------
-
-Variants are defined on the form element level. Check the following - incomplete - example:
-
-.. code-block:: yaml
-
-    type: Text
-    identifier: text-1
-    label: ''
-    variants:
-      -
-        identifier: variant-1
-        condition: 'formValues["checkbox-1"] == 1'
-        # If the condition matches, the label property of the form element is set to the value 'foo'
-        label: foo
-
-
-As usual :yaml:`identifier` must be a unique name of the variant on the form element level.
-
-Each variant has a single :yaml:`condition` which lets the variants' changes get applied if it matches.
-
-If the :yaml:`condition` of a variant matches, the remaining properties are applied to the form element. In the
-aforementioned example the label of the form element :yaml:`text-1` is changed to ``foo`` if the checkbox
-:yaml:`checkbox-1` is checked.
-
-The following properties can be overwritten by variants within the topmost element (:yaml:`Form`):
-
-* :yaml:`label`
-* :yaml:`renderingOptions`
-* :yaml:`finishers`
-* :yaml:`rendererClassName`
-
-The following properties can be overwritten by variants within all of the other form elements:
-
-* :yaml:`enabled`
-* :yaml:`label`
-* :yaml:`defaultValue`
-* :yaml:`properties`
-* :yaml:`renderingOptions`
-* :yaml:`validators`
-
-
-Conditions
-----------
-
-The form framework uses the Symfony component `expression language` to match the conditions. (@see https://symfony.com/doc/4.1/components/expression_language.html)
-An expression is a one-liner that returns a boolean value like :yaml:`applicationContext matches "#Production/Local#"`.
-Please read https://symfony.com/doc/4.1/components/expression_language/syntax.html to learn more about this topic.
-The form framework extends the expression language with some variables which can be used to access form values and environment settings.
-
-
-``formRuntime`` (object)
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-You can access every public method from the :php:`\TYPO3\CMS\Form\Domain\Runtime\FormRuntime` (@see https://docs.typo3.org/typo3cms/extensions/form/ApiReference/Index.html#typo3-cms-form-domain-model-formruntime).
-
-Example
-'''''''
-
-:yaml:`formRuntime.getIdentifier() == "test"`.
-
-
-``formValues`` (array)
-^^^^^^^^^^^^^^^^^^^^^^
-
-:yaml:`formValues` holds all of the submitted form element values. Each key within this array represents a form element identifier.
-
-Example
-'''''''
-
-:yaml:`formValues["text-1"] == "yes"`.
-
-
-``stepIdentifier`` (string)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-:yaml:`stepIdentifier` is set to the :yaml:`identifier` of the current step.
-
-Example
-'''''''
-
-:yaml:`stepIdentifier == "page-1"`.
-
-
-``stepType`` (string)
-^^^^^^^^^^^^^^^^^^^^^
-
-:yaml:`stepType` is set to the :yaml:`type` of the current step.
-
-Example
-'''''''
-
-:yaml:`stepType == "SummaryPage"`.
-
-
-``finisherIdentifier`` (string)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-:yaml:`finisherIdentifier` is set to the :yaml:`identifier` of the current finisher or an empty string (while no finishers are executed).
-
-Example
-'''''''
-
-:yaml:`finisherIdentifier == "EmailToSender"`.
-
-
-``siteLanguage`` (object)
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-You can access every public method from :php:`\TYPO3\CMS\Core\Site\Entity\SiteLanguage`.
-The most needed ones are probably:
-
-* getLanguageId() / Aka sys_language_uid.
-* getLocale() / The language locale. Something like 'en_US.UTF-8'.
-* getTypo3Language() / The language key for XLF files. Something like 'de' or 'default'.
-* getTwoLetterIsoCode() / Returns the ISO-639-1 language ISO code. Something like 'de'.
-
-Example
-'''''''
-
-:yaml:`siteLanguage.getLocale() == "de_DE"`.
-
-
-``applicationContext`` (string)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-:yaml:`applicationContext` is set to the application context (@see GeneralUtility::getApplicationContext()).
-
-Example
-'''''''
-
-:yaml:`applicationContext matches "#Production/Local#"`.
-
-
-``contentObject`` (array)
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-:yaml:`contentObject` is set to the data of the current content object or to an empty array if no content object is available.
-
-Example
-'''''''
-
-:yaml:`contentObject["pid"] in [23, 42]`.
-
-
-Working with variants programmatically
---------------------------------------
-
-Create a variant with conditions through the PHP API:
-
-.. code-block:: php
-
-    /** @var TYPO3\CMS\Form\Domain\Model\Renderable\RenderableVariantInterface $variant */
-    $variant = $formElement->createVariant([
-        'identifier' => 'variant-1',
-        'condition' => 'formValues["checkbox-1"] == 1',
-        'label' => 'foo',
-    ]);
-
-Get all variants of a form element:
-
-.. code-block:: php
-
-    /** @var TYPO3\CMS\Form\Domain\Model\Renderable\RenderableVariantInterface[] $variants */
-    $variants = $formElement->getVariants();
-
-Apply a variant to a form element regardless of its defined conditions:
-
-.. code-block:: php
-
-    $formElement->applyVariant($variant);
-
-
-Examples
---------
-
-Translate form element values depending on the frontend language:
-
-.. code-block:: yaml
-
-    type: Form
-    identifier: test
-    prototypeName: standard
-    label: DE
-    renderingOptions:
-      submitButtonLabel: Abschicken
-    variants:
-      -
-        identifier: language-variant-1
-        condition: 'siteLanguage.getLocale() == "en_US.UTF-8"'
-        label: EN
-        renderingOptions:
-          submitButtonLabel: Submit
-    renderables:
-      -
-        type: Page
-        identifier: page-1
-        label: DE
-        renderingOptions:
-          previousButtonLabel: 'zurück'
-          nextButtonLabel: 'weiter'
-        variants:
-          -
-            identifier: language-variant-1
-            condition: 'siteLanguage.getLocale() == "en_US.UTF-8"'
-            label: EN
-            renderingOptions:
-              previousButtonLabel: 'Previous step'
-              nextButtonLabel: 'Next step'
-        renderables:
-          -
-            type: Text
-            identifier: text-1
-            label: DE
-            properties:
-              fluidAdditionalAttributes:
-                placeholder: Platzhalter
-            variants:
-              -
-                identifier: language-variant-1
-                condition: 'siteLanguage.getLocale() == "en_US.UTF-8"'
-                label: EN
-                properties:
-                  fluidAdditionalAttributes:
-                    placeholder: Placeholder
-
-Set validators of one form element depending on the value of another form element:
-
-.. code-block:: yaml
-
-
-    type: Form
-    identifier: test
-    label: test
-    prototypeName: standard
-    renderables:
-      -
-        type: Page
-        identifier: page-1
-        label: Step
-        renderables:
-          -
-            defaultValue: ''
-            type: Text
-            identifier: text-1
-            label: 'Email address'
-            variants:
-              -
-                identifier: variant-1
-                condition: 'formValues["checkbox-1"] == 1'
-                properties:
-                  fluidAdditionalAttributes:
-                    required: 'required'
-                validators:
-                  -
-                    identifier: NotEmpty
-                  -
-                    identifier: EmailAddress
-          -
-            type: Checkbox
-            identifier: checkbox-1
-            label: 'Subscribe to newsletter'
-
-Hide entire steps depending on the value of a form element:
-
-.. code-block:: yaml
-
-    type: Form
-    identifier: test
-    prototypeName: standard
-    label: Test
-    renderables:
-      -
-        type: Page
-        identifier: page-1
-        label: 'Page 1'
-        renderables:
-          -
-            type: Text
-            identifier: text-1
-            label: 'Text 1'
-          -
-            type: Checkbox
-            identifier: checkbox-1
-            label: 'Skip page 2'
-            variants:
-              -
-                identifier: hide-1
-                condition: 'stepType == "SummaryPage"'
-                renderingOptions:
-                  enabled: false
-      -
-        type: Page
-        identifier: page-2
-        label: 'Page 2'
-        variants:
-          -
-            identifier: variant-1
-            condition: 'formValues["checkbox-1"] == 1'
-            renderingOptions:
-              enabled: false
-        renderables:
-          -
-            type: Text
-            identifier: text-2
-            label: 'Text 2'
-      -
-        type: SummaryPage
-        identifier: summarypage-1
-        label: 'Summary step'
-
-Set finisher values depending on the application context:
-
-.. code-block:: yaml
-
-    type: Form
-    identifier: test
-    prototypeName: standard
-    label: Test
-    renderingOptions:
-      submitButtonLabel: Submit
-    finishers:
-      -
-        identifier: Confirmation
-        options:
-          message: 'Thank you'
-    variants:
-      -
-        identifier: variant-1
-        condition: 'applicationContext matches "#Production/Local#"'
-        finishers:
-          -
-            identifier: Confirmation
-            options:
-              message: 'ouy knahT'
-    renderables:
-      -
-        type: Page
-        identifier: page-1
-        label: 'Page 1'
-        renderingOptions:
-          previousButtonLabel: 'Previous step'
-          nextButtonLabel: 'Next step'
-
-Hide a form element in certain finishers and on the summary step:
-
-.. code-block:: yaml
-
-    type: Form
-    identifier: test
-    prototypeName: standard
-    label: Test
-    finishers:
-      -
-        identifier: EmailToReceiver
-        options:
-          subject: Testmail
-          recipientAddress: tritum@example.org
-          recipientName: 'Test'
-          senderAddress: tritum@example.org
-          senderName: tritum@example.org
-    renderables:
-      -
-        type: Page
-        identifier: page-1
-        label: 'Page 1'
-        renderables:
-          -
-            type: Text
-            identifier: text-1
-            label: 'Text 1'
-            variants:
-              -
-                identifier: hide-1
-                renderingOptions:
-                  enabled: false
-                condition: 'stepType == "SummaryPage" || finisherIdentifier in ["EmailToSender", "EmailToReceiver"]'
-          -
-            type: Text
-            identifier: text-2
-            label: 'Text 2'
-      -
-        type: SummaryPage
-        identifier: summarypage-1
-        label: 'Summary step'
-
-
-Adding own expression language provider
----------------------------------------
-
-If you need to extend the expression language with custom functions you can extend it. For more
-information @see https://symfony.com/doc/4.1/components/expression_language/extending.html#using-expression-providers.
-
-First of all, you have to register the expression language provider within the form setup:
-
-.. code-block:: yaml
-
-    TYPO3:
-      CMS:
-        Form:
-          prototypes:
-            standard:
-              conditionContextDefinition:
-                expressionLanguageProvider:
-                  MyCustomExpressionLanguageProvider:
-                    implementationClassName: '\Vendor\MyExtension\CustomExpressionLanguageProvider'
-
-Your expression language provider must implement :php`Symfony\Component\ExpressionLanguage\ExpressionFunctionProviderInterface`.
-
-
-Adding own expression language variables
-----------------------------------------
-
-If you need to add custom variables to the expression language you can extend it.
-Then the variables are ready to be checked in conditions.
-
-First of all, you have to register the variable provider within the form setup:
-
-.. code-block:: yaml
-
-    TYPO3:
-      CMS:
-        Form:
-          prototypes:
-            standard:
-              conditionContextDefinition:
-                expressionLanguageVariableProvider:
-                  MyCustomExpressionLanguageVariableProvider:
-                    implementationClassName: '\Vendor\MyExtension\CustomExpressionLanguageVariableProvider'
-
-Your expression language variable provider must implement :php`TYPO3\CMS\Form\Domain\Condition\ExpressionLanguageVariableProviderInterface`.
-
-
-.. index:: Frontend, ext:form, NotScanned
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-84584-Re-DesignTheAdminPanel.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-84584-Re-DesignTheAdminPanel.rst
deleted file mode 100644 (file)
index 5316026..0000000
+++ /dev/null
@@ -1,28 +0,0 @@
-.. include:: ../../Includes.txt
-
-===========================================
-Feature: #84584 - Re-Design the admin panel
-===========================================
-
-See :issue:`84584`
-
-Description
-===========
-
-The admin panel got a complete overhaul regarding its design as well as the underlying code and extensibility.
-
-UI wise the following changes were done
-- Ajax is used to save configuration options, so only a single reload is triggered even if multiple settings changed.
-- Settings influencing page rendering should be grouped together
-- Most important info should be available at a glance with possibilities to show extended information
-- Complete design overhaul
-
-
-Impact
-======
-
-The new admin panel provides a better look and feel as well as more convenient access to information and more flexible extensibility.
-For backwards compatibility enabling and disabling modules or options for editors is still possible via User TSConfig.
-
-
-.. index:: Frontend, PHP-API, ext:adminpanel
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-84606-AddLogModuleToAdminPanel.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-84606-AddLogModuleToAdminPanel.rst
deleted file mode 100644 (file)
index 1894ca2..0000000
+++ /dev/null
@@ -1,26 +0,0 @@
-.. include:: ../../Includes.txt
-
-==============================================
-Feature: #84606 - Add Log Module to AdminPanel
-==============================================
-
-See :issue:`84606`
-
-Description
-===========
-
-A log module has been added to the adminPanel to display log entries generated during the current request.
-
-It displays all log entries generated via the logging framework during the request.
-
-Display options include grouping by log level and component, additionally the log level
-which shall be logged has been made configurable.
-
-
-Impact
-======
-
-A new AdminPanel sub module displaying log entries has been added in a new main module "Debug" which may
-be extended with further debug information.
-
-.. index:: Frontend, ext:adminpanel
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-84609-AddSQLLogModuleToAdminPanel.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-84609-AddSQLLogModuleToAdminPanel.rst
deleted file mode 100644 (file)
index 5f1b72f..0000000
+++ /dev/null
@@ -1,26 +0,0 @@
-.. include:: ../../Includes.txt
-
-==================================================
-Feature: #84609 - Add SQL Log Module to AdminPanel
-==================================================
-
-See :issue:`84609`
-
-Description
-===========
-
-A new AdminPanel module has been introduced which shows SQL queries done to generate the current page.
-The module includes a short trace of the query so developers may locate where it was initiated as well as - in case
-it's a prepared statement - the placeholder values to enable checking variations of the query.
-
-Logging of queries is done via the Doctrine SQL Logger capabilities and enabled whenever the AdminPanel is activated /
-open in the frontend. Logging is only done for the currently logged in backend user, this way the overall performance
-impact is negligible.
-
-
-Impact
-======
-
-The AdminPanel has a new sub module "Query Information" in the "Debug" section.
-
-.. index:: Backend, Database, Frontend, ext:adminpanel
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-84704-OpenSpecificFieldWhenFixingLinksInLinkvalidator.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-84704-OpenSpecificFieldWhenFixingLinksInLinkvalidator.rst
deleted file mode 100644 (file)
index 59ffad1..0000000
+++ /dev/null
@@ -1,29 +0,0 @@
-.. include:: ../../Includes.txt
-
-========================================================================
-Feature: #84704 - Open specific field when fixing links in Linkvalidator
-========================================================================
-
-See :issue:`84704`
-
-Description
-===========
-
-When fixing links in Linkvalidator, you click on the edit icon
-for the respective broken link which gets you to an edit form.
-
-Before this patch, the edit form was opened for the entire record.
-
-There you had too much information, and it was difficult to see,
-what needed fixing.
-
-With this patch only the respective table.field that contains
-the broken link is opened in the edit form (e.g. tt_content.bodytext).
-
-
-Impact
-======
-
-Only affects Linkvalidator. Editing broken links should be easier now.
-
-.. index:: Backend, ext:linkvalidator
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-84729-NewTCATypeSlug.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-84729-NewTCATypeSlug.rst
deleted file mode 100644 (file)
index 2f478b2..0000000
+++ /dev/null
@@ -1,65 +0,0 @@
-.. include:: ../../Includes.txt
-
-=====================================
-Feature: #84729 - New TCA type "slug"
-=====================================
-
-See :issue:`84729`
-
-Description
-===========
-
-A new TCA field type called `slug` has been added to TYPO3 Core. Its main purpose is to define parts of a URL
-path to generate and resolve URLs.
-
-With a URL like `https://www.typo3.org/ch/community/values/core-values/` a URL slug is typically a part like
-`/community` or `/community/values/core-values`.
-
-Within TYPO3, a slug is always part of the URL "path" - it does not scheme, host, HTTP verb, etc.
-
-A slug is usually added to a TCA-based database table, contain some rules for evaluation and definition.
-
-In contrast to concepts within RealURL of "URL segments", a slug is a segment of a URL, but it is not limited
-to be separated by slashes. Therefore, a slug can contain slashes.
-
-In the future, it could be possible to generate slugs for any TCA table, but its's main usage will be for the "pages"
-TCA structure.
-
-If a TCA table contains a field called "slug", it needs to be filled for every existing record. It can
-be shown and edited via regular Backend Forms, and is also evaluated during persistence via DataHandler.
-
-The default behaviour of a slug is as follows:
-* A slug only contains characters which are allowed within URLs. Spaces, commas and other special characters are
-  converted to a fallback character.
-* A slug is always lower-cased.
-* A slug is unicode-aware.
-
-The following options apply to the new TCA type::
-
-       'type' => 'slug',
-       'config' => [
-               'generatorOptions' => [
-                       'fields' => ['title', 'nav_title'],
-                       'fieldSeparator' => '/',
-                       'prefixParentPageSlug' => true
-               ]
-               'fallbackCharacter' => '-',
-               'eval' => 'uniqueInSite'
-       ]
-
-In addition the new `eval` option `uniqueInSite` to evaluate if a record is unique in a page tree (specific to a
-language).
-
-The new slug TCA type allows for two `eval` options `uniqueInSite` or `uniqueInPid` (useful for third-party
-records), and no other eval setting is checked for. It is possible to set both eval options, however it is
-recommended not to do so.
-
-It is possible to build a default value from the rootline (very helpful for pages, or categorized slugs),
-but also to just generate a "speaking" segment from e.g. a news title.
-
-Sanitation and Validation configuration options apply when persisting a record via DataHandler.
-
-In the backend forms a validation happens by an AJAX call, which immediately check any input by the user and receive
-a new proposal in case the slug is already used.
-
-.. index:: TCA, ext:core
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-85080-AddPropertyDisableFormElementsAndFinishers.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-85080-AddPropertyDisableFormElementsAndFinishers.rst
deleted file mode 100644 (file)
index 045ca31..0000000
+++ /dev/null
@@ -1,84 +0,0 @@
-.. include:: ../../Includes.txt
-
-=====================================================================
-Feature: #85080 - Add property to disable form elements and finishers
-=====================================================================
-
-See :issue:`85080`
-
-Description
-===========
-
-A a new rendering option for form elements and finishers has been introduced named :yaml:`enabled`
-which takes a boolean value (:yaml:`true` or :yaml:`false`).
-
-Setting :yaml:`enabled: true` for a form element renders it in the frontend and enables processing
-of its value including property mapping and validation. Setting :yaml:`enabled: false` instead
-disables the form element in the frontend.
-
-Setting :yaml:`enabled: true` for a finisher executes it when submitting forms, setting :yaml:`enabled: false`
-skips the finisher instead.
-
-By default :yaml:`enabled` is set to :yaml:`true`.
-
-
-Usage:
-======
-
-All form elements and finishers except the root form element and the first form page can be enabled
-or disabled.
-
-An example:
-
-.. code-block:: yaml
-
-    type: Form
-    identifier: test
-    label: test
-    prototypeName: standard
-    renderables:
-      -
-        type: Page
-        identifier: page-1
-        label: Step
-        renderables:
-          -
-            type: Text
-            identifier: text-1
-            label: Text
-            defaultValue: ''
-          -
-            type: Checkbox
-            identifier: checkbox-1
-            label: Checkbox
-            renderingOptions:
-              enabled: true
-      -
-        type: SummaryPage
-        identifier: summarypage-1
-        label: 'Summary step'
-        renderingOptions:
-          enabled: false
-    finishers:
-      -
-        identifier: Confirmation
-        options:
-          message: thx
-      -
-        identifier: Confirmation
-        options:
-          message: 'thx again'
-          renderingOptions:
-            enabled: '{checkbox-1}'
-
-In this example the form element :yaml:`checkbox-1` has been enabled explicitly but it is fine to
-leave this out since this is the default state (which can be seen in the element :yaml:`text-1`).
-
-The :yaml:`summarypage-1` has been disabled completely, for example to temporarily remove it from
-the form.
-
-The second :yaml:`Confirmation` finisher takes the fact into account that finishers can refer to
-form values. It is only enabled if the form element :yaml:`checkbox-1` has been activated by the
-user. Otherwise the finisher is skipped.
-
-.. index:: Frontend, ext:form, NotScanned
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-85146-ReadEnvironmentVariablesInTypoScript.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-85146-ReadEnvironmentVariablesInTypoScript.rst
deleted file mode 100644 (file)
index cf3c4e9..0000000
+++ /dev/null
@@ -1,35 +0,0 @@
-.. include:: ../../Includes.txt
-
-==========================================================
-Feature: #85146 - Read environment variables in TypoScript
-==========================================================
-
-See :issue:`85146`
-
-Description
-===========
-
-There is a new TypoScript value modifier `getEnv()`. The modifier checks if the variable given as its argument is set
-and reads the value if so, overriding any existing value. If the environment variable is not set, the variable given on
-the left-hand side of the expression is not changed.
-
-
-Impact
-======
-
-Write a TypoScript statement like this to use environment values in your TypoScript:
-
-.. code-block:: typoscript
-
-    # Define default value
-    myConstant = defaultValue
-    # Enable overriding by environment variable
-    myConstant := getEnv(TS_MYCONSTANT)
-
-To have a value actually inserted, your PHP execution environment (webserver, PHP-FPM) needs to have these variables
-set, or you need a mechanism like dotenv to set them in your running TYPO3.
-
-As it is a syntax feature you can use it in both constants and setup plus it gets cached, as opposed to the getText
-`getenv` feature.
-
-.. index:: TypoScript, ext:core
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-85164-AllowToOnlyShowSiteLanguagesInBE.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-85164-AllowToOnlyShowSiteLanguagesInBE.rst
deleted file mode 100644 (file)
index 4865234..0000000
+++ /dev/null
@@ -1,25 +0,0 @@
-.. include:: ../../Includes.txt
-
-===========================================================
-Important: #85164 - Allow to only show site languages in BE
-===========================================================
-
-See :issue:`85164`
-
-Description
-===========
-
-When the backend shows list of available languages - for instance in the page module
-language selector, when editing records and in the list module - the list of languages
-is now restricted to those defined by the site module.
-
-If there are for instance five language records in the system, but a site configures
-only three of them for a page tree, only those three are considered when rendering
-language drop downs.
-
-In case no site configuration has been created for a tree, all language records are shown. In
-this case the Page TSconfig options :php:`mod.SHARED.defaultLanguageFlag`,
-:php:`mod.SHARED.defaultLanguageLabel` and :php:`mod.SHARED.disableLanguages` settings
-are also considered - those are obsolete if a site configuration exists.
-
-.. index:: Backend, ext:backend
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-85164-EnableLanguagesPerSite.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-85164-EnableLanguagesPerSite.rst
deleted file mode 100644 (file)
index 778a13e..0000000
+++ /dev/null
@@ -1,23 +0,0 @@
-.. include:: ../../Includes.txt
-
-======================================================
-Feature: #85164 - Enable Languages on a per-site basis
-======================================================
-
-See :issue:`85164`
-
-Description
-===========
-
-When configuring a new site with multiple languages, is it now possible to not allow a language to be rendered
-in the TYPO3 Frontend. A new checkbox in the Site Handling module allows to add a language but not render it in
-Frontend to allow to prepare a new translation of a website before it is going live.
-
-
-Impact
-======
-
-Previously this wasn't as easy as doing this with one click, and took various places into account to switch
-a translation of a website "live". Going live is now as easy as turning on one checkbox.
-
-.. index:: Frontend
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-85236-AddedInfixOptionToDefaultLogFileNamesForFileWriter.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-85236-AddedInfixOptionToDefaultLogFileNamesForFileWriter.rst
deleted file mode 100644 (file)
index 7eaa39e..0000000
+++ /dev/null
@@ -1,34 +0,0 @@
-.. include:: ../../Includes.txt
-
-=============================================================================
-Feature: #85236 - Added infix option to default log file names for FileWriter
-=============================================================================
-
-See :issue:`85236`
-
-Description
-===========
-
-A new option :php:`logFileInfix` for the :php:`FileWriter` has been introduced.
-This allows to set a different name for the log file that is created by the :php:`FileWriter` without having to define a full path to the file.
-
-The example configuration will use the log file named 'typo3\_special\_<hash>.log'
-for any log message stemming from a class from the :php:`\Vendor\ExtName\` namespace.
-
-.. code-block:: php
-
-   $GLOBALS['TYPO3_CONF_VARS']['LOG']['Vendor']['ExtName']['writerConfiguration'] = [
-     \TYPO3\CMS\Core\Log\LogLevel::INFO => [
-       \TYPO3\CMS\Core\Log\Writer\FileWriter::class => [
-         'logFileInfix' => 'special'
-       ]
-     ]
-   ];
-
-
-Impact
-======
-
-The behaviour for existing :php:`FileWriter` configurations is not changed.
-
-.. index:: LocalConfiguration, ext:core
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-85247-TraitToDetectPublicDeprecatedMethods.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-85247-TraitToDetectPublicDeprecatedMethods.rst
deleted file mode 100644 (file)
index 0b8846c..0000000
+++ /dev/null
@@ -1,29 +0,0 @@
-.. include:: ../../Includes.txt
-
-===========================================================
-Feature: #85247 - Trait to detect public deprecated methods
-===========================================================
-
-See :issue:`85247`
-
-Description
-===========
-
-The trait :php:`TYPO3\CMS\Core\Compatibility\PublicMethodDeprecationTrait` has been added
-to allow setting public methods to protected in a backwards compatible way.
-
-The core uses this trait to set public methods that to should be protected or private but
-are accessible codewise for historical reasons, while extensions using the methods do not
-break, but a deprecation note is logged.
-
-Classes using this trait have a property :php:`$deprecatedPublicMethods` that lists all
-methods covered by the trait.
-
-
-Impact
-======
-
-Core classes using this trait log deprecation notes if an extension uses a method that
-has been made protected using the trait functionality.
-
-.. index:: PHP-API
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-85256-InstallTYPO3OnSQLite.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-85256-InstallTYPO3OnSQLite.rst
deleted file mode 100644 (file)
index 6271b27..0000000
+++ /dev/null
@@ -1,45 +0,0 @@
-.. include:: ../../Includes.txt
-
-=========================================
-Feature: #85256 - Install TYPO3 on SQLite
-=========================================
-
-See :issue:`85256`
-
-Description
-===========
-
-The TYPO3 web installer allows to install the system on `SQLite` DBMS.
-
-This platform can be selected if :php:`pdo_sqlite` is available in PHP, which is
-often the case. SQLite can be a nice DBMS for relatively small instances and has
-the advantage that no further server side daemon is needed.
-
-Administrators must keep an eye on security if using this platform:
-
-In SQLite, a database is stored in a single file. In TYPO3, its default location
-is the var/sqlite path of the instance which is derived from environment variable
-:php:`TYPO3_PATH_APP`. If that variable is **not** set which is
-often the case in non-composer instances, **the database file will end up in the
-web server accessible document root directory :file:`typo3conf/`**!
-
-To prevent guessing the database name and simply downloading it, the installer appends
-a random string to the database filename during installation. Additionally, the demo
-Apache :file:`_.htaccess` file prevents downloading :file:`.sqlite` files. The demo
-MicroSoft IIS web server configuration in file :file:`_web.config` comes with the same
-restriction.
-
-Administrators installing TYPO3 using the SQLite platform should thus test if the
-database is downloadable from the web and take measures to prevent this by either
-configuring the web server to deny this file, or - better - by moving the config folder
-out of the document root, which is good practice anyway.
-
-
-Impact
-======
-
-TYPO3 can be installed to run on SQLite. If choosing this option, administrators
-must check the file is never delivered by the web server.
-
-
-.. index:: Database
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-85313-AddNotesFieldToPagesTable.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-85313-AddNotesFieldToPagesTable.rst
deleted file mode 100644 (file)
index d5027bb..0000000
+++ /dev/null
@@ -1,20 +0,0 @@
-.. include:: ../../Includes.txt
-
-================================================
-Feature: #85313 - Add notes field to pages table
-================================================
-
-See :issue:`85313`
-
-Description
-===========
-
-A :php:`descriptionColumn` has been added to the pages table.
-
-
-Impact
-======
-
-Users can add notes to each page record to inform other users of important facts or similar.
-
-.. index:: Backend
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-85355-SupportBasicHTML5FieldsInFormEngine.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-85355-SupportBasicHTML5FieldsInFormEngine.rst
deleted file mode 100644 (file)
index 87ef2e4..0000000
+++ /dev/null
@@ -1,23 +0,0 @@
-.. include:: ../../Includes.txt
-
-==========================================================
-Feature: #85355 - Support basic HTML5 fields in FormEngine
-==========================================================
-
-See :issue:`85355`
-
-Description
-===========
-
-The FormEngine renders now HTML5 specific field types and attributes.
-
-
-Impact
-======
-
-Depending on the :php:`eval` configuration, the input types may be :html:`text`, :html:`number`
-or :html:`email.`
-If :php:`range` is configured, its values are stored in :html:`min` and :html:`max` attributes
-for number fields.
-
-.. index:: Backend, ext:backend
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-85389-ContextAPIForConsistentDataHandling.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-85389-ContextAPIForConsistentDataHandling.rst
deleted file mode 100644 (file)
index 098d8a4..0000000
+++ /dev/null
@@ -1,125 +0,0 @@
-.. include:: ../../Includes.txt
-
-==========================================================
-Feature: #85389 - Context API for consistent data handling
-==========================================================
-
-See :issue:`85389`
-
-Description
-===========
-
-A new Context API is introduced, which encapsulates various information for data retrieval (e.g. inside
-the database) and analysis of current permissions and caching information.
-
-Previously, various information was distributed inside globally accessible objects (:php:`$TSFE` or :php:`$BE_USER`)
-like the current workspace ID or if a frontend or backend user is authenticated. Having a global object
-available was also dependent on the current request type (frontend or backend), instead of having
-one consistent place where all this data is located.
-
-The context is currently instantiated at the very beginning of each TYPO3 entry point, keeping track
-of the current time (formally known as :php:`$GLOBALS['EXEC_TIME']`, and if a user is logged in,
-and which workspace is currently accessed.
-
-This information is separated in so-called "Aspects", being responsible for a certain area:
-
-- VisibilityAspect, holding information if hidden/deleted records should be fetched from the database
-- DateTimeAspect, keeping the current date as immutable datetime object
-- UserAspect, holding frontend/backend user IDs, usernames and usergroups
-- WorkspaceAspect, holding the currently visible workspace (default to "0"/ live)
-
-Further aspects related to the current request (e.g. selected language information and fallback strategy)
-will follow, but extensions can add their own Aspects as well, as they only need to implement the AspectInterface.
-
-The Context object is used as a Singleton, available via :php:`GeneralUtility::makeInstance(Context::class)`.
-
-Adding or replacing an aspect has implications on the whole further request. The recommended way on doing
-so is done in a PSR-15 middleware. In the future (TYPO3 v10), the global context will have a "frozen" state
-after all PSR-15 middlewares are run through, to ensure a consistent object throughout all renderings
-within a backend.
-
-However, if, for a certain retrieval part a custom context is needed, the necessary PHP classes, like
-:php:`PageRepository` can receive a custom Context object. For this to work, a new Context object can be
-created via :php:`new Context()`  and or cloned from the master context via
-:php:`$myContext = clone GeneralUtility::makeInstance(Context::class);` to keep all existing aspects but only to
-override a certain aspect locally.
-
-A huge benefit when using the Context API is a strong decoupling of various architectural failures within
-TYPO3 Core, which are now "Context aware" and not depending if a certain global object is available.
-
-This will not only unify the code quality, but also introduce a better standard, where hard intermingling within
-Extbase, PageRepository and TypoScriptFrontendController can be found.
-
-Impact
-======
-
-The new Context API replaces lots of places known for a very long time:
-
-* DateTimeAspect replaces :php:`$GLOBALS['SIM_EXEC_TIME']` and :php:`$GLOBALS['EXEC_TIME']`
-* VisibilityAspect replaces :php:`$GLOBALS['TSFE']->showHiddenPages` and :php:`$GLOBALS['TSFE']->showHiddenRecords`
-* WorkspaceAspect replaces :php:`$GLOBALS['BE_USER']->workspace`
-* LanguageAspect replaces various properties related to language Id, overlay and fallback logic, mostly within Frontend
-* UserAspect replaces various calls and checks on :php:`$GLOBALS['BE_USER']` and :php:`$GLOBALS['TSFE']->fe_user`
-options when only some information is needed.
-
-
-TYPO3 Core comes with the following Aspects within the global context:
-
-* date
-* frontend.user
-* backend.user
-* workspace
-* visibility
-* language
-
-Usage
-=====
-
-As for TYPO3 v9, the old properties can be used the same way as before, but will throw a deprecation warning.
-
-It is recommended to read data from the current global Context for custom extensions:
-
-.. code-block:: php
-
-    $context = GeneralUtility::makeInstance(Context::class);
-
-    // Reading the current data instead of $GLOBALS['EXEC_TIME']
-    $currentTimestamp = $context->getPropertyFromAspect('date', 'timestamp');
-
-    // Checking if a user is logged in
-    $userIsLoggedIn = $context->getPropertyFromAspect('frontend.user', 'isLoggedIn');
-
-
-If an aspect needs to be added, or a middleware replaces an aspect, the main context object can be altered.
-
-However, if custom DB queries need to be made, it is strongly recommended to clone the context object:
-
-.. code-block:: php
-
-    // Current global context
-    $context = GeneralUtility::makeInstance(Context::class);
-    $localContextWithoutFrontendUser = clone $context;
-    $localContextWithoutFrontendUser->setAspect('frontend.user', GeneralUtility::makeInstance(UserAspect::class, null);
-
-    // Fetch a page which is publically available, but not accessible when logged in
-    $sysPage = GeneralUtility::makeInstance(PageRepository::class, $localContextWithoutFrontendUser);
-    $pageRow = $sysPage->getPage($pageId);
-
-
-As a rule of thumb:
-- If new code is written that is depending on external factors for querying data, ensure that a context object
-can be handed in via e.g. the constructor.
-- If you are sure, that the consuming class is NOT altering the context object, the main context object can be used
-- If the consuming class, e.g. ContentObjectRenderer is altering the context object, it is recommended to hand in a clone
-of a context.
-
-Further development
-===================
-
-There will be additional aspects that will be introduced in TYPO3 Core. Also see PSR-15 middlewares shipped with TYPO3
-Frontend or Backend to see how aspects can be modified and set.
-
-Aspects eventually will become the successor of Database Restrictions, as they contain all information
-necessary to restrict a database query.
-
-.. index:: PHP-API, ext:core
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-85410-AllowTCADescriptionProperty.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-85410-AllowTCADescriptionProperty.rst
deleted file mode 100644 (file)
index 21dca74..0000000
+++ /dev/null
@@ -1,40 +0,0 @@
-.. include:: ../../Includes.txt
-
-================================================
-Feature: #85410 - Allow TCA description property
-================================================
-
-See :issue:`85410`
-
-Description
-===========
-
-The new `TCA` property `description` on column field level has been introduced.
-The value data type is a localized string, similar and on the same level as `label`.
-
-The property can be used to display an additional help text between the field label and
-the user input when editing records. As an example, the core uses the description property
-in the site configuration module when editing a site on some properties like `identifier`.
-
-The property is available on all common `TCA` types like `input` and `select` and so on.
-
-Example::
-
-    'columns' => [
-        'myField' => [
-            'label' => 'My label',
-            'description' => 'LLL:EXT:my_ext/Resources/Private/Language/locallang_tca.xlf:field.description',
-            'config' => [
-                'type' => 'input',
-            ],
-        ],
-    ],
-
-
-Impact
-======
-
-The change is fully backwards compatible and can be used by integrators or administrators
-to hint editors for expected field input.
-
-.. index:: Backend, FlexForm, TCA
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-85550-IntroduceContextForTypoScriptDataGetTextProperty.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-85550-IntroduceContextForTypoScriptDataGetTextProperty.rst
deleted file mode 100644 (file)
index e0748df..0000000
+++ /dev/null
@@ -1,31 +0,0 @@
-.. include:: ../../Includes.txt
-
-========================================================================
-Feature: #85550 - Introduce context for TypoScript data getText property
-========================================================================
-
-See :issue:`85550`
-
-Description
-===========
-
-The new context API can now be accessed via the :ts:`getText` property in TypoScript.
-
-Example:
-
-.. code-block:: typoscript
-
-       page.10 = TEXT
-       page.10.data = context:workspace:id
-       page.10.wrap = You are in workspace: |
-
-Where as `context` is the keyword for accessing an aspect, the second part is the name of the aspect,
-and the third part is the property of the aspect.
-
-.. code-block:: typoscript
-
-       data = context:[aspectName]:[propertyName]
-
-If a property is an array, it is converted into a comma-separated list.
-
-.. index:: TypoScript, ext:frontend
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-85590-AddHooksForDatabaseRecordListCSVActions.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-85590-AddHooksForDatabaseRecordListCSVActions.rst
deleted file mode 100644 (file)
index 49a49ac..0000000
+++ /dev/null
@@ -1,33 +0,0 @@
-.. include:: ../../Includes.txt
-
-==============================================================
-Feature: #85590 - Add hooks for DatabaseRecordList CSV actions
-==============================================================
-
-See :issue:`85590`
-
-Description
-===========
-
-Now it is possible to customize the csv output in the DatabaseRecordList with a hook.
-
-The following two hooks were implemented:
-- customizeCsvHeader for the header
-- customizeCsvRow for a single row
-
-
-Impact
-======
-
-Now you can influence the output of the CSV files in the DatabaseRecordList with hooks. For this you can
-register the hooks in an extension.
-
-Example:
-
-.. code-block:: php
-
-$hookName = DatabaseRecordList::class;
-$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS'][$hookName]['customizeCsvRow'][] = \Vendor\ExtName\Hooks\CsvTest::class . '->customizeCsvRow';
-$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS'][$hookName]['customizeCsvHeader'][] = \Vendor\ExtName\Hooks\CsvTest::class . '->customizeCsvHeader';
-
-.. index:: Backend
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-85678-AddAPIForTitleTags.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-85678-AddAPIForTitleTags.rst
deleted file mode 100644 (file)
index d946142..0000000
+++ /dev/null
@@ -1,96 +0,0 @@
-.. include:: ../../Includes.txt
-
-===================================
-Feature: #85678 - Add PageTitle API
-===================================
-
-See :issue:`85678`
-
-Description
-===========
-
-In order to keep setting the titles in control, a new API to set the page title has been introduced.
-
-The API uses :php:`PageTitleProviders` to define the page title based on page record and the content on the page.
-
-Based on the priority of the providers, the :php:`PageTitleProviderManager` will check the providers if a title
-is given by the provider. It will start with the highest priority PageTitleProviders and will end with the lowest
-in priority.
-
-By default, the core ships three providers. The provider with the (by default) highest priority will be the
-:php:`AltPageTitleProvider`. This provider handles the (since v9 deprecated) property
-:php:`$GLOBALS['TSFE']->altPageTitle`. If an extension has set a value to this property, this provider will return
-that value.
-
-If you have installed the system extension SEO, the second provider will be the :php:`SeoTitlePageTitleProvider`.
-When an editor has set a value for the SEO title in the page properties of the page, this provider will provide
-that title to the :php:`PageTitleProviderManager`. If you have not installed the SEO system extension, this fields
-and provider are not available.
-
-The fallback provider with the lowest priority is the :php:`RecordPageTitleProvider`. When no other title is set
-by a provider, this provider will return the title of the page.
-
-Besides the providers shipped by core, you can add own providers. An integrator can define the priority of the
-providers for his project.
-
-Create your own PageTitleProvider
-=================================
-
-Extension developer may want to have an own provider for page titles. For example if you have an extension with
-records and a detail view. The title of the page record, will not be the correct title. To make sure to display
-the correct page title, you have to create your own :php:`PageTitleProvider`. It is quite easy to create one.
-
-First of all create a PHP class in your extension that implements the :php:`PageTitleProviderInterface`. This will
-force you to have at least the :php:`getTitle()` method in your class. Within this method you can create your
-own logic to define the correct title.
-
-Define priority of PageTitleProviders
-=====================================
-
-The priority of the providers are set by the TypoScript property :typoscript:`config.pageTitleProviders`. This
-way an integrator is able to set the priorities for his project and can even have conditions in place.
-
-By default, the core has the following setup:
-
-.. code-block:: typoscript
-
-   config.pageTitleProviders {
-        altPageTitle {
-            provider = TYPO3\CMS\Core\PageTitle\AltPageTitleProvider
-            before = record
-        }
-        record {
-            provider = TYPO3\CMS\Core\PageTitle\RecordPageTitleProvider
-        }
-   }
-
-The ordering of the providers is based on the `before` and `after` parameters. If you want a provider to be handled
-before a specific other provider, just set that provider in the `before`, do the same with `after`.
-
-If you have installed the system extension SEO, you will also get a third provider. The configuration will be:
-
-.. code-block:: typoscript
-
-   config.pageTitleProviders {
-      altPageTitle {
-         provider = TYPO3\CMS\Core\PageTitle\AltPageTitleProvider
-         before = record
-      }
-      record {
-         provider = TYPO3\CMS\Core\PageTitle\RecordPageTitleProvider
-      }
-      seo {
-         provider = TYPO3\CMS\Seo\PageTitle\SeoTitlePageTitleProvider
-         before = record
-         after = altPageTitle
-      }
-   }
-
-First the :php:`AltPageTitleProvider` will be checked, then the :php:`SeoTitlePageTitleProvider` (because it will be
-handled before record and after altPageTitle) and if both providers didn't provide a title, the
-:php:`RecordPageTitleProvider` will be checked.
-
-You can override these settings within your own installation. You can add as many providers as you want. Be aware
-that if a provider returns a non-empty value, all provider with a lower priority won't be checked.
-
-.. index:: Frontend, ext:core, ext:seo
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-85691-ShowPagePathForReferencesInRecordInfo.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-85691-ShowPagePathForReferencesInRecordInfo.rst
deleted file mode 100644 (file)
index 1220fa8..0000000
+++ /dev/null
@@ -1,20 +0,0 @@
-.. include:: ../../Includes.txt
-
-==============================================================
-Feature: #85691 - Show page path for references in record info
-==============================================================
-
-See :issue:`85691`
-
-Description
-===========
-
-This feature adds the page path of record references into the table found in the record info.
-
-
-Impact
-======
-
-Better way to find record references via the record info
-
-.. index:: Backend, ext:backend
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-85698-NewTypeinputEvalSaltedPassword.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-85698-NewTypeinputEvalSaltedPassword.rst
deleted file mode 100644 (file)
index 0a0aa1d..0000000
+++ /dev/null
@@ -1,31 +0,0 @@
-.. include:: ../../Includes.txt
-
-====================================================
-Feature: #85698 - New type=input eval saltedPassword
-====================================================
-
-See :issue:`85698`
-
-Description
-===========
-
-Setting passwords and storing them as salted passwords in the database
-is now supported by adding :php:`saltedPassword` to :php:`TCA` :php:`type=input`
-fields.
-
-Fields having this eval set will get their value evaluated to a salted
-hash before they are stored by the :php:`DataHandler`.
-
-Note the salt configuration for backend (BE) is considered when using this eval
-on tables that is not the :php:`fe_users` table.
-
-
-Impact
-======
-
-The new eval substitutes custom code that has been done within the
-salted passwords extension before. It has no impact on instances
-being upgraded.
-
-
-.. index:: Backend, TCA
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-85719-AllowSitesWithoutSchemeOrDomain.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-85719-AllowSitesWithoutSchemeOrDomain.rst
deleted file mode 100644 (file)
index 6ad8dbe..0000000
+++ /dev/null
@@ -1,40 +0,0 @@
-.. include:: ../../Includes.txt
-
-======================================================
-Feature: #85719 - Allow sites without scheme or domain
-======================================================
-
-See :issue:`85719`
-
-Description
-===========
-
-Since the inception of site handling, the definition of a site base - the URL prefix - was limited to
-only allow a full URI with scheme (HTTP/HTTPS) and domain. This didn't allow to run TYPO3 on multiple
-domains, basically limiting the URL-resolving ("Site Routing") compared to previous URL handling
-solutions in the past.
-
-A new site routing based on symfony/routing component allows to have a flexible routing based on
-specific schemes.
-
-
-Impact
-======
-
-It is now possible to set a site base prefix to just "/site1" and "/site2" or "www.mydomain.com" instead
-of entering a full URI.
-
-This allows to have a Site base e.g. `www.mydomain.com` to be detected with http and https protocols,
-although it is recommended to do a HTTP to HTTPS redirect either on the webserver level, via a
-.htaccess rewrite rule, or by adding a redirect in TYPO3.
-
-Please also note that this better flexibility will also introduce side-effects when having multiple sites with mixed configuration settings as Site base:
-
-Site 1: `/mysite/`
-Site 2: `www.mydomain.com`
-
-will be unspecific when detecting a URL like `www.mydomain/mysite/` and can lead to side-effects.
-
-In this case, it is necessary by the Site Administrator to define unique Site base prefixes.
-
-.. index:: Frontend
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-85828-MoveSymfonyExpressionLanguageHandlingIntoEXTcore.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-85828-MoveSymfonyExpressionLanguageHandlingIntoEXTcore.rst
deleted file mode 100644 (file)
index 5b57251..0000000
+++ /dev/null
@@ -1,36 +0,0 @@
-.. include:: ../../Includes.txt
-
-=========================================================================
-Feature: #85828 - Move symfony expression language handling into EXT:core
-=========================================================================
-
-See :issue:`85828`
-
-Description
-===========
-
-The symfony expression language handling has been moved out of EXT:form into EXT:core.
-This step was required to make the expression language usable also in other scopes.
-
-To use the expression language a provider definition is required which implements the :php:`\TYPO3\CMS\Core\ExpressionLanguage\ProviderInterface`.
-The core comes with a :php:`\TYPO3\CMS\Core\ExpressionLanguage\DefaultProvider` class which can be used directly.
-For a custom implementation the :php:`\TYPO3\CMS\Core\ExpressionLanguage\AbstractProvider` class can be extended.
-
-The provider can provide additional variables and expression functions to extend the expression language.
-For a custom implementation check out the :php:`\TYPO3\CMS\Form\Domain\Condition\ConditionProvider` class.
-
-A usage example:
-
-.. code-block:: php
-
-   $provider = GeneralUtility::makeInstance(\TYPO3\CMS\Core\ExpressionLanguage\DefaultProvider::class);
-   $conditionResolver = GeneralUtility::makeInstance(\TYPO3\CMS\Core\ExpressionLanguage\Resolver::class, $provider);
-   $conditionResolver->evaluate('1 < 2'); // result is true
-
-
-Impact
-======
-
-The expression language can now be used in other scopes and has no dependency to EXT:form
-
-.. index:: Backend, Frontend, PHP-API, ext:core
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-85829-ImplementSymfonyExpressionLanguageForTypoScriptConditions.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-85829-ImplementSymfonyExpressionLanguageForTypoScriptConditions.rst
deleted file mode 100644 (file)
index 14341b5..0000000
+++ /dev/null
@@ -1,195 +0,0 @@
-.. include:: ../../Includes.txt
-
-=================================================================================
-Feature: #85829 - Implement symfony expression language for TypoScript conditions
-=================================================================================
-
-See :issue:`85829`
-
-Description
-===========
-
-The `symfony expression language <https://symfony.com/doc/current/components/expression_language.html>`__ has been implemented for TypoScript conditions in both frontend and backend.
-The existing conditions are available as variables and/or functions. Please check the following tables in detail.
-
-General Usage
--------------
-
-To learn the full power of the symfony expression language please check the `documentation for the common expression syntax <https://symfony.com/doc/current/components/expression_language/syntax.html>`__.
-Here are some examples to understand the power of the new expression language:
-
-.. code-block:: typoscript
-
-   [page["uid"] in 18..45]
-   # This condition matches if current page uid is between 18 and 45
-   [END]
-
-   [userId in [1,5,7]]
-   # This condition matches if current logged in user has the uid 1, 5 or 7
-   [END]
-
-   [not ("foo" matches "/bar/")]
-   # This condition does match if "foo" **not** matches the regExp: `/bar/`
-   [END]
-
-   [applicationContext == "Production"] && [userId == 15] && [globalVar('TSFE:id') == 125]
-   # This condition match if application context is "Production" AND logged in user has the uid 15 AND current page is 125
-   # This condition could also be combined in one condition:
-   # [applicationContext("Production") && userId == 15 && globalVar('TSFE:id') == 125]
-   [END]
-
-   [request.getNormalizedParams().getHttpHost() == 'typo3.org']
-   # This condition matches if current hostname is typo3.org
-   [END]
-
-   [like(request.getNormalizedParams().getHttpHost(), "*.devbox.local")]
-   # This condition matches if current hostname is any subdomain of devbox.local
-   [END]
-
-   [request.getNormalizedParams().isHttps() == false]
-   # This condition matches if current request is **not** https
-   [END]
-
-
-Variables
----------
-
-The following variables are available. The values are context related.
-
-+---------------------+------------+----------------------------------------------------------------+
-| Variable            | Type       | Description                                                    |
-+=====================+============+================================================================+
-| applicationContext  | String     | current application context as string                          |
-+---------------------+------------+----------------------------------------------------------------+
-| page                | Array      | current page record as array                                   |
-+---------------------+------------+----------------------------------------------------------------+
-| {$foo.bar}          | Constant   | Any TypoScript constant is available like before.              |
-|                     |            | Depending on the type of the constant you have to use          |
-|                     |            | different conditions, see examples below:                      |
-|                     |            | - if constant is an integer:                                   |
-|                     |            | - [{$foo.bar} == 4711]                                         |
-|                     |            | - if constant is a string put constant in quotes:              |
-|                     |            | - ["{$foo.bar}" == "4711"]                                     |
-+---------------------+------------+----------------------------------------------------------------+
-| tree                | Object     | object with tree information                                   |
-| .level              | Integer    | current tree level                                             |
-| .rootLine           | Array      | array of arrays with uid and pid                               |
-| .rootLineIds        | Array      | an array with UIDs of the rootline                             |
-+---------------------+------------+----------------------------------------------------------------+
-| backend             | Object     | object with backend information (available in BE only)         |
-| .user               | Object     | object with current backend user information                   |
-| .user.isAdmin       | Boolean    | true if current user is admin                                  |
-| .user.isLoggedIn    | Boolean    | true if current user is logged in                              |
-| .user.userId        | Integer    | UID of current user                                            |
-| .user.userGroupList | String     | comma list of group UIDs                                       |
-+---------------------+------------+----------------------------------------------------------------+
-| frontend            | Object     | object with frontend information (available in FE only)        |
-| .user               | Object     | object with current frontend user information                  |
-| .user.isLoggedIn    | Boolean    | true if current user is logged in                              |
-| .user.userId        | Integer    | UID of current user                                            |
-| .user.userGroupList | String     | comma list of group UIDs                                       |
-+---------------------+------------+----------------------------------------------------------------+
-| typo3               | Object     | object with TYPO3 related information                          |
-| .version            | String     | TYPO3_version (e.g. 9.4.0-dev)                                 |
-| .branch             | String     | TYPO3_branch (e.g. 9.4)                                        |
-| .devIpMask          | String     | $GLOBALS['TYPO3_CONF_VARS']['SYS']['devIPmask']                |
-+---------------------+------------+----------------------------------------------------------------+
-
-
-Functions
----------
-
-Functions take over the logic of the old conditions which do more than a simple comparison check.
-The following functions are available in **any** context:
-
-+------------------------+-----------------------+--------------------------------------------------+
-| Function               | Parameter             | Description                                      |
-+========================+=======================+==================================================+
-| request                | Custom Object         | This object provides 4 methods                   |
-| .getQueryParams()      |                       | - [request.getQueryParams()['foo'] == 1]         |
-| .getParsedBody()       |                       | - [request.getParsedBody()['foo'] == 1]          |
-| .getHeaders()          |                       | - [request.getHeaders()['Accept'] == 'json']     |
-| .getCookieParams()     |                       | - [request.getCookieParams()['foo'] == 1]        |
-| .getNormalizedParams() |                       | - [request.getNormalizedParams().isHttps()]      |
-+------------------------+-----------------------+--------------------------------------------------+
-| date                   | String                | Get current date in given format.                |
-|                        |                       | Examples:                                        |
-|                        |                       | - true if day of current month is 7:             |
-|                        |                       | - [date("j") == 7]                               |
-|                        |                       | - true if day of current week is 7:              |
-|                        |                       | - [date("w") == 7]                               |
-|                        |                       | - true if day of current year is 7:              |
-|                        |                       | - [date("z") == 7]                               |
-|                        |                       | - true if current hour is 7:                     |
-|                        |                       | - [date("G") == 7]                               |
-+------------------------+-----------------------+--------------------------------------------------+
-| like                   | String                | This function has two parameters:                |
-|                        |                       | the first parameter is the string to search in   |
-|                        |                       | the second parameter is the search string        |
-|                        |                       | Example:                                         |
-|                        |                       | - [like("foobarbaz", "*bar*")]                   |
-+------------------------+-----------------------+--------------------------------------------------+
-| ip                     | String                | Value or Constraint, Wildcard or RegExp possible |
-|                        |                       | special value: devIP (match the devIPMask        |
-+------------------------+-----------------------+--------------------------------------------------+
-| compatVersion          | String                | version constraint, e.g. 9.4 or 9.4.0            |
-+------------------------+-----------------------+--------------------------------------------------+
-| loginUser              | String                | value or constraint, wildcard or RegExp possible |
-|                        |                       | Examples:                                        |
-|                        |                       | - [loginUser('*')]          // any logged in user|
-|                        |                       | - [loginUser(1)]            // user with uid 1   |
-|                        |                       | - [loginUser('1,3,5')]      // user 1, 3 or 5    |
-|                        |                       | - [loginUser('*') == false] // not logged in     |
-+------------------------+-----------------------+--------------------------------------------------+
-| getTSFE                | Object                | TypoScriptFrontendController ($GLOBALS['TSFE'])  |
-+------------------------+-----------------------+--------------------------------------------------+
-| getenv                 | String                | PHP function: getenv()                           |
-+------------------------+-----------------------+--------------------------------------------------+
-| usergroup              | String                | value or constraint, wildcard or RegExp possible |
-+------------------------+-----------------------+--------------------------------------------------+
-
-
-The following functions are only available in **frontend** context:
-
-+--------------------+------------+-----------------------------------------------------------------+
-| Function           | Parameter  | Description                                                     |
-+====================+============+=================================================================+
-| session            | String     | Get value from session                                          |
-|                    |            | Example, matches if session value = 1234567                     |
-|                    |            | - [session("session:foo|bar") == 1234567]                       |
-+--------------------+------------+-----------------------------------------------------------------+
-| site               | String     | get value from site configuration, or null if                   |
-|                    |            | no site was found or property does not exists                   |
-|                    |            | Example, matches if site identifier = foo                       |
-|                    |            | - [site("identifier") == "foo"]                                 |
-|                    |            | Example, matches if site base = http://localhost                |
-|                    |            | - [site("base") == "http://localhost"]                          |
-+--------------------+------------+-----------------------------------------------------------------+
-| siteLanguage       | String     | get vale from siteLanguage configuration, or                    |
-|                    |            | null if no site was found or property not exists                |
-|                    |            | Example, match if siteLanguage locale = foo                     |
-|                    |            | - [siteLanguage("locale") == "de_CH"]                           |
-|                    |            | Example, match if siteLanguage title = Italy                    |
-|                    |            | - [siteLanguage("title") == "Italy"]                            |
-+--------------------+------------+-----------------------------------------------------------------+
-
-
-Extending the expression language with own functions (like old userFunc)
-------------------------------------------------------------------------
-
-It is possible to extend the expression language with own functions like before userFunc in the old conditions.
-An example could be :php:`TYPO3\CMS\Core\ExpressionLanguage\TypoScriptConditionFunctionsProvider` which implements
-the most core functions.
-
-Adding new methods by implementing your own provider which implement the :php:`ExpressionFunctionProviderInterface` and
-register the provider in your ``ext_localconf.php`` file:
-
-.. code-block:: php
-
-   if (!is_array($GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['TYPO3\CMS\Core\ExpressionLanguage\TypoScriptConditionProvider']['additionalExpressionLanguageProvider'])) {
-      $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['TYPO3\CMS\Core\ExpressionLanguage\TypoScriptConditionProvider']['additionalExpressionLanguageProvider'] = [];
-   }
-   $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['TYPO3\CMS\Core\ExpressionLanguage\TypoScriptConditionProvider']['additionalExpressionLanguageProvider'][] = \My\NameSpace\Provider\TypoScriptConditionProvider::class;
-
-
-.. index:: Backend, Frontend, TypoScript, ext:core
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-85894-FeatureTogglesInAdminToolsSettings.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-85894-FeatureTogglesInAdminToolsSettings.rst
deleted file mode 100644 (file)
index 99f317e..0000000
+++ /dev/null
@@ -1,22 +0,0 @@
-.. include:: ../../Includes.txt
-
-=========================================================
-Feature: #85894 - Feature toggles in Admin Tools Settings
-=========================================================
-
-See :issue:`85894`
-
-Description
-===========
-
-Feature toggles registered in :file:`DefaultConfiguration.php` and documented
-in :file:`DefaultConfigurationDescription.yml` can now be toggled using
-the interface Admin Tools -> Settings -> Feature toggles.
-
-
-Impact
-======
-
-Toggling core features is possible using the backend.
-
-.. index:: Backend, LocalConfiguration, ext:install
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-85900-PseudoSiteHandling.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-85900-PseudoSiteHandling.rst
deleted file mode 100644 (file)
index 7688cbe..0000000
+++ /dev/null
@@ -1,27 +0,0 @@
-.. include:: ../../Includes.txt
-
-======================================
-Feature: #85900 - Pseudo Site Handling
-======================================
-
-See :issue:`85900`
-
-Description
-===========
-
-The new site handling functionality has a counterpart for usages within PHP code where no site configuration
-can be found, which is named "Pseudo Site", a site without configuration.
-
-For a pseudo-site it is not possible to determine all available languages (as they are only configured in
-TypoScript), or the proper labels for the default language (as this is done in PageTSconfig), however, a
-PseudoSite or Site object (both instances of "SiteInterface") is now always attached to every Frontend or
-Backend request via a PSR-15 middleware.
-
-
-Impact
-======
-
-Extension Developers can now access a site and determine the base URL / Entry Point URL for a site, or access
-all available languages via the SiteInterface object, instead of querying sys_domain or sys_language respectively.
-
-.. index:: PHP-API
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-85928-UpgradeWizardToMigratePagesToSpeakingURLs.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-85928-UpgradeWizardToMigratePagesToSpeakingURLs.rst
deleted file mode 100644 (file)
index f13b5fd..0000000
+++ /dev/null
@@ -1,42 +0,0 @@
-.. include:: ../../Includes.txt
-
-==================================================================
-Feature: #85928 - Upgrade wizard to migrate pages to speaking URLs
-==================================================================
-
-See :issue:`85928`
-
-Description
-===========
-
-TYPO3 now supports "Speaking URLs" for pages, and in order to fully make use of this feature, an
-upgrade wizard builds up the URL segment (pagepath) for all pages that do not have a value
-set already.
-
-In order to ease the pain when upgrading from previous versions that supported RealURL,
-the upgrade wizard checks for additional tables "tx_realurl_pathcache" (realurl v1) and
-"tx_realurl_pathdata" (realurl v2+) if they exist in the database, to fill the page paths based
-on these values - however they will get sanitized to match the slug layout with a prefixed "/".
-
-Pages that contain value in their "alias" database field, this takes priority over "regular" pages
-and values from RealURL, whereas alias fields will result in a slug like "/my-alias-value".
-
-
-Impact
-======
-
-After running the upgrade wizard, it is possible to use all of the speaking URL functionality for
-all pages that support a site configuration.
-
-The upgrade wizard also runs through all pages that do not have a site configuration yet, in
-order to ensure consistent state throughout the database. It is encouraged to create a site
-configuration for a pagepath before running this upgrade wizard.
-
-Please take note that running the upgrade wizard does not migrate a previously configured RealURL
-project fully to the new structure. It only eases the migration, but the full migration depends
-on many more previous URL generation configurations used.
-
-Also: if `simulate_static`, `realurl` or `cooluri` or any other extension for URL rewriting was
-used, it is highly possible that pages are now available under different URLs than before.
-
-.. index:: Database
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-85947-PageBasedURLHandling.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-85947-PageBasedURLHandling.rst
deleted file mode 100644 (file)
index 08b3105..0000000
+++ /dev/null
@@ -1,40 +0,0 @@
-.. include:: ../../Includes.txt
-
-=========================================
-Feature: #85947 - Page based URL handling
-=========================================
-
-See :issue:`85947`
-
-Description
-===========
-
-Page records now have a field called "slug" that contains the website
-frontend path to the page, like "/team/about-us/". When a page has the
-field filled, the URL which the site is linked to, will receive a full URL
-to that page, instead of the common :php:`index.php?id=xy` that TYPO3 builds
-by default.
-
-When using Site Handling for a page tree, this page-based URL handling is
-enabled by default and requires proper URL Rewrite Rules from the server.
-
-The slug field is shown when editing page records in the backend and is
-resolved to the page uid in the frontend if a "Site configuration" in the
-site module has been set up.
-
-Note: Page-based URL handling only works if a Site configuration
-has been set up since otherwise neither the domain nor the language can
-be properly resolved which is a requirement to resolve the page path part
-of the URL.
-
-Note #2: If a page has the path segment "/team/about-us", but there is no
-other page with a path segment "/team/about-us/", then an automatic 307
-HTTP redirect to the proper URI is triggered.
-
-Impact
-======
-
-Integrators should configure their sites in the Sites module to take advantage
-of the core internal page based routing.
-
-.. index:: Backend, Database, Frontend, TCA
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-85991-ExcludeSymfonyCommandsFromScheduler.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-85991-ExcludeSymfonyCommandsFromScheduler.rst
deleted file mode 100644 (file)
index 1495b7b..0000000
+++ /dev/null
@@ -1,43 +0,0 @@
-.. include:: ../../Includes.txt
-
-=========================================================
-Feature: #85991 - Exclude Symfony Commands from Scheduler
-=========================================================
-
-See :issue:`85991`
-
-Description
-===========
-
-TYPO3's Scheduler system extension added a feature to call a Symfony / command repeatedly, however
-it is very helpful if an extension author can decide to explicitly define a command to be
-"non-schedulable" like the installation of an extension or the listing of syslog information which
-act as helpers on the command line.
-
-This feature is the equivalent to Extbase's `@cli` annotation for command controllers, and thus
-finishes the Scheduler integration for Symfony commands in TYPO3.
-
-
-Impact
-======
-
-A registered Symfony command can now have a new option :php:`schedulable` which can be set to
-:php:`false` for commands that should only be executed specifically by TYPO3's CLI interface.
-
-The default value is :php:`true` which means that every Symfony command can be used in the Scheduler.
-
-An example file within :file:`EXT:myextension/Configuration/Commands.php` could look like this:
-
-.. code-block:: php
-
-       return [
-           'admins:delete' => [
-               'class' => \ACME\MyExtension\Command\DeleteAllAdministratorsCommand::class,
-               'schedulable' => false,
-           ]
-       ];
-
-The command could still be executed via :bash:`.../typo3 admins:delete` but not be set up as
-Scheduler task in the TYPO3 backend.
-
-.. index:: CLI, ext:scheduler
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-86001-RegularWorkspaceCleanupTasksAvailableViaCLICommands.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-86001-RegularWorkspaceCleanupTasksAvailableViaCLICommands.rst
deleted file mode 100644 (file)
index 12bcb1f..0000000
+++ /dev/null
@@ -1,30 +0,0 @@
-.. include:: ../../Includes.txt
-
-============================================================================
-Feature: #86001 - Regular Workspace cleanup tasks available via CLI commands
-============================================================================
-
-See :issue:`86001`
-
-Description
-===========
-
-TYPO3 now supports two new symfony-based commands to trigger regular tasks, which were previously only
-available when the scheduler component was available.
-
-* typo3/sysext/core/bin/typo3 workspace:autopublish
-
-Checks for workspaces with auto-publishing configured and does a publishing/swapping process.
-
-* typo3/sysext/core/bin/typo3 cleanup:previewlinks
-
-Removes expired previewlinks stored within `sys_preview` from the database.
-
-
-Impact
-======
-
-It is possible to execute these commands from the CLI context without having to install the scheduler extension
-and to create a scheduler task for that.
-
-.. index:: CLI, ext:workspaces
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-86003-AdminpanelCompositionApi.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-86003-AdminpanelCompositionApi.rst
deleted file mode 100644 (file)
index f3c87ce..0000000
+++ /dev/null
@@ -1,505 +0,0 @@
-.. include:: ../../Includes.txt
-
-==========================================================
-Feature: #86003 - Composition based API for the Adminpanel
-==========================================================
-
-See :issue:`86003`
-
-Description
-===========
-
-A new API to extend the adminpanel for extension authors has been introduced.
-Enabling future enhancements for the adminpanel without having to make breaking changes for existing module providers
-is a key ingredient for providing a future proof extensible solution. Using single big interfaces that need to change on
-updates break backwards compatibility and do not provide sufficient feature encapsulation.
-
-The adminpanel APIs have been refactored to use a composition pattern to allow modules more flexibility. Modules can now only
-implement the interfaces they need instead of implementing all functionality. For example an adminpanel module that only provides
-page related settings does no longer have to implement the getContent method.
-
-Small interfaces have been provided as building blocks for modules with rich functionality. Easy addition of new interfaces that _can_ (not
-must) be implemented allow future improvements.
-
-Additionally the API has been modified to allow a more object-oriented approach using simple DTOs instead of associative arrays for better
-type-hinting and a better developer experience. Storing and rendering data have been separated in two steps allowing to completely disconnect
-the rendered adminpanel from the current page. This can be used as a base for building a complete standalone adminpanel without API changes.
-
-General Request Flow and the Adminpanel
-=======================================
-
-To better understand how the adminpanel stores and renders data, let's take a short look at how the adminpanel is initialized and rendered.
-
-Since TYPO3 v9 TYPO3 uses PSR-15 middlewares. The adminpanel brings three that are relevant to its rendering process:
-
-- `AdminPanelInitiator` - Called early in the request stack to allow initialisation of modules to catch most of the request data (for example log entries)
-- `AdminPanelDataPersister` - Called at nearly the end of a frontend request to store the collected data (this is where module data gets saved)
-- `AdminPanelRenderer` - Called as one of the last steps in the rendering process, currently replacing the closing body tag with its own code (this is where module content gets rendered)
-
-When building own modules keep in mind at which step your modules` methods get called. In the last step for example (the rendering), you should not depend on any data outside of
-that provided to the module directly (for example do not rely on `$GLOBALS` to be filled).
-
-Current Design Considerations
-------------------------------
-
-While the API of the adminpanel is very flexible in combining interfaces, the UI has a fixed structure and therefor a few things to consider when implementing own modules.
-
-- The bottom bar of the adminpanel will only be rendered for modules that have submodules and implement the `SubmoduleProviderInterface`
-- ShortInfo (see below) is only displayed for "TopLevel" modules
-- Content is only rendered for submodules
-
-
-How-To add own modules
-======================
-
-Adding custom adminpanel modules always follows these steps:
-
-1. Create a class implementing the basic `ModuleInterface`
-2. Register the class in `ext_localconf.php`
-3. Implement further interfaces for additional capabilities
-
-
-1. Create module class
-----------------------
-
-To create your own admin panel module, create a new PHP class implementing `\TYPO3\CMS\Adminpanel\ModuleApi\ModuleInterface`.
-The interface denotes your class as an adminpanel module and requires the implementation of `getIdentifier` and `getLabel` as a minimum
-of methods for a module.
-
-2. Register your module
-------------------------
-
-Displayed as a top level module:
-++++++++++++++++++++++++++++++++
-
-Register your module by adding the following in your `ext_localconf.php`::
-
-    $GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['adminpanel']['modules']['mynamespace_modulename'] => [
-        'module' => \Your\Namespace\Adminpanel\Modules\YourModule::class,
-        'before' => ['cache'],
-    ];
-
-via `before` or `after` you can influence where your module will be displayed in the module menu by referencing the
-identifier / array key of other modules.
-
-Displayed as a sub module:
-++++++++++++++++++++++++++
-
-Register your module by adding the following in your `ext_localconf.php`::
-
-    $GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['adminpanel']['modules']['info']['submodules']['mynamespace_modulename'] => [
-        'module' => \Your\Namespace\Adminpanel\Modules\YourModule::class
-    ];
-
-Note the `submodules` key in the array allowing you to introduce hierarchical configuration.
-
-
-3. Add additional interfaces
-----------------------------
-
-Your module is currently registered but is not doing anything yet, as it has no additional capabilities. The adminpanel provides additional
-separate interfaces (see list below). By implementing multiple interfaces you have fine-grained control over how your module behaves, which
-data it stores and how it gets rendered.
-
-Adminpanel Interfaces
-=====================
-
-ModuleInterface
----------------
-
-Purpose
-+++++++
-Base interface all adminpanel modules share, defines common methods.
-
-Methods
-+++++++
-
-- `getIdentifier` - Returns `string` identifier of a module (for example `mynamespace_modulename`)
-- `getLabel` - Returns speaking label of a module (for example `My Module`)
-
-
-ConfigurableInterface
----------------------
-
-Purpose
-+++++++
-Used to indicate that an adminpanel module can be enabled or disabled via configuration
-
-Methods
-+++++++
-
-- `isEnabled` - Returns `bool` depending on whether the module is enabled.
-
-Example implementation
-++++++++++++++++++++++
-
- `\TYPO3\CMS\Adminpanel\ModuleApi\AbstractModule::isEnabled`::
-
-    /**
-     * Returns true if the module is
-     * -> either enabled via TSConfig admPanel.enable
-     * -> or any setting is overridden
-     * override is a way to use functionality of the admin panel without displaying the panel to users
-     * for example: hidden records or pages can be displayed by default
-     *
-     * @return bool
-     */
-    public function isEnabled(): bool
-    {
-        $identifier = $this->getIdentifier();
-        $result = $this->isEnabledViaTsConfig();
-        if ($this->mainConfiguration['override.'][$identifier] ?? false) {
-            $result = (bool)$this->mainConfiguration['override.'][$identifier];
-        }
-        return $result;
-    }
-
-
-
-ContentProviderInterface
-------------------------
-
-Purpose
-+++++++
-Adminpanel interface to denote that a module has content to be rendered
-
-Methods
-+++++++
-
-- `getContent(ModuleData $data)` - Return content as HTML. For modules implementing the `DataProviderInterface`
-the "ModuleData" object is automatically filled with the stored data - if
-no data is given a "fresh" ModuleData object is injected.
-
-Example implementation
-++++++++++++++++++++++
-
- `\TYPO3\CMS\Adminpanel\Modules\Debug\QueryInformation::getContent`::
-
-    public function getContent(ModuleData $data): string
-    {
-        $view = new StandaloneView();
-        $view->setTemplatePathAndFilename(
-            'typo3/sysext/adminpanel/Resources/Private/Templates/Modules/Debug/QueryInformation.html'
-        );
-        $this->getLanguageService()->includeLLFile('EXT:adminpanel/Resources/Private/Language/locallang_debug.xlf');
-        $view->assignMultiple($data->getArrayCopy());
-        return $view->render();
-    }
-
-
-DataProviderInterface
-------------------------
-
-Purpose
-+++++++
-Adminpanel interface to denote that a module provides data to be stored for the current request.
-
-Adminpanel modules can save data to the adminpanel request cache and access this data in the rendering process.
-Data necessary for rendering the module content has to be returned via this interface implementation, as this allows
-for separate data collection and rendering and is a pre-requisite for a standalone debug tool.
-
-Methods
-+++++++
-
-- `getDataToStore(ServerRequestInterface $request): ModuleData` - Return a `ModuleData` instance with the data to store
-
-Example implementation
-++++++++++++++++++++++
-
- `\TYPO3\CMS\Adminpanel\Modules\Info\RequestInformation::getDataToStore`::
-
-    public function getDataToStore(ServerRequestInterface $request): ModuleData
-    {
-        return new ModuleData(
-            [
-                'post' => $_POST,
-                'get' => $_GET,
-                'cookie' => $_COOKIE,
-                'session' => $_SESSION,
-                'server' => $_SERVER,
-            ]
-        );
-    }
-
-InitializableInterface
-------------------------
-
-Purpose
-+++++++
-Adminpanel interface to denote that a module has tasks to perform on initialization of the request.
-
-Modules that need to set data / options early in the rendering process to be able to collect data, should implement
-this interface - for example the log module uses the initialization to register the adminpanel log collection early
-in the rendering process.
-
-Initialize is called in the PSR-15 middleware stack through adminpanel initialisation via the AdminPanel MainController.
-
-Methods
-+++++++
-
-- `initializeModule(ServerRequestInterface $request)` - Called on adminpanel initialization
-
-Example implementation
-++++++++++++++++++++++
-
- `\TYPO3\CMS\Adminpanel\Modules\CacheModule::initializeModule`::
-
-    public function initializeModule(ServerRequestInterface $request): void
-    {
-        if ($this->configurationService->getConfigurationOption('cache', 'noCache')) {
-            $this->getTypoScriptFrontendController()->set_no_cache('Admin Panel: No Caching', true);
-        }
-    }
-
-
-ModuleSettingsProviderInterface
--------------------------------
-
-Purpose
-+++++++
-Adminpanel module settings interface denotes that a module has own settings.
-
-The adminpanel knows two types of settings:
-- ModuleSettings are relevant for the module itself and its representation (for example the log module provides settings
-  where displayed log level and grouping of the module can be configured)
-- PageSettings are relevant for rendering the page (for example the preview module provides settings showing or hiding
-  hidden content elements or simulating a specific rendering time)
-
-If a module provides settings relevant to its own content, use this interface.
-
-Methods
-+++++++
-
-- `getSettings(): string` - Return settings as rendered HTML form elements
-
-Example implementation
-++++++++++++++++++++++
-
- `\TYPO3\CMS\Adminpanel\Modules\TsDebug\TypoScriptWaterfall::getSettings`::
-
-    public function getSettings(): string
-    {
-        $view = GeneralUtility::makeInstance(StandaloneView::class);
-        $templateNameAndPath = 'EXT:adminpanel/Resources/Private/Templates/Modules/TsDebug/TypoScriptSettings.html';
-        $view->setTemplatePathAndFilename(GeneralUtility::getFileAbsFileName($templateNameAndPath));
-        $view->setPartialRootPaths(['EXT:adminpanel/Resources/Private/Partials']);
-
-        $view->assignMultiple(
-            [
-                'tree' => (int)$this->getConfigurationOption('tree'),
-                ...
-            ]
-        );
-
-        return $view->render();
-    }
-
-
-OnSubmitActorInterface
------------------------
-
-Purpose
-+++++++
-Adminpanel interface for modules that need to react on changed configuration
-(for example if fluid debug settings change, the frontend cache should be cleared).
-
-OnSubmitActors are currently called upon persisting new configuration _before_ the page is reloaded.
-
-Methods
-+++++++
-
-- `onSubmit(array $configurationToSave, ServerRequestInterface $request)` - Can act when configuration gets saved. Configuration form vars are provided in `$configurationToSave` as an array.
-
-Example implementation
-++++++++++++++++++++++
-
- `\TYPO3\CMS\Adminpanel\Modules\PreviewModule::onSubmit`::
-
-    /**
-     * Clear page cache if fluid debug output setting is changed
-     *
-     * @param array $input
-     * @param ServerRequestInterface $request
-     * @throws \TYPO3\CMS\Core\Cache\Exception\NoSuchCacheException
-     */
-    public function onSubmit(array $input, ServerRequestInterface $request): void
-    {
-        $activeConfiguration = (int)$this->getConfigOptionForModule('showFluidDebug');
-        if (isset($input['preview_showFluidDebug']) && (int)$input['preview_showFluidDebug'] !== $activeConfiguration) {
-            $pageId = (int)$request->getParsedBody()['TSFE_ADMIN_PANEL']['preview_clearCacheId'];
-            $cacheManager = GeneralUtility::makeInstance(CacheManager::class);
-            $cacheManager->getCache('cache_pages')->flushByTag('pageId_' . $pageId);
-            $cacheManager->getCache('fluid_template')->flush();
-        }
-    }
-
-
-
-PageSettingsProviderInterface
------------------------------
-
-Purpose
-+++++++
-
-Adminpanel page settings interface denotes that a module has settings regarding the page rendering.
-
-The adminpanel knows two types of settings:
-- ModuleSettings are relevant for the module itself and its representation (for example the log module provides settings
-  where displayed log level and grouping of the module can be configured)
-- PageSettings are relevant for rendering the page (for example the preview module provides settings showing or hiding
-  hidden content elements or simulating a specific rendering time)
-
-If a module provides settings changing the rendering of the main page request, use this interface.
-
-Methods
-+++++++
-
-- `getSettings(): string` - Return HTML form elements for settings
-
-Example implementation
-++++++++++++++++++++++
-
- `\TYPO3\CMS\Adminpanel\Modules\EditModule::getPageSettings`::
-
-    public function getPageSettings(): string
-    {
-        $editToolbarService = GeneralUtility::makeInstance(EditToolbarService::class);
-        $toolbar = $editToolbarService->createToolbar();
-        $view = GeneralUtility::makeInstance(StandaloneView::class);
-        $templateNameAndPath = 'EXT:adminpanel/Resources/Private/Templates/Modules/Settings/Edit.html';
-        $view->setTemplatePathAndFilename(GeneralUtility::getFileAbsFileName($templateNameAndPath));
-        $view->setPartialRootPaths(['EXT:adminpanel/Resources/Private/Partials']);
-        $view->assignMultiple(
-            [
-                'feEdit' => ExtensionManagementUtility::isLoaded('feedit'),
-                ...
-            ]
-        );
-        return $view->render();
-
-
-PageSettingsProviderInterface
------------------------------
-
-Purpose
-+++++++
-
-Adminpanel interface to denote that a module has own resource files.
-
-An adminpanel module implementing this interface may deliver custom JavaScript and Css files to provide additional
-styling and JavaScript functionality
-
-Methods
-+++++++
-
-- `getJavaScriptFiles(): array` - Returns a string array with javascript files that will be rendered after the module
-- `getCssFiles(): array` - Returns a string array with CSS files that will be rendered after the module
-
-Example implementation
-++++++++++++++++++++++
-
- `\TYPO3\CMS\Adminpanel\Modules\TsDebugModule`::
-
-    public function getJavaScriptFiles(): array
-    {
-        return ['EXT:adminpanel/Resources/Public/JavaScript/Modules/TsDebug.js'];
-    }
-
-    public function getCssFiles(): array
-    {
-        return [];
-    }
-
-
-ShortInfoProviderInterface
------------------------------
-
-Purpose
-+++++++
-
-Adminpanel shortinfo provider interface can be used to add the module to the short info bar of the adminpanel.
-
-Modules providing shortinfo will be displayed in the bottom bar of the adminpanel and may provide "at a glance" info
-about the current state (for example the log module provides the number of warnings and errors directly).
-
-Be aware that modules with submodules at the moment can only render one short info (the one of the "parent" module).
-This will likely change in v10.
-
-Methods
-+++++++
-
-- `getShortInfo(): string` - Info string (no HTML) that should be rendered
-- `getIconIdentifier(): string` - An icon for this info line, needs to be registered in `IconRegistry`
-
-Example implementation
-++++++++++++++++++++++
-
- `\TYPO3\CMS\Adminpanel\Modules\InfoModule`::
-
-    public function getShortInfo(): string
-    {
-        $parseTime = $this->getTimeTracker()->getParseTime();
-        return sprintf($this->getLanguageService()->sL(
-            'LLL:EXT:adminpanel/Resources/Private/Language/locallang_info.xlf:module.shortinfo'
-        ), $parseTime);
-    }
-
-    public function getIconIdentifier(): string
-    {
-        return 'actions-document-info';
-    }
-
-
-
-SubmoduleProviderInterface
------------------------------
-
-Purpose
-+++++++
-
- Adminpanel interface providing hierarchical functionality for modules.
-
- A module implementing this interface may have submodules. Be aware that the current implementation of the adminpanel
- renders a maximum level of 2 for modules. If you need to render more levels, write your own module and implement
- multi-hierarchical rendering in the getContent method.
-
-Methods
-+++++++
-
-- `setSubModules(array $subModules)` - Sets array of module instances (instances of `ModuleInterface`) as submodules
-- `getSubModules(): array` - Returns an array of module instances
-- `hasSubmoduleSettings(): bool` - Return true if any of the submodules has settings to be rendered (can be used to render settings in a central place)
-
-Example implementation
-++++++++++++++++++++++
-
- `\TYPO3\CMS\Adminpanel\ModuleApi\AbstractModule`::
-
-
-    public function setSubModules(array $subModules): void
-    {
-        $this->subModules = $subModules;
-    }
-
-    public function getSubModules(): array
-    {
-        return $this->subModules;
-    }
-
-    public function hasSubmoduleSettings(): bool
-    {
-        $hasSettings = false;
-        foreach ($this->subModules as $subModule) {
-            if ($subModule instanceof ModuleSettingsProviderInterface) {
-                $hasSettings = true;
-                break;
-            }
-            if ($subModule instanceof SubmoduleProviderInterface) {
-                $hasSettings = $subModule->hasSubmoduleSettings();
-            }
-        }
-        return $hasSettings;
-    }
-
-
-.. index:: Frontend, PHP-API, ext:adminpanel
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-86051-ShowExtensionsViaCLI.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-86051-ShowExtensionsViaCLI.rst
deleted file mode 100644 (file)
index 76efb0c..0000000
+++ /dev/null
@@ -1,28 +0,0 @@
-.. include:: ../../Includes.txt
-
-=========================================
-Feature: #86051 - Show extensions via CLI
-=========================================
-
-See :issue:`86051`
-
-Description
-===========
-
-A new command `extension:list` is added, which can be executed via Command Line
-`typo3/sysext/core/bin/typo3 extension:list`.
-
-This command shows all currently installed (= active) extensions. The option `--all`
-also includes all inactive extensions. If only the list of inactive extensions should
-be shown, the command `--inactive` will show only the extensions available for installation.
-
-Additional description of the extensions can be shown by --verbose / -v.
-
-
-Impact
-======
-
-In order to show which extensions can be uninstalled or installed via CLI, the new command
-is a good companion for the existing commands `extension:activate` and `extension:deactivate`.
-
-.. index:: CLI, ext:core
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-86066-CLICommandsForListingAndShowingSites.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-86066-CLICommandsForListingAndShowingSites.rst
deleted file mode 100644 (file)
index eddfa53..0000000
+++ /dev/null
@@ -1,30 +0,0 @@
-.. include:: ../../Includes.txt
-
-============================================================
-Feature: #86066 - CLI Commands for listing and showing sites
-============================================================
-
-See :issue:`86066`
-
-Description
-===========
-
-Two new CLI commands have been added:
--  `site:list`
--  `site:show`
-
-The list command can be executed via `typo3/sysext/core/bin/typo3 site:list` and will list all
-configured sites with their configured Identifier, root page, base URL, languages, locales and
-a flag whether or not the site is enabled.
-
-The show command can be executed via `typo3/sysext/core/bin/typo3 site:show <identifier>`.
-It needs an identifier of a configured site which must be provided after the command name.
-The command will output the complete configuration for the site in the YAML syntax.
-
-
-Impact
-======
-
-Reading access to the configured sites and their detailed configuration is now possible from CLI.
-
-.. index:: CLI, ext:core
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Important-84280-UnitTestSuppressNoticesRemoved.rst b/typo3/sysext/core/Documentation/Changelog/master/Important-84280-UnitTestSuppressNoticesRemoved.rst
deleted file mode 100644 (file)
index 1ac8935..0000000
+++ /dev/null
@@ -1,22 +0,0 @@
-.. include:: ../../Includes.txt
-
-=====================================================
-Important: #84280 - Unit test suppressNotices removed
-=====================================================
-
-See :issue:`84280`
-
-Description
-===========
-
-The property :php:`$suppressNotices` available for unit tests extending class
-:php:`UnitTestCase` has been removed. Unit tests that trigger :php:`E_NOTICE`
-level errors will now fail.
-
-The property has been introduced with core v9.2 and has been removed with v9.4
-after no core unit tests used that flag anymore.
-
-If extensions use the typo3/testing-framework for testing, they now may have
-to fix their tests or system under test to not throw notices, either.
-
-.. index:: PHP-API, FullyScanned
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Important-84623-ConfigurationFilesMovedFromTypo3confToConfigDirectory.rst b/typo3/sysext/core/Documentation/Changelog/master/Important-84623-ConfigurationFilesMovedFromTypo3confToConfigDirectory.rst
deleted file mode 100644 (file)
index 85887c6..0000000
+++ /dev/null
@@ -1,38 +0,0 @@
-.. include:: ../../Includes.txt
-
-====================================================================================
-Important: #84623 - Configuration files moved from "typo3conf" to "config" directory
-====================================================================================
-
-See :issue:`84623`
-
-Description
-===========
-
-The TYPO3 configuration files for instances running in Composer Mode or having the environment
-variable `TYPO3_PATH_APP` set to a different location than :php:`PATH_site`, have been moved from
-the :file:`<web-dir>/typo3conf` to the :file:`config` directory.
-
-The following files are affected:
-
-- :file:`LocalConfiguration.php`
-- :file:`AdditionalConfiguration.php`
-- :file:`AdditionalFactoryConfiguration.php`
-
-The first access to the TYPO3 frontend or backend will redirect to the Install Tool which
-automatically creates the :file:`config` directory and moves all of the affected files currently
-present in :file:`<web-dir>/typo3conf` to :file:`config`. Afterwards backend and frontend are
-accessible as usual.
-
-Using the environment variable `TYPO3_PATH_APP` allows for storing relevant code like configuration
-outside of the document root / Composer `<web-dir>`. This effectively hardens a TYPO3 instance,
-as less files are accessible in public. All new installations in Composer Mode use this setup by
-default. Installations in Classic Mode (without Composer setup) will continue to use the previous
-setup since it cannot be ensured that they have access outside of the document root.
-
-If you have a setup with a $GLOBALS['TYPO3_CONF_VARS']['SYS']['trustedHostsPattern'] set, please
-go to the install tool first. The migration is done automatically and you can just go to the backend
-afterwards. If you have not set your trustedHostsPattern, you will be redirected automatically and
-you don't have to do anything.
-
-.. index:: LocalConfiguration
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Important-85196-RemovedSimulateUserFromUserSettings.rst b/typo3/sysext/core/Documentation/Changelog/master/Important-85196-RemovedSimulateUserFromUserSettings.rst
deleted file mode 100644 (file)
index 513554f..0000000
+++ /dev/null
@@ -1,27 +0,0 @@
-.. include:: ../../Includes.txt
-
-============================================================
-Important: #85196 - Removed simulate user from user settings
-============================================================
-
-See :issue:`85196`
-
-Description
-===========
-
-The user settings module that can be reached from the backend toolbar in
-the drop down behind the logged in user name had a functionality to
-show user settings of another backend user for admins.
-
-This simulate user switch has been dropped from the interface.
-
-Admins who want to check or change settings of other users should fully
-switch to the target user using the "Switch to user" of the "Backend users"
-module and then navigate to its user settings.
-
-Backend administrators who need to often change other backend user settings
-should consider using adapted User TSconfig :ts:`setup.` details to reduce
-streamline this workflow.
-
-
-.. index:: Backend, ext:setup
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Important-85393-ExtensionManagerOnlyImportsExtensionsCompatibleWithTYPO3V7LTSOrHigher.rst b/typo3/sysext/core/Documentation/Changelog/master/Important-85393-ExtensionManagerOnlyImportsExtensionsCompatibleWithTYPO3V7LTSOrHigher.rst
deleted file mode 100644 (file)
index 343515b..0000000
+++ /dev/null
@@ -1,23 +0,0 @@
-.. include:: ../../Includes.txt
-
-====================================================================================================
-Important: #85393 - Extension Manager only imports extensions compatible with TYPO3 v7 LTS or higher
-====================================================================================================
-
-See :issue:`85393`
-
-Description
-===========
-
-The extension manager now includes a restriction when updating the list of current extensions
-within TER that have been uploaded later than November 10th, 2015 - the release of
-TYPO3 v7 LTS (7.6.0).
-
-This ensures that the database is drastically reduced, resulting in smaller footprint for the
-database and faster updating / searching / browsing the list of available extensions within the
-Extension Manager.
-
-Installing extensions older than this date is still possible by manually downloading an extension
-and importing it via a ZIP file or by uploading it into `typo3conf/ext/[extension_name]`.
-
-.. index:: ext:extensionmanager
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Important-85683-DroppedSaltedpasswordOptions.rst b/typo3/sysext/core/Documentation/Changelog/master/Important-85683-DroppedSaltedpasswordOptions.rst
deleted file mode 100644 (file)
index 004ab8e..0000000
+++ /dev/null
@@ -1,40 +0,0 @@
-.. include:: ../../Includes.txt
-
-====================================================
-Important: #85683 - Dropped salted passwords options
-====================================================
-
-See :issue:`85683`
-
-Description
-===========
-
-Some extension configuration of the salted passwords extension has been dropped:
-
-- FE.forceSalted and BE.forceSalted
-  By explicitly setting forceSalted to 1 (default 0) in the saltedpasswords extension configuration it was possible to
-  deny login of users who had not stored their password as salted password yet. This option has been removed.
-  User who have been upgraded to salted passwords using the "Convert user passwords to salted hashes" from
-  core version 8 are still able to login and will get their passwords updated to the configured salted password
-  mechanism upon first successful login. This upgrade will be dropped in core version 10. Other non salted passwords
-  mechanisms (simple md5 or plaintext) will however lead to a failed login. Administrators who did not yet upgrade
-  their user base to salted passwords must perform the "Convert user passwords to salted hashes" in core
-  version 7 or version 8 before upgrading to v9.
-
-- FE.updatePasswd and BE.updatePasswd
-  By explicitly setting updatePasswd to 0 (default 1) in the saltedpasswords extension configuration it was possible
-  to avoid updating a given hashed password to the currently configured hash algorithm, but still allow login. This option has
-  been dropped: A user submitting a valid password using an old salted passwords algorithm that is no longer configured
-  as current salted passwords algorithm will always get his password updated and stored using the currently
-  configured password salt.
-
-- FE.onlyAuthService and BE.onlyAuthService
-  By explicitly setting onlyAuthService to 1 (default 0), it was possible to deny any further authentication service
-  to successfully validate a user. This setting is mostly useless since any different authentication service is usually
-  configured to kick in before the native TYPO3 internal authentication service. It does not make sense to have this toggle
-  and a search in open extensions revealed no usage. On upgrading to v9, if you are running additional authentication services,
-  please verify those have a higher priority than the default :php:`SaltedPasswordService`, action is only needed if
-  additionally onlyAuthService has been set to 1 in salted passwords configuration, which is probably never the case.
-
-
-.. index:: Backend, Database, Frontend, ext:saltedpasswords
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Important-85719-PHPPackagesSymfonyComponentsRequirementsRaisedToSymfony41.rst b/typo3/sysext/core/Documentation/Changelog/master/Important-85719-PHPPackagesSymfonyComponentsRequirementsRaisedToSymfony41.rst
deleted file mode 100644 (file)
index 7eb2366..0000000
+++ /dev/null
@@ -1,33 +0,0 @@
-.. include:: ../../Includes.txt
-
-=======================================================================================
-Important: #85719 - PHP Packages: Symfony Components requirements raised to Symfony 4.1
-=======================================================================================
-
-See :issue:`85719`
-
-Description
-===========
-
-Due to the introduction of the PHP requirement of `symfony/routing` with a minimum requirement of
-version 4.1, all other Symfony Components have been raised to have at least 4.1 as well.
-
-This includes the following symfony components:
-* symfony/finder
-* symfony/console
-* symfony/yaml
-* symfony/expression-language
-
-This is due to the usage of `symfony/routing`, which is a must-have for TYPO3 for Route Matching,
-which has been heavily improved in version 4.1 performance-wise. As TYPO3 should have the best experience
-with routing, it is critical to use at least 4.1, and no version lower than that.
-
-If a composer-based TYPO3 installation depends on a package that is not compatible with
-symfony components lower than 4.1, it is not possible to upgrade TYPO3 to v9.4 without fixing other
-requirements.
-
-In this case, evaluate if other third-party packages can be upgraded to be compatible with
-Symfony 4.1 components and require newer versions of these packages, or open up a support ticket
-in the respective package project website to ensure compatibility with newer symfony versions.
-
-.. index:: PHP-API
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Important-85833-SaltedpasswordsExtensionMergedIntoCoreExtension.rst b/typo3/sysext/core/Documentation/Changelog/master/Important-85833-SaltedpasswordsExtensionMergedIntoCoreExtension.rst
deleted file mode 100644 (file)
index 88ac12c..0000000
+++ /dev/null
@@ -1,34 +0,0 @@
-.. include:: ../../Includes.txt
-
-========================================================================
-Important: #85833 - saltedpasswords extension merged into core extension
-========================================================================
-
-See :issue:`85833`
-
-Description
-===========
-
-The previously available system extension `saltedpasswords` has been removed as its
-functionality has been merged into `core`. All functionality is still available but
-renamed related to a better Hashing API.
-
-This resolves a hard cross-dependency between `EXT:core` and `EXT:saltedpasswords`
-since TYPO3 v6 as it was a sane default to properly use password hashes.
-
-Backwards compatibility is given by automatic upgrades of settings when visiting
-the Install Tool.
-
-For composer-based installations this means the dependency to `typo3/cms-saltedpasswords`
-can safely be removed via `composer remove typo3/cms-saltedpasswords`, although this is
-not mandatory due to the fact that `typo3/cms-core` is noted as a replacement for
-saltedpasswords in its composer.json file.
-
-In some edge-cases for non-composer-based installations it might be necessary to remove
-the `saltedpasswords` entry from :php:`typo3conf/PackagesStates.php`.
-
-Any checks for :php:`ExtensionManagementUtility::isLoaded('saltedpasswords')` in
-third-party extensions which were not necessary (as saltedpasswords had to be installed
-at any time anyways), can safely be removed.
-
-.. index:: Backend, NotScanned, ext:saltedpasswords
\ No newline at end of file
index 20d61d3..d8418fd 100644 (file)
@@ -45,6 +45,13 @@ use TYPO3Fluid\Fluid\Core\ViewHelper\Traits\CompileWithRenderStatic;
  * (depending on the value of {someNumber})
  * </output>
  *
+ * <code title="use dash for decimals without value">
+ * <f:format.currency useDash="true">123.00</f:format.currency>
+ * </code>
+ * <output>
+ * 123,-
+ * </output>
+ *
  * @api
  */
 class CurrencyViewHelper extends AbstractViewHelper