TYPO3 v15 dev-main snapshot ()

Documentation/Changelog/7.3/Breaking-62983-PostProcessMirrorUrlSignalHasMoved.rst

@@ -0,0 +1,52 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-62983:
+
+========================================================
+Breaking: #62983 - postProcessMirrorUrl signal has moved
+========================================================
+
+See :issue:`62983`
+
+Description
+===========
+
+While refactoring the Language backend module, the
+`\TYPO3\CMS\Lang\Service\UpdateTranslationService::postProcessMirrorUrl` signal got lost. Due to
+the refactoring, it has been integrated in another class.
+
+
+Impact
+======
+
+Using the old signal will prevent the slot from being called.
+
+
+Affected Installations
+======================
+
+All extensions are affected that use the old
+`\TYPO3\CMS\Lang\Service\UpdateTranslationService::postProcessMirrorUrl`
+signal.
+
+
+Migration
+=========
+
+Change the slot to use the `\TYPO3\CMS\Lang\Service\TranslationService::postProcessMirrorUrl`
+signal. If it is required to serve multiple TYPO3 versions, use the following code:
+
+.. code-block:: php
+
+	$signalSlotDispatcher->connect(
+		version_compare(TYPO3_version, '7.0', '<')
+			? 'TYPO3\\CMS\\Lang\\Service\\UpdateTranslationService'
+			: 'TYPO3\\CMS\\Lang\\Service\\TranslationService',
+		'postProcessMirrorUrl',
+		'Vendor\\Extension\\Slots\\CustomMirror',
+		'postProcessMirrorUrl'
+	);
+
+
+.. index:: PHP-API, Backend, ext:lang

Documentation/Changelog/7.3/Breaking-63453-ChangedRenderingOfFlashMessagesViewHelper.rst

@@ -0,0 +1,51 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-63453:
+
+===============================================================
+Breaking: #63453 - Changed rendering of FlashMessagesViewHelper
+===============================================================
+
+See :issue:`63453`
+
+Description
+===========
+
+The default (`renderMode="ul"`) rendering output of the `FlashMessagesViewHelper` has been changed.
+
+By default the view helper rendered an unordered list, each list item containing one message.
+This output has been adjusted and more markup has been added.
+
+
+Impact
+======
+
+You may see unexpected formatting of flash messages.
+
+
+Affected Installations
+======================
+
+Any template using the `FlashMessagesViewHelper` unless the attribute `renderMode` is set to "div".
+Be aware that the `renderMode` attribute has been deprecated.
+
+
+Migration
+=========
+
+Add a custom rendering template for the flash messages, like outlined in the example, to obtain the same output
+as before.
+
+.. code-block:: html
+
+	<f:flashMessages as="flashMessages">
+		<ul class="myFlashMessages">
+			<f:for each="{flashMessages}" as="flashMessage">
+				<li>{flashMessage.message}</li>
+			</f:for>
+		</ul>
+	</f:flashMessages>
+
+
+.. index:: Fluid

Documentation/Changelog/7.3/Breaking-63835-RemoveDeprecatedExtbasePersistenceParts.rst

@@ -0,0 +1,26 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-63835:
+
+=======================================================================
+Breaking: #63835 - Remove Deprecated Parts in Extbase Persistence Layer
+=======================================================================
+
+See :issue:`63835`
+
+Description
+===========
+
+The previously deprecated functions `TYPO3\CMS\Extbase\Persistence\Generic\Backend->setDeletedObjects()` and
+`TYPO3\CMS\Extbase\Persistence\Repository->replace()` inside the Persistence Layer of Extbase have been removed.
+The protected property "session" inside `TYPO3\CMS\Extbase\Persistence\Repository` has been removed as well.
+
+
+Impact
+======
+
+Any direct calls to the methods will now exit with a PHP Fatal Error.
+
+
+.. index:: PHP-API, ext:extbase

Documentation/Changelog/7.3/Breaking-63846-FormEngineRefactoring.rst

@@ -0,0 +1,93 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-63846:
+
+=========================================
+Breaking: #63846 - FormEngine refactoring
+=========================================
+
+See :issue:`63846`
+
+Description
+===========
+
+FormEngine is the core code structure that renders a record view in the backend. Basically everything
+that is displayed if elements from page or list module are edited is done by this code.
+
+The main implementation was done thirteen years ago and was never touched on a deep code structure level
+until now. The according patches were huge and move the whole code to a new level. Stuff like that can
+not be done without impact on extensions that use this code.
+
+
+Impact
+======
+
+TCA changes
+-----------
+
+* Keys `_PADDING`, `_VALIGN` and `DISTANCE` of `TCA['aTable']['columns']['aField']['config']['wizards']`
+  have been removed and have no effect anymore.
+
+* Key `TCA['aTable']['ctrl']['mainPalette']` has been dropped and has no effect anymore.
+
+TSconfig changes
+----------------
+
+* Key `mod.web_layout.tt_content.fieldOrder` has been dropped and has no effect anymore.
+
+* Key `TCEFORM.aTable.aField.linkTitleToSelf` has been dropped and has no effect anymore.
+
+
+Code level
+----------
+
+Methods and properties from FormEngine are not available anymore. Classes like `InlineElement` are gone.
+New structures like a factory for elements and container have been introduced.
+While not too many extensions in the wild hook or code with FormEngine, those that do will probably throw
+fatal errors after upgrade. The hook `getSingleFieldClass` has been removed altogether.
+
+Changed user functions and hooks
+--------------------------------
+
+* TCA: If format of type `none` is set to `user`, the configured userFunc no longer gets an instance of `FormEngine`
+  as parent object, but an instance of `NoneElement`.
+
+* TCA: Wizards configured as `userFunc` now receive a dummy `FormEngine` object with empty properties instead
+  of the real instance.
+
+* Hooks no longer get the key `form_type`. Use `type` instead.
+
+* Hook `getSingleFieldClass` has been dropped and no longer called.
+
+Breaking interface changes
+--------------------------
+
+* The type hint to `FormEngine` as `$pObj` has been removed on the `DatabaseFileIconsHookInterface`.
+  This hook is no longer given an instance of `FormEngine`.
+
+* Method `init()` of `InlineElementHookInterface` has been removed. Classes that implement this interface will
+  no longer get `init()` called.
+
+
+Affected installations
+======================
+
+For most instances, the overall impact is rather low or they are not affected at all. Some very
+rarely used TCA and TSconfig options have been dropped, those will do no harm. Instances are usually only affected
+if loaded extensions do fancy stuff with FormEngine with hooks or other related code.
+
+TYPO3 CMS 7 installations with extensions using or hooking into FormEngine and its related classes are
+likely to break. TCA elements of type user may break. Instances using these parts will quickly show
+fatal errors at testing. It may help to search for `FormEngine` or `t3lib_tceForms` below the `typo3conf/ext`
+directory to find affected instances.
+
+
+Migration
+=========
+
+Adapt the extension code. The majority of methods were for internal core usage only, but still public. Please
+use the existing API to solve needs on FormEngine.
+
+
+.. index:: PHP-API, Backend, TSConfig, TCA

Documentation/Changelog/7.3/Breaking-66429-RemoveIdentityMapFromPersistence.rst

@@ -0,0 +1,56 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-66429:
+
+======================================================
+Breaking: #66429 - Remove IdentityMap from persistence
+======================================================
+
+See :issue:`66429`
+
+Description
+===========
+
+The `IdentityMap` class and its usage has been removed from the Extbase persistence.
+
+
+Impact
+======
+
+Upgraded installations will throw a `ReflectionException`. Accessing the previously existing `IdentityMap`
+properties within `DataMapper` and `Repository` will now fail. Creating `IdentityMap` instances is not possible
+anymore.
+
+
+Affected Installations
+======================
+
+All installations, especially extensions using the `IdentityMap` class directly or accessing the properties within
+`DataMapper` or `Repository`.
+
+
+Migration
+=========
+
+The Extbase reflection cache of existing installations needs to be cleared once.
+
+Existing code can be migrated to the persistence `Session` class which provides a drop-in replacement for the
+`IdentityMap`.
+
+
+Usage example
+=============
+
+How to use the `Session` class to retrieve objects by an identifier:
+
+.. code-block:: php
+
+	$session = GeneralUtility::makeInstance(ObjectManager::class)->get(\TYPO3\CMS\Extbase\Persistence\Generic\Session::class);
+	$session->registerObject($object, $identifier);
+	if ($session->hasIdentifier($identifier)) {
+		$object = $session->getObjectByIdentifier($identifier, $className);
+	}
+
+
+.. index:: PHP-API, ext:extbase

Documentation/Changelog/7.3/Breaking-66669-BackendLoginControllerRefactored.rst

@@ -0,0 +1,48 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-66669:
+
+=====================================================
+Breaking: #66669 - Backend LoginController refactored
+=====================================================
+
+See :issue:`66669`
+
+Description
+===========
+
+The backend login has been completely refactored and a new API has been introduced.
+The openid form has been extracted and is now using the new API as well.
+
+
+Impact
+======
+
+All former member variables of the  `LoginController` class have been removed or made protected, together with
+some, now pointless, hooks and their related classes.
+
+The deleted hooks are:
+
+- `$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['typo3/index.php']['loginScriptHook']`
+- `$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['typo3/index.php']['loginFormHook']`
+
+The removed class and its alias:
+
+- `TYPO3\CMS\Rsaauth\Hook\LoginFormHook`
+- `tx_rsaauth_loginformhook`
+
+
+Affected Installations
+======================
+
+Any code manipulating the BE login.
+
+
+Migration
+=========
+
+Use the new backend login form API.
+
+
+.. index:: PHP-API, Backend, ext:rsaauth

Documentation/Changelog/7.3/Breaking-66707-IssueCommandNowAddsQuotesWhenUsedInJSContext.rst

@@ -0,0 +1,37 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-66707:
+
+=========================================================================
+Breaking: #66707 - issueCommand() now adds quotes when used in JS context
+=========================================================================
+
+See :issue:`66707`
+
+Description
+===========
+
+Using `\TYPO3\CMS\Backend\Template\DocumentTemplate::issueCommand()` in JavaScript context (second parameter = -1),
+now ensures that the URL is properly escaped and quoted for being used in JavaScript code.
+
+
+Impact
+======
+
+Having additional quotes around the result of the call to `issueCommand()` will lead to JavaScript errors.
+
+
+Affected Installations
+======================
+
+Any installation using third party extensions, which use `issueCommand()` with second parameter set to -1.
+
+
+Migration
+=========
+
+Make sure that you do **not** specify any additional quotes around the result of the call to `issueCommand()`.
+
+
+.. index:: PHP-API, Backend

Documentation/Changelog/7.3/Breaking-66754-RemoveRenderingContextAwareInterface.rst

@@ -0,0 +1,33 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-66754:
+
+========================================================
+Breaking: #66754 - Remove RenderingContextAwareInterface
+========================================================
+
+See :issue:`66754`
+
+Description
+===========
+
+The `RenderingContextAwareInterface` allowed objects to get the `RenderingContext` set while being
+accessed from inside a Fluid template. This makes optimization of variable access in Fluid difficult
+and seems to be an unused feature. Therefore it has been removed.
+
+Impact
+======
+
+For implementations of `RenderingContextAwareInterface` the change breaks without any simple replacement.
+Functionality would have to be replicated in userland code. But as there are no known implementations
+the expected impact is rather low.
+
+
+Breaking interface changes
+--------------------------
+
+* The `RenderingContextAwareInterface` has been removed. There is no replacement.
+
+
+.. index:: Fluid, PHP-API

Documentation/Changelog/7.3/Breaking-66868-MoveUsageOfBackendUserSettingsDataProvider.rst

@@ -0,0 +1,42 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-66868:
+
+================================================================
+Breaking: #66868 - Move usage of BackendUserSettingsDataProvider
+================================================================
+
+See :issue:`66868`
+
+Description
+===========
+
+The ExtDirect API `BackendUserSettingsDataProvider` has been removed.
+
+
+Impact
+======
+
+Third party code using either `BackendUserSettingsDataProvider` or `top.TYPO3.BackendUserSettings.ExtDirect` will fatal.
+
+
+Affected Installations
+======================
+
+Any installation using `BackendUserSettingsDataProvider` or `top.TYPO3.BackendUserSettings.ExtDirect` is affected.
+
+
+Migration
+=========
+
+In JavaScript, use `TYPO3.Storage.Persistent` API. In PHP, use `\TYPO3\CMS\Backend\Controller\UserSettingsController`:
+
+.. code-block:: php
+
+	/** @var $userSettingsController \TYPO3\CMS\Backend\Controller\UserSettingsController */
+	$userSettingsController = GeneralUtility::makeInstance(\TYPO3\CMS\Backend\Controller\UserSettingsController::class);
+	$state = $userSettingsController->process('get', 'BackendComponents.States.' . $stateId);
+
+
+.. index:: PHP-API, Backend, JavaScript

Documentation/Changelog/7.3/Breaking-66906-AutomaticPNGToGIFConversionRemoved.rst

@@ -0,0 +1,31 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-66906:
+
+==========================================================
+Breaking: #66906 - Automatic PNG to GIF conversion removed
+==========================================================
+
+See :issue:`66906`
+
+Description
+===========
+
+The configuration setting `$TYPO3_CONF_VARS[GFX][png_to_gif]` has been removed.
+
+
+Impact
+======
+
+If the option is set in an installation, then PNG images used in the TYPO3 Frontend will now be kept as PNG, instead
+of converting them to GIF files.
+
+
+Affected Installations
+======================
+
+Installations having the option `$TYPO3_CONF_VARS[GFX][png_to_gif]` activated.
+
+
+.. index:: LocalConfiguration

Documentation/Changelog/7.3/Breaking-66991-TCAValueSliderBasedOnJQuery.rst

@@ -0,0 +1,37 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-66991:
+
+===================================================
+Breaking: #66991 - TCA value slider based on jQuery
+===================================================
+
+See :issue:`66991`
+
+Description
+===========
+
+The TCA value slider has been ported from ExtJS to jQuery and Bootstrap.
+
+
+Impact
+======
+
+Since TYPO3 CMS 7 uses a DateTimePicker, the time selection conflicts with the value slider and therefore
+time-sliding has been dropped.
+
+
+Affected Installations
+======================
+
+All installations are affected whose TCA uses the value slider wizard in combination with `time` evaluation.
+
+
+Migration
+=========
+
+Remove the slider wizard from affected TCA.
+
+
+.. index:: TCA, JavaScript, Backend

Documentation/Changelog/7.3/Breaking-66997-RemoveSuper-challengedPasswordSecurity.rst

@@ -0,0 +1,57 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-66997:
+
+=============================================================
+Breaking: #66997 - Remove super-/challenged password security
+=============================================================
+
+See :issue:`66997`
+
+Description
+===========
+
+TYPO3 CMS supports four possibilities how passwords can be sent from the browser to the server:
+
+- "normal": Plain text
+- "challenged": md5 hashed
+- "superchallenged": md5 hashed
+- "rsa": asymmetric encryption
+
+Since TYPO3 CMS 6.2 the password transmission is protected by the rsaauth-extension by default ("rsa"),
+which renders the old protection mechanisms "superchallenged" and "challenged" useless.
+
+If the Backend login is accessed via HTTPS protocol, the "rsa" protection is redundant and can be disabled in general.
+
+The super-/challenged options are removed, as "rsa" and "normal" are sufficient.
+If rsaauth was not installed the default has been "superchallenged". The new default is "normal" now.
+
+
+Impact
+======
+
+If an installation has rsaauth disabled, the password transfer is now **Plain Text**.
+
+Any code relying on or checking for the "superchallenged" or "challenged" option
+of `[BE][loginSecurityLevel]` or `[FE][loginSecurityLevel]`, will not work as expected.
+
+
+Affected Installations
+======================
+
+Any installation having set `[BE][loginSecurityLevel]` or `[FE][loginSecurityLevel]` to an empty string or to
+either of "superchallenged" or "challenged".
+
+
+Migration
+=========
+
+Make sure you access the Backend via HTTPS or install the rsaauth system extension.
+
+Also refer to the `TYPO3 Security Guide`_
+
+.. _TYPO3 Security Guide: https://docs.typo3.org/typo3cms/SecurityGuide/GuidelinesAdministrators/EncryptedCommunication/Index.html
+
+
+.. index:: PHP-API, Frontend, Backend, LocalConfiguration

Documentation/Changelog/7.3/Breaking-67027-RemovedFlowCompatibilityFromPackageManager.rst

@@ -0,0 +1,43 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-67027:
+
+=================================================================
+Breaking: #67027 - Removed FLOW-compatibility from PackageManager
+=================================================================
+
+See :issue:`67027`
+
+Description
+===========
+
+The Package Manager has been simplified and trimmed down to fit the needs of the TYPO3 extensions and typical
+Composer packages. All shipped code backported from Flow was removed or refactored to be included in the TYPO3
+Core natively. Loading classes are done with the Composer class loader or by the conventions of extension namings.
+All default Composer packages can still be included as usual, however the custom Flow-logic has been removed.
+
+
+Impact
+======
+
+It is not possible to add custom Package.php loaders into TYPO3 extensions anymore to be called during runtime. It is
+not possible to configure extensions with custom `Classes/` directories and custom composer.json locations anymore.
+There is no special handling for "typo3-flow" packages anymore. The :file:`typo3conf/PackageStates.php` file now only
+contains the parts that are necessary for the TYPO3 system.
+
+
+Affected Installations
+======================
+
+All installations using custom functionality of the PackageManager not in use with the TYPO3 Core, or installations
+trying to use Flow packages natively in the TYPO3 Core.
+
+
+Migration
+=========
+
+Use Composer packages natively for class loading, or use ext_localconf.php to additionally configure a package.
+
+
+.. index:: PHP-API

Documentation/Changelog/7.3/Breaking-67204-DatabaseConnectionexec_SELECTgetRowsMayThrowException.rst

@@ -0,0 +1,42 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-67204:
+
+===============================================================================
+Breaking: #67204 - DatabaseConnection::exec_SELECTgetRows() may throw exception
+===============================================================================
+
+See :issue:`67204`
+
+Description
+===========
+
+`DatabaseConnection::exec_SELECTgetRows()` validates `$uidIndexField` parameter now.
+If the specified field is not present in the database result an `InvalidArgumentException` is thrown.
+
+
+Impact
+======
+
+This change will affect only broken usages of `DatabaseConnection::exec_SELECTgetRows()` with an invalid last
+parameter.
+
+It is very unlikely that existing code affected by this change, since using the method in a wrong way had the
+consequence that it only returned the last row from the result.
+
+
+Affected Installations
+======================
+
+Any code using the `DatabaseConnection::exec_SELECTgetRows()` method with `$uidIndexField` being set to a field
+name not present in the queried result set.
+
+
+Migration
+=========
+
+Fix your call to the method and correct the `$uidIndexField` parameter.
+
+
+.. index:: PHP-API, Database

Documentation/Changelog/7.3/Breaking-67212-DiscardLegacyClassLoader.rst

@@ -0,0 +1,63 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-67212:
+
+=============================================
+Breaking: #67212 - Discard TYPO3 class loader
+=============================================
+
+See :issue:`67212`
+
+Description
+===========
+
+The former TYPO3 class loader has been removed in favor of the composer class loader.
+
+
+Impact
+======
+
+ext_autoload.php files are **not** evaluated any more. Instead all class files are registered
+automatically during extension installation and written into a class map file. This class map file is
+not changed during regular requests, but only if the extension list changes (by using the Extension Manager).
+
+These class information files are located in the :file:`typo3temp/autoload/` directory and will also be automatically
+created if they do not exist.
+
+Non-namespaced classes with `Tx_` naming convention like `Tx_Extension_ClassName` are only resolved through
+the aforementioned class map, but not dynamically. This means that extension authors need to re-generate the class map
+files when introducing new classes. Thus it is highly recommended to use a Classes folder with PSR-4 standard class
+files in there.
+
+When installing TYPO3 with composer, it also means that all extensions need to bring their own :file:`composer.json`
+file with class loading information or the class loading information of all extensions need to be specified in the root
+:file:`composer.json` for class loading to work properly.
+
+
+Affected Installations
+======================
+
+All installations are affected.
+
+
+Migration
+=========
+
+No migration is needed during upgrade if TYPO3 is installed in the classic way.
+If TYPO3 is installed in a distribution via composer, missing class loading information need to be provided in root
+composer.json for all extensions which do not bring their own composer.json manifest.
+
+.. code-block:: json
+
+    {
+        "autoload": {
+            "psr-4": {
+                "GeorgRinger\\News\\": "typo3conf/ext/news/Classes/",
+                "MyAwesomeNamespace\\IncrediExt\\": "typo3conf/ext/incredible_extension/Resources/PHP/Libraries/lib/"
+            }
+        }
+    }
+
+
+.. index:: PHP-API

Documentation/Changelog/7.3/Breaking-67229-FormEngineRelatedClasses.rst

@@ -0,0 +1,44 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-67229:
+
+=============================================
+Breaking: #67229 - FormEngine related classes
+=============================================
+
+See :issue:`67229`
+
+
+Description
+===========
+
+With the further development of FormEngine, some minor changes on PHP level have been applied:
+
+* Class `TYPO3\CMS\T3editor\FormWizard` has been removed
+
+* Class `TYPO3\CMS\Rtehtmlarea\Controller\FrontendRteController` has been removed
+
+* The method signature of class `TYPO3\CMS\Utility\BackendUtility` method `getSpecConfParts` has changed
+
+
+Impact
+======
+
+Using code will fatal or not be called any longer.
+
+
+Affected Installations
+======================
+
+If extensions use above classes or methods. Since these classes are mostly core internal
+it is quite unlikely any project in the wild is affected.
+
+
+Migration
+=========
+
+Use the newly introduced API.
+
+
+.. index:: PHP-API, Backend, ext:t3editor, RTE

Documentation/Changelog/7.3/Breaking-67402-ExtbaseAbstractDomainObjectInitializeObject.rst

@@ -0,0 +1,37 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-67402-1668719172:
+
+================================================================
+Breaking: #67402 - Extbase AbstractDomainObject initializeObject
+================================================================
+
+See :issue:`67402`
+
+Description
+===========
+
+Method `initializeObject()` has been removed from `TYPO3\CMS\Extbase\DomainObject\AbstractDomainObject`.
+
+
+Impact
+======
+
+Possible fatal error in Extbase if objects are thawed from persistence.
+
+
+Affected Installations
+======================
+
+Domain objects extending AbstractDomainObject and calling `parent::initializeObject()`.
+This is relatively unlikely since the default implementation of `initializeObject()` is empty.
+
+
+Migration
+=========
+
+Remove calls to `parent::initializeObject()` from own `initializeObject()` implementations.
+
+
+.. index:: PHP-API, ext:extbase

Documentation/Changelog/7.3/Breaking-67402-ExtbaseAbstractDomainObjectWakeUp.rst

@@ -0,0 +1,33 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-67402:
+
+==========================================================
+Breaking: #67402 - Extbase AbstractDomainObject __wakeup()
+==========================================================
+
+See :issue:`67402`
+
+Description
+===========
+
+Method `__wakeup()` in classes extending `TYPO3\CMS\Extbase\DomainObject\AbstractDomainObject`
+is no longer called if objects are created when fetched from persistence.
+
+
+Affected Installations
+======================
+
+An instance is affected if own domain objects extending AbstractDomainObject
+implement own `__wakeup()` methods. Those methods are no longer called.
+
+
+Migration
+=========
+
+Move initialization code from `__wakeup()` to `initializeObject()`. As a bonus, dependencies have been injection at
+this point already.
+
+
+.. index:: PHP-API, ext:extbase

Documentation/Changelog/7.3/Deprecation-61829-DbalConfigClassFile.rst

@@ -0,0 +1,37 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-61829:
+
+============================================================
+Deprecation: #61829 - Deprecate config.classFile DBAL option
+============================================================
+
+See :issue:`61829`
+
+Description
+===========
+
+The DBAL option `config.classFile` has been marked for deprecation,
+and will be removed with TYPO3 CMS 8.
+
+
+Impact
+======
+
+Using `config.classFile` option will throw a deprecation message.
+
+
+Affected Installations
+======================
+
+Installations which use a user-defined DBAL database-handler.
+
+
+Migration
+=========
+
+Load the class using the autoloader.
+
+
+.. index:: PHP-API, ext:dbal

Documentation/Changelog/7.3/Deprecation-63453-DeprecateRenderModeAttributeOfFlashMessageViewHelper.rst

@@ -0,0 +1,51 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-63453:
+
+===============================================================================
+Deprecation: #63453 - Deprecate renderMode attribute of FlashMessagesViewHelper
+===============================================================================
+
+See :issue:`63453`
+
+Description
+===========
+
+Deprecated `renderMode` in favor of a flexible deferred rendering of flash messages in the Fluid template.
+This means that flash messages should no longer contain HTML, but the HTML output can and should be adjusted in the
+Fluid template.
+
+
+Impact
+======
+
+Using `renderMode` on FlashMessage output will throw a deprecation warning.
+
+
+Affected Installations
+======================
+
+All instances using the renderMode attribute in FlashMessage output.
+
+
+Migration
+=========
+
+Adjust flash messages to contain only plain text and remove the renderMode attribute in the output Templates.
+
+.. code-block:: html
+
+	<f:flashMessages as="flashMessages">
+		<ul class="typo3-flashMessages">
+			<f:for each="{flashMessages}" as="flashMessage">
+				<li class="alert {flashMessage.class}">
+					<h4>{flashMessage.title}</h4>
+					{flashMessage.message}
+				</li>
+			</f:for>
+		</ul>
+	</f:flashMessages>
+
+
+.. index:: Fluid

Documentation/Changelog/7.3/Deprecation-63735-DeprecateDataHandlerCheckValueMethods.rst

@@ -0,0 +1,37 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-63735:
+
+=================================================================
+Deprecation: #63735 - Deprecate DataHandler->checkValue_*-methods
+=================================================================
+
+See :issue:`63735`
+
+Description
+===========
+
+The following internal but currently public functions have been marked as deprecated:
+
+* DataHandler->checkValue_text
+* DataHandler->checkValue_input
+* DataHandler->checkValue_check
+* DataHandler->checkValue_radio
+* DataHandler->checkValue_group_select
+* DataHandler->checkValue_flex
+
+
+Impact
+======
+
+Using these functions will throw a deprecation message.
+
+
+Migration
+=========
+
+These functions are internal and should not be used outside of the core.
+
+
+.. index:: PHP-API, Backend

Documentation/Changelog/7.3/Deprecation-65344-ExtTables.rst

@@ -0,0 +1,41 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-65344:
+
+========================================================
+Deprecation: #65344 - typo3conf/extTables.php deprecated
+========================================================
+
+See :issue:`65344`
+
+Description
+===========
+
+The file :file:`typo3conf/extTables.php` which could be used for local TCA modifications has been marked as deprecated.
+
+Setting `$GLOBALS['TYPO3_CONF_VARS']['DB']['extTablesDefinitionScript']` together with the constant
+`TYPO3_extTableDef_script` are deprecated and should not be used any longer.
+
+
+Impact
+======
+
+The options and files are typically used for "poor man" `$GLOBALS['TCA']` overrides. This is discouraged
+and shouldn't be used any longer.
+
+
+Migration
+=========
+
+There are two options to migrate away from `typo3conf/extTables.php` usage, the first one should be preferred:
+
+* It is good practice to have a project / site specific extension that contains templates, TypoScript and
+  other stuff. Create one or more dedicated extensions and use TCA overrides to apply the desired modifications.
+  Something like `$GLOBALS['TCA']['pages']['ctrl']['hideAtCopy'] = FALSE;` should be moved from
+  :file:`typo3conf/extTables.php` to :file:`typo3conf/ext/<your_extension>/Configuration/TCA/Overrides/pages.php`.
+
+* Slot the signal `tcaIsBeingBuilt` that is emitted in `ExtensionManagementUtility.php`.
+
+
+.. index:: PHP-API, TCA, LocalConfiguration

Documentation/Changelog/7.3/Deprecation-66789-DeprecateOptionsInCshViewHelper.rst

@@ -0,0 +1,30 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-66789:
+
+=========================================================
+Deprecation: #66789 - options deprecated in CshViewHelper
+=========================================================
+
+See :issue:`66789`
+
+Description
+===========
+
+The two unused options `iconOnly` and `styleAttributes` have been marked as deprecated.
+
+
+Impact
+======
+
+The options in the CshViewHelper have been marked as deprecated and will be removed in TYPO3 CMS 8.
+
+
+Migration
+=========
+
+Remove the options where the CshViewHelper is used.
+
+
+.. index:: Fluid, Backend

Documentation/Changelog/7.3/Deprecation-66823-ExtensionUtilityConfigureModule.rst

@@ -0,0 +1,38 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-66823:
+
+================================================================================
+Deprecation: #66823 - Deprecate Extbase ExtensionUtility->configureModule method
+================================================================================
+
+See :issue:`66823`
+
+Description
+===========
+
+The method `TYPO3\CMS\Extbase\Utility\ExtensionUtility->configureModule()` has been marked for deprecation, and will
+be removed with TYPO3 CMS 8.
+
+
+Impact
+======
+
+Calling `TYPO3\CMS\Extbase\Utility\ExtensionUtility->configureModule()` will throw a deprecation message.
+
+
+Affected Installations
+======================
+
+Any installation with a third-party extension making use of `ExtensionUtility->configureModule()` directly
+inside e.g. ext_tables.php.
+
+
+Migration
+=========
+
+Use the 1:1 functionality in `TYPO3\CMS\Core\Utility\ExtensionManagementUtility->configureModule()` directly.
+
+
+.. index:: PHP-API, Backend, ext:extbase

Documentation/Changelog/7.3/Deprecation-66905-ClassicPageModuleAndEditRegularContentFromId.rst

@@ -0,0 +1,39 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-66905:
+
+===========================================================================================
+Deprecation: #66905 - Deprecate uc->classicPageEditMode and editRegularContentFromId option
+===========================================================================================
+
+See :issue:`66905`
+
+Description
+===========
+
+The BE-User uc option "classicPageEditMode" which was used prior to TYPO3 CMS 4.0 has been removed some time ago.
+The functionality `editRegularContentFromId` which was then triggered in EditDocumentController has been marked
+for deprecation.
+
+
+Impact
+======
+
+Any direct calls using `editRegularContentFromId` via GET parameter or calling `editRegularContentFromId()`
+directly from a third-party extension will trigger a deprecation message.
+
+
+Affected Installations
+======================
+
+Any installation using third-party code to restore the old behaviour.
+
+
+Migration
+=========
+
+Remove calls to the functionality.
+
+
+.. index:: PHP-API, Backend

Documentation/Changelog/7.3/Deprecation-66906-FunctionalityPngToGifConversion.rst

@@ -0,0 +1,41 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-66906:
+
+=============================================================
+Deprecation: #66906 - Functionality for png_to_gif conversion
+=============================================================
+
+See :issue:`66906`
+
+Description
+===========
+
+The global option `$TYPO3_CONF_VARS[GFX][png_to_gif]` has been removed. The according functionality within
+`GraphicalFunctions->pngToGifByImagemagick()` has been marked for deprecation.
+
+
+Impact
+======
+
+Any direct calls using `pngToGifByImagemagick()` will now throw a deprecation warning. All installations having the
+option `png_to_gif` activated will now always show png files instead of gifs when resizing PNG images in the
+TYPO3 Frontend.
+
+
+Affected Installations
+======================
+
+Any installation having png_to_gif activated or having third-party extensions calling
+`GraphicalFunctions->pngToGifByImagemagick()` directly.
+
+
+Migration
+=========
+
+Remove calls to the functionality, as the result will be a PNG. If GIF conversion is needed, the functionality needs
+to be implemented in a custom FAL Processor inside an extension.
+
+
+.. index:: PHP-API, Backend, LocalConfiguration, FAL

Documentation/Changelog/7.3/Deprecation-67029-DeprecatePageBgImgOption.rst

@@ -0,0 +1,36 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-67029:
+
+=================================================
+Deprecation: #67029 - Deprecate page.bgImg option
+=================================================
+
+See :issue:`67029`
+
+Description
+===========
+
+The option `page.bgImg` has been marked for deprecation and will be removed with TYPO3 CMS 8.
+
+
+Impact
+======
+
+Using `page.bgImg` will throw a deprecation message.
+
+
+Affected Installations
+======================
+
+Any installation which uses this TypoScript option.
+
+
+Migration
+=========
+
+Use CSS to set a background on the body.
+
+
+.. index:: TypoScript, Frontend

Documentation/Changelog/7.3/Deprecation-67171-T3editorIsEnabled.rst

@@ -0,0 +1,36 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-37171:
+
+=====================================================
+Deprecation: #37171 - Deprecate t3editor->isEnabled()
+=====================================================
+
+See :issue:`37171`
+
+Description
+===========
+
+TYPO3\CMS\T3editor\T3editor->isEnabled() has been marked as deprecated and should not be called anymore.
+
+
+Impact
+======
+
+The method isEnabled() always returns TRUE and will be removed with TYPO3 CMS 8.
+
+
+Affected Installations
+======================
+
+Any installation using third-party code that works with t3editor and calls isEnabled().
+
+
+Migration
+=========
+
+The method call should be removed.
+
+
+.. index:: PHP-API, Backend, ext:t3editor

Documentation/Changelog/7.3/Deprecation-67229-TcaChanges.rst

@@ -0,0 +1,245 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-65290-1668719172:
+
+=================================
+Deprecation: #65290 - TCA changes
+=================================
+
+See :issue:`65290`
+
+
+Description
+===========
+
+Some details in the main `Table Configuration Array, TCA`, known on PHP side as `$GLOBALS['TCA']` changed.
+
+
+Simplified `types` `showitem` configuration using `columnsOverrides`
+--------------------------------------------------------------------
+
+If a field is configured as `type` in `TCA` `ctrl` section, the value of this database field determines
+which fields are shown if opening a record in the backend. The shown fields are configured in `TCA` section
+`types` `showitem` and is a comma separated list of field names. Each field name can have 4 additional
+semicolon separated options, from which the last two have been dropped and moved:
+
+Before:
+
+.. code-block:: php
+
+	'types' => array(
+		'aType' => array(
+			'showitem' => 'aField,anotherField;otherLabel;aPalette;special:configuration;a-style-indicator,thirdField',
+		),
+	),
+
+
+If a record is opened that has the type field set to `aType`, it would show the three fields `aField`, `anotherField`
+and `thirdField`. The second field `anotherField` has further configuration and shows a different label, adds an additional
+palette below the field referenced as `aPalette`, adds `special:configuration` as special configuration and changes
+the style with its last field. The last two parameters were changed: The style configuration is obsolete since 7.1 and has been removed.
+The special configuration is identical to the `defaultExtras` field of a `columns` field section and can be added with this
+name in a newly introduced array `columnsOverrides` that is parallel to `showitem` of this type:
+
+.. code-block:: php
+
+	'types' => array(
+		'aType' => array(
+			'showitem' => 'aField,anotherField;otherLabel;aPalette,thirdField',
+			'columnsOverrides` => array(
+				'anotherField' => array(
+					'defaultExtras' => 'special:configuration',
+				),
+			),
+		),
+	),
+
+
+So, the 4th parameter has been transferred to `columnsOverrides` while the 5th parameter has been removed.
+
+This change enables more flexible overrides of column configuration based on a given type. This is currently used in
+`FormEngine` only, so only view-related parameters must be overwritten here. It is not supported to change data handling
+related parameters like `type=text` to `type=select` or similar, but it is possible to change for example the number
+of rows shown in a `type=text` column field:
+
+.. code-block:: php
+
+	'types' => array(
+		'aType' => array(
+			'showitem' => 'aField,anotherField;otherLabel;aPalette,thirdField',
+			'columnsOverrides` => array(
+				'anotherField' => array(
+					'config' => array(
+						'rows' => 42,
+					),
+				),
+			),
+		),
+	),
+
+
+It is also possible to remove a given configuration from the default configuration using the `__UNSET` keyword. Again,
+this is only supported for view-related configuration options. Changing for instance an `eval` option may cripple the
+PHP-side validation done by the DataHandler that checks and stores values.
+
+.. code-block:: php
+
+	'types' => array(
+		'aType' => array(
+			'columnsOverrides` => array(
+				'bodytext' => array(
+					'config' => array(
+						'rows' => '__UNSET',
+					),
+				),
+			),
+		),
+	),
+
+
+The above example would remove the `rows` parameter of the `bodytext` field columns configuration, so a default
+value would be used instead.
+
+
+Simplified t3editor configuration
+---------------------------------
+
+t3editor is no longer configured and enabled as wizard.
+
+Configuration for a column field looked like this before:
+
+.. code-block:: php
+
+	'bodytext' => array(
+		'config' => array(
+			'type' => 'text',
+			'rows' => 42,
+			'wizards' => array(
+				't3editor' => array(
+					'type' => 'userFunc',
+					'userFunc' => 'TYPO3\CMS\T3editor\FormWizard->main',
+					'title' => 't3editor',
+					'icon' => 'wizard_table.gif',
+					'module' => array(
+						'name' => 'wizard_table'
+					),
+					'params' => array(
+						'format' => 'html',
+						'style' => 'width:98%; height: 60%;'
+					),
+				),
+			),
+		),
+	),
+
+
+The new configuration is simplified to:
+
+.. code-block:: php
+
+	'bodytext' => array(
+		'exclude' => 1,
+		'label' => 'aLabel',
+		'config' => array(
+			'type' => 'text',
+			'renderType' => 't3editor',
+			'format' => 'html',
+			'rows' => 42,
+		),
+	),
+
+
+In case t3editor was only enabled for a specific type, this was previously done with
+`enableByTypeConfig` within the wizard configuration and `wizards[theWizardName]` as
+the 4th semicolon separated parameter of the according field in section `showitem` of the
+`type` where t3editor should be enabled. Old configuration was:
+
+.. code-block:: php
+
+	'columns' => array(
+		'bodytext' => array(
+			'exclude' => 1,
+			'label' => 'aLabel',
+			'config' => array(
+				'type' => 'text',
+				'rows' => 42,
+				'wizards' => array(
+					't3editorHtml' => array(
+						'type' => 'userFunc',
+						'userFunc' => 'TYPO3\CMS\T3editor\FormWizard->main',
+						'enableByTypeConfig' => 1,
+						'title' => 't3editor',
+						'icon' => 'wizard_table.gif',
+						'module' => array(
+							'name' => 'wizard_table'
+						),
+						'params' => array(
+							'format' => 'html',
+							'style' => 'width:98%; height: 60%;'
+						),
+					),
+				),
+			),
+		),
+	),
+	'types' => array(
+		'firstType' => array(
+			'showitem' => 'bodytext;;;wizards[t3editorHtml]',
+		),
+	),
+
+
+This now uses the new `columnsOverrides` feature parallel to `showitem`:
+
+.. code-block:: php
+
+	'columns' => array(
+		'bodytext' => array(
+			'config' => array(
+				'type' => 'text',
+				'rows' => 42,
+			),
+		),
+	),
+	'types' => array(
+		'firstType' => array(
+			'showitem' => 'bodytext',
+			'columnsOverrides' => array(
+				'bodytext' => array(
+					'config' => array(
+						'format' => 'typoscript',
+						'renderType' => 't3editor',
+					),
+				),
+			),
+		),
+
+
+Impact
+======
+
+TCA is automatically migrated during bootstrap of the TYPO3 core and the result is cached.
+In case TCA is still registered or changed in extensions with entries in `ext_tables.php`, an automatic
+migration of this part of `TCA` is only triggered if extension `compatibility6` is loaded. This has a
+performance penalty since the migration in `compatibility6` is then done on every frontend and backend
+script call and is not cached.
+It is **strongly** advised to move remaining `TCA` changes from `ext_tables.php` to `Configuration/TCA` or
+`Configuration/TCA/Overrides` of the according extension and to unload `compatibility6`.
+
+
+Migration
+=========
+
+An automatic migration is in place. It throws deprecation log entries in case `TCA` had to be changed on the fly.
+The migration logs give hints on what exactly has changed and the final `TCA` can be inspected in the backend
+configuration module. If outdated flexforms are used, the migration is done within the FormEngine class
+construct on the fly and will throw deprecation warnings as soon as a record with outdated `TCA` flexforms
+is opened in the backend.
+
+Typical migration of the 4th `showitem` parameter involves moving a RTE configuration like
+`richtext:rte_transform[mode=ts_css]` or the `type=text` flags `nowrap`, `fixed-font`
+and `enabled-tab` to `columnsOverrides`.
+
+
+.. index:: TCA, Backend, ext:t3editor

Documentation/Changelog/7.3/Deprecation-67297-DbalFieldTypeConversion.rst

@@ -0,0 +1,33 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-67297:
+
+========================================================
+Deprecation: #67297 - MySQL / DBMS field type conversion
+========================================================
+
+See :issue:`67297`
+
+Description
+===========
+
+The Dbal\DatabaseConnection class provides generic functions that translate between native MySQL field types
+and ADOdb meta field types. The generic functions `MySQLActualType()` and `MySQLMetaType` have been marked as
+deprecated and should not be used any longer.
+
+
+Impact
+======
+
+Although these are public functions the use was probably limited to the DBAL Extension.
+If used however, they will trigger a deprecation message.
+
+
+Migration
+=========
+
+Use the functions `getNativeFieldType()` and `getMetaFieldType()` provided by the DBMS specifics class.
+
+
+.. index:: PHP-API, ext:dbal

Documentation/Changelog/7.3/Deprecation-67402-ExtbaseAbstractDomainObjectWakeUp.rst

@@ -0,0 +1,31 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-67402:
+
+=============================================================
+Deprecation: #67402 - Extbase AbstractDomainObject __wakeup()
+=============================================================
+
+See :issue:`67402`
+
+Description
+===========
+
+Method `__wakeup()` has been marked as deprecated in `TYPO3\CMS\Extbase\DomainObject\AbstractDomainObject`.
+
+
+Affected Installations
+======================
+
+An instance is affected if own domain objects extending AbstractDomainObject
+implement `__wakeup()` and call `parent::__wakeup()` as documented.
+
+
+Migration
+=========
+
+Remove calls to `parent::__wakeup()` from own `__wakeup()` implementations.
+
+
+.. index:: PHP-API, ext:extbase

Documentation/Changelog/7.3/Feature-59606-IntegrateSymfonyConsoleIntoCommandController.rst

@@ -0,0 +1,101 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-59606:
+
+==================================================================
+Feature: #59606 - Integrate Symfony/Console into CommandController
+==================================================================
+
+See :issue:`59606`
+
+Description
+===========
+
+The CommandController now makes use of Symfony/Console internally and
+provides various methods directly from the CommandController's `output` member:
+
+* TableHelper
+
+  * outputTable($rows, $headers = NULL)
+
+* DialogHelper
+
+  * select($question, $choices, $default = NULL, $multiSelect = false, $attempts = FALSE)
+  * ask($question, $default = NULL, array $autocomplete = array())
+  * askConfirmation($question, $default = TRUE)
+  * askHiddenResponse($question, $fallback = TRUE)
+  * askAndValidate($question, $validator, $attempts = FALSE, $default = NULL, array $autocomplete = NULL)
+  * askHiddenResponseAndValidate($question, $validator, $attempts = FALSE, $fallback = TRUE)
+
+* ProgressHelper
+
+  * progressStart($max = NULL)
+  * progressSet($current)
+  * progressAdvance($step = 1)
+  * progressFinish()
+
+Here's an example showing of some of those functions:
+
+.. code-block:: php
+
+   namespace Acme\Demo\Command;
+
+   use TYPO3\CMS\Extbase\Mvc\Controller\CommandController;
+
+   /**
+    * My command
+    */
+   class MyCommandController extends CommandController {
+
+      /**
+       * @return string
+       */
+      public function myCommand() {
+         // render a table
+         $this->output->outputTable(array(
+            array('Bob', 34, 'm'),
+            array('Sally', 21, 'f'),
+            array('Blake', 56, 'm')
+         ),
+         array('Name', 'Age', 'Gender'));
+
+         // select
+         $colors = array('red', 'blue', 'yellow');
+         $selectedColorIndex = $this->output->select('Please select one color', $colors, 'red');
+         $this->outputLine('You choose the color %s.', array($colors[$selectedColorIndex]));
+
+         // ask
+         $name = $this->output->ask('What is your name?' . PHP_EOL, 'Bob', array('Bob', 'Sally', 'Blake'));
+         $this->outputLine('Hello %s.', array($name));
+
+         // prompt
+         $likesDogs = $this->output->askConfirmation('Do you like dogs?');
+         if ($likesDogs) {
+            $this->outputLine('You do like dogs!');
+         }
+
+         // progress
+         $this->output->progressStart(600);
+         for ($i = 0; $i < 300; $i ++) {
+            $this->output->progressAdvance();
+            usleep(5000);
+         }
+         $this->output->progressFinish();
+
+      }
+   }
+
+
+Impact
+======
+
+This change does not alter the public API so it is not breaking
+in the strict sense. But it introduces a new behavior:
+Previously all output was collected in the `Cli\Response` and only rendered to the console at the end of a CLI request.
+Now all methods producing output (including `output()` and `outputLine()`) render the result directly to the console.
+If you use `$this->response` directly or let the command method return a string, the rendering is still deferred until
+the end of the CLI request.
+
+
+.. index:: CLI, ext:extbase, PHP-API

Documentation/Changelog/7.3/Feature-62242-ActionMenuItemGroupViewHelper.rst

@@ -0,0 +1,45 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-62242:
+
+===============================================
+Feature: #62242 - ActionMenuItemGroupViewHelper
+===============================================
+
+See :issue:`62242`
+
+Description
+===========
+
+Using this ViewHelper, OptGroups can be used in the backend select field, which controls which action is selected.
+
+
+Impact
+======
+
+The new ViewHelper can be used in all new projects. There is no interference with any part of existing code.
+
+
+Examples
+========
+
+Usage example:
+
+.. code-block:: html
+
+	<f:be.menus.actionMenu>
+		<f:be.menus.actionMenuItem label="Default: Welcome" controller="Default" action="index" />
+		<f:be.menus.actionMenuItem label="Community: get in touch" controller="Community" action="index" />
+
+		<f:be.menus.actionMenuItemGroup label="Information">
+			<f:be.menus.actionMenuItem label="PHP Information" controller="Information" action="listPhpInfo" />
+			<f:be.menus.actionMenuItem label="Documentation" controller="Information" action="documentation" />
+			<f:be.menus.actionMenuItem label="Hooks" controller="Information" action="hooks" />
+			<f:be.menus.actionMenuItem label="Signals" controller="Information" action="signals" />
+			<f:be.menus.actionMenuItem label="XClasses" controller="Information" action="xclass" />
+		</f:be.menus.actionMenuItemGroup>
+	</f:be.menus.actionMenu>
+
+
+.. index:: Fluid, Backend

Documentation/Changelog/7.3/Feature-63453-TemplateSupportForFlashMessagesViewHelper.rst

@@ -0,0 +1,37 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-63453:
+
+==============================================================
+Feature: #63453 - Template support for FlashMessagesViewHelper
+==============================================================
+
+See :issue:`63453`
+
+Description
+===========
+
+Template support for `FlashMessagesViewHelper` has been added.
+This allows to define a custom rendering for flash messages.
+
+The new attribute `as` for the `FlashMessagesViewHelper` allows to specify a variable name,
+which can be used within the view helper's child elements to access the flash messages.
+
+Example usage:
+
+.. code-block:: html
+
+	<f:flashMessages as="flashMessages">
+		<ul class="myFlashMessages">
+			<f:for each="{flashMessages}" as="flashMessage">
+				<li class="alert {flashMessage.class}">
+					<h4>{flashMessage.title}</h4>
+					<span class="fancy-icon">{flashMessage.message}</span>
+				</li>
+			</f:for>
+		</ul>
+	</f:flashMessages>
+
+
+.. index:: Fluid, Backend, Frontend

Documentation/Changelog/7.3/Feature-63561-AddTypoScriptStdWrapStrtotime.rst

@@ -0,0 +1,47 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-63561:
+
+==================================================
+Feature: #63561 - Add TypoScript stdWrap strtotime
+==================================================
+
+See :issue:`63561`
+
+Description
+===========
+
+A new TypoScript property `strtotime` is now available within `stdWrap` which allows for conversion of formatted
+dates to timestamp, e.g. to perform date calculations.
+
+Possible values are `1` or any time string valid as first argument of the PHP `strtotime()` function.
+
+Basic usage to convert date string to timestamp:
+
+.. code-block:: typoscript
+
+	date_as_timestamp = TEXT
+	date_as_timestamp {
+		value = 2015-04-15
+		strtotime = 1
+	}
+
+Convert incoming date string to timestamp, perform date calculation and output as date string again:
+
+.. code-block:: typoscript
+
+	next_weekday = TEXT
+	next_weekday {
+		data = GP:selected_date
+		strtotime = + 2 weekdays
+		strftime = %Y-%m-%d
+	}
+
+Impact
+======
+
+The new property is available everywhere in TypoScript where `stdWrap` is applied.
+
+
+.. index:: TypoScript, Frontend

Documentation/Changelog/7.3/Feature-65250-TypoScriptConditionAddGPmerged.rst

@@ -0,0 +1,35 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-65250:
+
+===================================================
+Feature: #65250 - TypoScript condition add GPmerged
+===================================================
+
+See :issue:`65250`
+
+
+Description
+===========
+
+If one uses TypoScript condition with GP then the check is with GeneralUtility::_GP()
+which means that if I have GET variables beginning with an extbase plugin-namespace
+and POST variables with the same plugin-namespace, e.g.
+GET: tx_demo_demo[action]=detail
+POST: tx_demo_demo[name]=Foo
+then GeneralUtility::_GP('tx_demo_demo'), as intended, will only return the
+array of the POST variables for that namespace. However, that results in the issue that
+if you check for the GET variable the check will fail.
+
+So, instead the check should use GeneralUtility::_GPmerged()
+
+.. code-block:: typoscript
+
+	[globalVar = GPmerged:tx_demo|foo = 1]
+	page.90 = TEXT
+	page.90.value = DEMO
+	[global]
+
+
+.. index:: TypoScript, Frontend

Documentation/Changelog/7.3/Feature-66111-AddTemplaterootpathsSupportToCobjectFluidtemplate.rst

@@ -0,0 +1,94 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-66111:
+
+========================================================================
+Feature: #66111 - Add TemplateRootPaths support to cObject FLUIDTEMPLATE
+========================================================================
+
+See :issue:`66111`
+
+Description
+===========
+
+cObject FLUIDTEMPLATE has been extended with `templateRootPaths` and `templateName`. Now you can set a template name
+and when rendering the template this name is used together with the set format to find the template in the given
+templateRootPaths with the same fallback logic as layoutRootPath and partialRootPath
+
+- templateName = string/stdWrap
+- templateRootPaths = array of file paths with "EXT:" prefix support
+
+
+Example 1:
+----------
+
+.. code-block:: typoscript
+
+	lib.stdContent = FLUIDTEMPLATE
+	lib.stdContent {
+		templateName = Default
+		layoutRootPaths {
+			10 = EXT:frontend/Resources/Private/Layouts
+			20 = EXT:sitemodification/Resources/Private/Layouts
+		}
+		partialRootPaths {
+			10 = EXT:frontend/Resources/Private/Partials
+			20 = EXT:sitemodification/Resources/Private/Partials
+		}
+		templateRootPaths {
+			10 = EXT:frontend/Resources/Private/Templates
+			20 = EXT:sitemodification/Resources/Private/Templates
+		}
+		variable {
+			foo = bar
+		}
+	}
+
+Example 2:
+----------
+
+.. code-block:: typoscript
+
+	lib.stdContent = FLUIDTEMPLATE
+	lib.stdContent {
+
+		templateName = TEXT
+		templateName.stdWrap {
+			cObject = TEXT
+			cObject {
+				data = levelfield:-2,backend_layout_next_level,slide
+				override.field = backend_layout
+				split {
+					token = frontend__
+					1.current = 1
+					1.wrap = |
+				}
+			}
+			ifEmpty = Default
+		}
+		layoutRootPaths {
+			10 = EXT:frontend/Resources/Private/Layouts
+			20 = EXT:sitemodification/Resources/Private/Layouts
+		}
+		partialRootPaths {
+			10 = EXT:frontend/Resources/Private/Partials
+			20 = EXT:sitemodification/Resources/Private/Partials
+		}
+		templateRootPaths {
+			10 = EXT:frontend/Resources/Private/Templates
+			20 = EXT:sitemodification/Resources/Private/Templates
+		}
+		variable {
+			foo = bar
+		}
+	}
+
+
+Impact
+======
+
+If templateName and templateRootPaths are set the template and file options are neglected.
+
+
+.. index:: TypoScript, Fluid, Frontend

Documentation/Changelog/7.3/Feature-66173-AllowPageTitleEditByDoubleclick.rst

@@ -0,0 +1,25 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-66173:
+
+======================================================
+Feature: #66173 - Allow page title edit by doubleclick
+======================================================
+
+See :issue:`66173`
+
+Description
+===========
+
+A user can edit the page title in the "Page" and the "List" module by double-clicking the page header.
+
+
+Impact
+======
+
+If a user has sufficient permissions, the page title will become a text field after double-clicking on it.
+Pressing the "escape" key aborts the edit, pressing "enter" submits the changes.
+
+
+.. index:: Backend

Documentation/Changelog/7.3/Feature-66269-FluidRemoveViewHelperXmlnsAttributesAndSpecifiedHtmlTag.rst

@@ -0,0 +1,115 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-66269:
+
+==================================================================================
+Feature: #66269 - Fluid: Remove ViewHelper xmlns-attributes and specified html tag
+==================================================================================
+
+See :issue:`66269`
+
+Description
+===========
+
+With the introduction of using xmlns:* attributes to include ViewHelpers, it is possible to have IDE support for Fluid
+templates.
+However, the problem is that the xmlns:* attributes and the corresponding tag will also be rendered, which is not
+desired most of the time. A workaround to avoid this is to use sections.
+However, this solution is counter-intuitive, is not available in layouts and causes extra processing overhead.
+
+.. code-block:: html
+
+	<html xmlns:f="http://typo3.org/ns/TYPO3/CMS/Fluid/ViewHelpers"
+			xmlns:n="http://typo3.org/ns/GeorgRinger/News/ViewHelpers">
+
+	<f:section name="content">
+	</f:section>
+
+
+Impact
+======
+
+The xmlns:* attributes for valid ViewHelper namespaces will now be removed before rendering.
+Such ViewHelper namespaces follow this URI pattern:
+
+.. code-block:: html
+
+	http://typo3.org/ns/<phpNamespace>
+
+
+Examples:
+
+.. code-block:: html
+
+	http://typo3.org/ns/TYPO3/CMS/Fluid/ViewHelpers
+	http://typo3.org/ns/GeorgRinger/News/ViewHelpers
+
+
+xmlns attributes for non-ViewHelper namespaces will be preserved.
+
+Furthermore an additional data-attribute to HTML-Tags is introduced.
+
+.. code-block:: html
+
+	data-namespace-typo3-fluid="true"
+
+If this attribute is specified on the HTML-Tag, the HTML-tag itself won't be rendered as well.
+(Also a corresponding closing tag will not be rendered for that template.)
+This is useful for various IDEs and HTML auto-completion.
+
+
+Examples
+========
+
+Include ViewHelper namespaces on an existing tag (e.g. root xml tag) via xmlns attributes for Fluid and News extension.
+
+.. code-block:: xml
+
+	<?xml version="1.0" encoding="utf-8"?>
+	<root xmlns:f="http://typo3.org/ns/TYPO3/CMS/Fluid/ViewHelpers"
+			xmlns:n="http://typo3.org/ns/GeorgRinger/News/ViewHelpers"
+			xmlns:foo="http://typo3.org/foo">
+
+		<f:if condition="{newsItem.title}">
+			<f:then>
+				<n:titleTag>{newsItem.title}</n:titleTag>
+			</f:then>
+			<f:else>
+				<n:titleTag>News-Detail</n:titleTag>
+			</f:else>
+		</f:if>
+	</root>
+
+Output is then
+
+.. code-block:: xml
+
+	<root xmlns:foo="http://typo3.org/foo" >
+		...
+	</root>
+
+
+Include ViewHelper namespaces with HTML-tag and a data-namespace-typo3-fluid="true" attribute via xmlns attributes for
+Fluid and News extension.
+
+.. code-block:: html
+
+	<html data-namespace-typo3-fluid="true"
+			xmlns:f="http://typo3.org/ns/TYPO3/CMS/Fluid/ViewHelpers"
+			xmlns:n="http://typo3.org/ns/GeorgRinger/News/ViewHelpers">
+
+		<f:if condition="{newsItem.title}">
+			<f:then>
+				<n:titleTag>{newsItem.title}</n:titleTag>
+			</f:then>
+			<f:else>
+				<n:titleTag>News-Detail</n:titleTag>
+			</f:else>
+		</f:if>
+	</html>
+
+The output contains everything excluding the HTML-tag.
+
+
+.. index:: Fluid

Documentation/Changelog/7.3/Feature-66669-BeLoginFormAPI.rst

@@ -0,0 +1,108 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-66669:
+
+===================================
+Feature: #66669 - BE login form API
+===================================
+
+See :issue:`66669`
+
+Description
+===========
+
+The backend login has been completely refactored and a new API has been introduced.
+The OpenID form has been extracted and is now using the new API as well and is completely independent of the central
+Core classes for the first time.
+
+
+Registering a login provider
+----------------------------
+
+The concept of the new backend login is based on "login providers".
+A login provider can be registered within your `ext_localconf.php` file like this:
+
+.. code-block:: php
+
+	$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['backend']['loginProviders'][1433416020] = [
+		'provider' => \TYPO3\CMS\Backend\LoginProvider\UsernamePasswordLoginProvider::class,
+		'sorting' => 50,
+		'icon-class' => 'fa-key',
+		'label' => 'LLL:EXT:backend/Resources/Private/Language/locallang.xlf:login.link'
+	];
+
+The settings are defined as:
+
+* `provider`: The login provider class name, which must implement `TYPO3\CMS\Backend\LoginProvider\LoginProviderInterface`.
+* `sorting`: The sorting is important for the ordering of the links to the possible login providers on the login screen.
+* `icon-class`: The font-awesome icon name for the link on the login screen.
+* `label`: The label for the login provider link on the login screen.
+
+For a new login provider you have to register a **new key** - a unix timestamp - in `$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['backend']['loginProviders']`.
+If your login provider extends another one, you may only overwrite necessary settings. An example would be to
+extend an existing provider and replace its registered 'provider' class with your new class name.
+
+.. code-block:: php
+
+	$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['backend']['loginProviders'][1433416020]['provider'] = CustomProviderExtendingUsernamePasswordLoginProvider::class
+
+LoginProviderInterface
+----------------------
+
+The LoginProviderInterface contains only one method:
+
+`public function render(StandaloneView $view, PageRenderer $pageRenderer, LoginController $loginController);`
+
+The parameters are defined as:
+
+* `$view`: The Fluid StandaloneView which renders the login screen. You have to set the template file and you may add variables to the view according to your needs.
+* `$pageRenderer`: The PageRenderer instance provides possibility to add necessary JavaScript resources.
+* `$loginController`: The LoginController instance.
+
+
+The View
+--------
+
+As mentioned above, the `render` method gets the Fluid StandaloneView as first parameter.
+You have to set the template path and filename using the methods of this object.
+The template file must only contain the form fields, not the form-tag.
+Later on, the view renders the complete login screen.
+
+View requirements:
+
+* The template must use the `Login`-layout provided by the Core `<f:layout name="Login">`.
+* Form fields must be provided within the section `<f:section name="loginFormFields">`.
+
+
+.. code-block:: html
+
+	<f:layout name="Login" />
+	<f:section name="loginFormFields">
+		<div class="form-group t3js-login-openid-section" id="t3-login-openid_url-section">
+			<div class="input-group">
+				<input type="text" id="openid_url" name="openid_url" value="{presetOpenId}" autofocus="autofocus" placeholder="{f:translate(key: 'openId', extensionName: 'openid')}" class="form-control input-login t3js-clearable t3js-login-openid-field" />
+				<div class="input-group-addon">
+					<span class="fa fa-openid"></span>
+				</div>
+			</div>
+		</div>
+	</f:section>
+
+
+Examples
+--------
+
+Within the Core you can find two best practice implementations:
+
+1. EXT:backend, which implements the `UsernamePasswordLoginProvider` (the default)
+2. EXT:openid, which implements the `OpenIdLoginProvider` and adds a second login option
+
+
+Impact
+======
+
+All extensions which add additional fields to the login form must be updated and make use of the new BE login form API.
+
+
+.. index:: PHP-API, Backend, ext:openid

Documentation/Changelog/7.3/Feature-66681-CategoryRegistryAddOptionsToSetL10n_modeAndL10n_display.rst

@@ -0,0 +1,31 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-66681:
+
+=================================================================================
+Feature: #66681 - CategoryRegistry: add options to set l10n_mode and l10n_display
+=================================================================================
+
+See :issue:`66681`
+
+Description
+===========
+
+Class `CategoryRegistry->addTcaColumn` got options to set  `l10n_mode` and `l10n_display`.
+The values can be set via:
+
+.. code-block:: php
+
+	\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::makeCategorizable(
+		$extensionKey,
+		$tableName,
+		'categories',
+		array(
+			'l10n_mode' => 'string (keyword)',
+			'l10n_display' => 'list of keywords'
+		)
+	);
+
+
+.. index:: PHP-API, TCA, Backend

Documentation/Changelog/7.3/Feature-66697-AddUppercamelcaseAndLowercamelcaseToStdWrap.case.rst

@@ -0,0 +1,44 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-66697:
+
+=======================================================================
+Feature: #66697 - Add uppercamelcase and lowercamelcase to stdWrap.case
+=======================================================================
+
+See :issue:`66697`
+
+Description
+===========
+
+To make it possible to change a value from underscored to "UpperCamelCase" or "lowerCamelCase" the options
+`uppercamelcase` and `lowercamelcase` are added to `stdWrap.case`.
+
+.. code-block:: typoscript
+
+	tt_content = CASE
+	tt_content {
+		key {
+			field = CType
+		}
+
+		my_custom_ctype =< lib.userContent
+		my_custom_ctype {
+			file = EXT:site_base/Resources/Private/Templates/SomeOtherTemplate.html
+			settings {
+				extraParam = 1
+			}
+		}
+
+		default =< lib.userContent
+		default {
+			file = TEXT
+			file.field = CType
+			file.stdWrap.case = uppercamelcase
+			file.wrap = EXT:site_base/Resources/Private/Templates/|.html
+		}
+	}
+
+
+.. index:: TypoScript, Frontend

Documentation/Changelog/7.3/Feature-66698-AddIntegrityPropertyToJavaScriptFiles.rst

@@ -0,0 +1,45 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-66698:
+
+============================================================
+Feature: #66698 - Add integrity property to JavaScript files
+============================================================
+
+See :issue:`66698`
+
+Description
+===========
+
+Add a property `integrity="some-hash"` to JavaScript files via TypoScript
+
+`page.includeJSLibs.<array>.integrity = some-hash`
+
+This patch affects the TypoScript PAGE properties
+
+* includeJSLibs
+* includeJSFooterlibs
+* includeJS
+* includeJSFooter
+
+Usage:
+------
+
+.. code-block:: typoscript
+	:emphasize-lines: 6
+
+	page {
+		includeJS {
+			jQuery = fileadmin/jquery-1.10.2.min.js
+			jQuery.disableCompression = 1
+			jQuery.excludeFromConcatenation = 1
+			jQuery.integrity = sha256-C6CB9UYIS9UJeqinPHWTHVqh/E1uhG5Twh+Y5qFQmYg=
+		}
+	}
+
+.. hint::
+	Integrity hashes may be generated using https://www.srihash.org/.
+
+
+.. index:: JavaScript, TypoScript, Frontend

Documentation/Changelog/7.3/Feature-66709-AddTemplateRootPathsSupportToFluidViewStandaloneView.rst

@@ -0,0 +1,62 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-66709:
+
+============================================================================
+Feature: #66709 - Add TemplateRootPaths support to Fluid/View/StandaloneView
+============================================================================
+
+See :issue:`66709`
+
+Description
+===========
+
+The StandaloneView is extended with `setTemplateRootPaths($templatePaths)` and `setTemplate($templateName, $throwException = TRUE)`.
+Now you can set a template by name.
+
+When `setTemplate($templateName)` is called the `$templateName` is used to find the template in the given
+templateRootPaths with the same fallback logic as layoutRootPath and partialRootPath.
+
+
+Basic example:
+
+.. code-block:: php
+
+	$view = GeneralUtility::makeInstance(StandaloneView::class);
+	$view->setLayoutRootPaths($layoutPaths);
+	$view->setPartialRootPaths($partialPaths);
+	$view->setTemplateRootPaths($templatePaths);
+
+	try {
+		$view->setTemplate($templateName);
+	} catch (InvalidTemplateResourceException $e) {
+		// no template $templateName found in given $templatePaths
+		exit($e->getMessage());
+	}
+
+	$content = $view->render();
+
+
+
+Example of rendering an email template:
+
+.. code-block:: php
+
+	$view = GeneralUtility::makeInstance(StandaloneView::class);
+	$view->setLayoutRootPaths(array(GeneralUtility::getFileAbsFileName('EXT:my_extension/Resources/Private/Layouts')));
+	$view->setPartialRootPaths(array(GeneralUtility::getFileAbsFileName('EXT:my_extension/Resources/Private/Partials')));
+	$view->setTemplateRootPaths(array(GeneralUtility::getFileAbsFileName('EXT:my_extension/Resources/Private/Templates')));
+	$view->setTemplate('Email/Notification');
+
+	$emailBody = $view->render();
+
+
+Impact
+======
+
+The public API of `TYPO3\CMS\Fluid\View\StandaloneView` is enhanced with the methods
+ `setTemplateRootPaths($templatePaths)` and `setTemplate($templateName, $throwException = TRUE)`
+
+
+.. index:: PHP-API, Fluid

Documentation/Changelog/7.3/Feature-66822-SpriteIconsInBackendModules.rst

@@ -0,0 +1,41 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-66822:
+
+===================================================
+Feature: #66822 - Allow Sprites For Backend Modules
+===================================================
+
+See :issue:`66822`
+
+Description
+===========
+
+Backend Modules (both Main Modules like "Web" and Submodules like "Filelist") can now use sprites instead of images for
+displaying the icons in the module menu on the left side of the TYPO3 Backend.
+
+Registering a module can now look like this (as an example the "Page" module):
+
+.. code-block:: php
+
+	\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addModule(
+		'web',
+		'layout',
+		'top',
+		\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::extPath($_EXTKEY) . 'Modules/Layout/',
+		array(
+			'script' => '_DISPATCH',
+			'access' => 'user,group',
+			'name' => 'web_layout',
+			'iconIdentifier' => 'module-web',
+			'labels' => array(
+				'll_ref' => 'LLL:EXT:backend/Resources/Private/Language/locallang_mod.xlf',
+			),
+		)
+	);
+
+One can use any available sprite icon known to TYPO3.
+
+
+.. index:: PHP-API, Backend

Documentation/Changelog/7.3/Feature-66907-AddDataProcessingToFluidTemplateContentObject.rst

@@ -0,0 +1,54 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-66907:
+
+=====================================================================
+Feature: #66907 - Add Data Processing to FLUIDTEMPLATE content object
+=====================================================================
+
+See :issue:`66907`
+
+Description
+===========
+
+cObject FLUIDTEMPLATE has been extended with `dataProcessing`. This setting can be used to add one or multiple processors to
+manipulate data of the currently rendered content object, like tt_content or page, and fill a key/value store that will be passed
+as variables to the Fluid template, where every key of the key/value store will be available as variable in the Fluid template.
+
+- dataProcessing = array of class references by full namespace
+
+
+Example:
+--------
+
+.. code-block:: typoscript
+
+	my_custom_ctype = FLUIDTEMPLATE
+	my_custom_ctype {
+		templateRootPaths {
+			10 = EXT:your_extension_key/Resources/Private/Templates
+		}
+		templateName = CustomName
+		settings {
+			extraParam = 1
+		}
+		dataProcessing {
+			1 = Vendor\YourExtensionKey\DataProcessing\MyFirstCustomProcessor
+			2 = Vendor2\AnotherExtensionKey\DataProcessing\MySecondCustomProcessor
+			2 {
+				options {
+					myOption = SomeValue
+				}
+			}
+		}
+	}
+
+
+Impact
+======
+
+The data processors can be used in all new projects. There is no interference with any part of existing code.
+
+
+.. index:: PHP-API, TypoScript, Frontend

Documentation/Changelog/7.3/Feature-67071-ProcessedFilesCleanupToolAddedInInstallTool.rst

@@ -0,0 +1,22 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-67071:
+
+====================================================================
+Feature: #67071 - Processed files cleanup tool added in Install Tool
+====================================================================
+
+See :issue:`67071`
+
+Description
+===========
+
+The Install Tool now provides a new tool to remove processed files (e.g. image thumbnails) from FAL in its "Clean up"
+section.
+
+The tool is useful if you change graphic-related settings or after updating GraphicsMagick/ImageMagick on the server
+and you want all files to be regenerated.
+
+
+.. index:: Backend

Documentation/Changelog/7.3/Feature-67229-FormEngineNodeFactoryApi.rst

@@ -0,0 +1,111 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-67229:
+
+============================================
+Feature: #67229 - FormEngine NodeFactory API
+============================================
+
+See :issue:`67229`
+
+Description
+===========
+
+The FormEngine class construct was moved to a tree approach with container classes as inner nodes and
+element classes (the rendering widgets) as leaves. Finding, instantiation and preparation of those
+classes is done via `TYPO3\CMS\Backend\Form\NodeFactory`.
+
+This class was extended with an API to allow flexible overriding and adding of containers and elements:
+
+
+Registration of new nodes and overwriting existing nodes
+--------------------------------------------------------
+
+.. code-block:: php
+
+	$GLOBALS['TYPO3_CONF_VARS']['SYS']['formEngine']['nodeRegistry'][1433196792] = array(
+		'nodeName' => 'input',
+		'priority' => 40,
+		'class' => \MyVendor\MyExtension\Form\Element\T3editorElement::class,
+	);
+
+
+This registers the class `MyVendor\MyExtension\Form\Element\T3editorElement` as render class for
+the type `input`. It will be called to render elements of this type and must implement the interface
+`TYPO3\CMS\Backend\Form\NodeInterface`. The array key is the unix timestamp of the date when an registry
+element is added and is just used to have a unique key that is very unlikely to collide with others - this
+is the same logic that is used for exception codes. If more than one registry element for the same type
+is registered, the element with highest priority wins. Priority must be set between 0 and 100. Two elements
+with same priority for the same type will throw an exception.
+
+The core extension t3editor uses this API to substitute a `type=text` field with `renderType=t3editor`
+from the default `TextElement` to its own `T3editorElement`.
+
+This registry both allows completely overriding existing implementations of any existing given type as well as
+registration of a new `renderType` for own fancy elements. A TCA configuration for a new renderType
+and its nodeRegistry could look like:
+
+.. code-block:: php
+
+	'columns' => array(
+		'bodytext' => array(
+			'config' => array(
+				'type' => 'text',
+				'renderType' => '3dCloud',
+			),
+		),
+	),
+
+	$GLOBALS['TYPO3_CONF_VARS']['SYS']['formEngine']['nodeRegistry'][1433197759] = array(
+		'nodeName' => '3dCloud',
+		'priority' => 40,
+		'class' => \MyVendor\MyExtension\Form\Element\ShowTextAs3dCloudElement::class,
+	);
+
+
+Resolve class resolution to different render classes
+----------------------------------------------------
+
+In case the above API is not flexible enough, another class can be registered to resolve the final
+class that renders a certain element or container differently:
+
+.. code-block:: php
+
+	// Register FormEngine node type resolver hook to render RTE in FormEngine if enabled
+	$GLOBALS['TYPO3_CONF_VARS']['SYS']['formEngine']['nodeResolver'][1433198160] = array(
+		'nodeName' => 'text',
+		'priority' => 50,
+		'class' => \MyVendor\MyExtension\Form\Resolver\MyTextNodeResolver::class,
+	);
+
+
+This registers a resolver class at priority 50 if the type `text` should be rendered. This class must
+implement `TYPO3\CMS\Backend\Form\NodeResolverInterface` and can return a different class name that is
+called as render class. The render class in turn must implement `TYPO3\CMS\Backend\Form\NodeInterface`.
+
+The array key is a unix timestamp of the date when this resolver code is registered. Multiple resolvers
+are a chain, the resolver with highest priority is asked first, and the chain is called until one resolver
+returns a new class name. If no resolver returns anything, the default class name will be instantiated and rendered.
+
+Priority is between 0 and 100 and two resolvers for the same type and same priority will throw an exception.
+
+The resolver will receive the full `globalOptions` array with all settings to make a resolve decision
+on all incoming values.
+
+This API is used by core extension rtehtmlarea to route the rendering of `type=text` to its own
+`RichTextElement` class in case the editor is enabled for this field and for the user.
+
+This API allows fine grained resolution of render-nodes based on any need, for instance it would be
+easily possible to call another different richtext implementation (eg. TinyMCE) for specific fields
+of own extensions based on moon phases or your fathers birthday, by adding a resolver class with a higher priority.
+
+
+Warning
+-------
+
+The internal data given to the resolver class still may change. Both the `globalOptions` and the current
+`renderType` values are subject to change without further notice until TYPO3 CMS 7 LTS.
+
+
+.. index:: PHP-API, TCA, Backend

Documentation/Changelog/7.3/Feature-67319-AddFieldCopyrightToEXTfilemetadata.rst

@@ -0,0 +1,24 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-67319:
+
+===========================================================
+Feature: #67319 - Add field "copyright" to EXT:filemetadata
+===========================================================
+
+See :issue:`67319`
+
+Description
+===========
+
+The field "copyright" has been added to the meta data of a FAL record
+
+
+Impact
+======
+
+The new field can be used in all new projects. There is no interference with any part of existing code.
+
+
+.. index:: FAL, Database

Documentation/Changelog/7.3/Important-66614-ChecksumForProcessedFilesChanged.rst

@@ -0,0 +1,37 @@
+
+.. include:: /Includes.rst.txt
+
+.. _important-66614:
+
+===================================================================
+Important: #66614 - Checksums for processed files have been changed
+===================================================================
+
+See :issue:`66614`
+
+Description
+===========
+
+The base data used for the checksum calculation of processed files has been changed.
+The checksum is used to identify changes which require regeneration of processed files.
+
+Formerly the `GFX` section of the `TYPO3_CONF_VARS` was included in this base data,
+which caused weird problems in some cases.
+
+With TYPO3 CMS 7.3 (and 6.2.13) this has been changed. In case you are adjusting `GFX` settings and you want
+processed files to be regenerated, you need to manually clean the existing processed files by using the Clean up
+utility in the Install Tool.
+
+Since the base data is different now, the Core would not recognize the existing processed files as valid files and would
+delete those and build a new version.
+In case you are having a large installation, you might want to avoid this costly operation.
+The Install Tool provides a dedicated Upgrade Wizard for you, which avoids the expensive regeneration of processed files
+by updating the checksum of all existing processed files.
+
+.. note::
+
+	The Upgrade Wizard is only relevant for you if you're upgrading from any TYPO3 CMS version below 7.3 or 6.2.13.
+	Any upgrade from 7.3 or later or from 6.2.13 or later to a newer version does **not** require to run the wizard.
+
+
+.. index:: Database

Documentation/Changelog/7.3/Important-67248-CleanUpDataMapperconvertClassNameToTableName.rst

@@ -0,0 +1,18 @@
+
+.. include:: /Includes.rst.txt
+
+.. _important-67248:
+
+====================================================================
+Important: #67248 - Clean up DataMapper::convertClassNameToTableName
+====================================================================
+
+See :issue:`67248`
+
+Description
+===========
+
+As a side-effect of cleaning up `DataMapper::convertClassNameToTableName` the argument `$className` is now mandatory.
+
+
+.. index:: PHP-API, ext:extbase

Documentation/Changelog/7.3/Important-67401-DependencyInjectionIsNowDoneBeforeInitializeObject.rst

@@ -0,0 +1,27 @@
+
+.. include:: /Includes.rst.txt
+
+.. _important-67401:
+
+==============================================================================
+Important: #67401 - Dependency Injection is now done before initializeObject()
+==============================================================================
+
+See :issue:`67401`
+
+Description
+===========
+
+Formerly `initializeObject()` was called before the dependencies were injected when retrieving an Extbase Domain
+Model. This behavior didn't match either the documentation_ nor the behavior when using the `ObjectManager`.
+
+With TYPO3 CMS 7.3 this has been changed, dependency injection using `@inject` annotations and `inject*()` methods
+is now performed **before** calling `initializeObject()` when retrieving Domain Models.
+
+This may have impact on extensions that are relying on the reversed call order. In these cases adjustments are
+required to take into account that the injected objects are available.
+
+.. _documentation: https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/DependencyInjection/Index.html
+
+
+.. index:: PHP-API, ext:extbase

Documentation/Changelog/7.3/Index.rst

@@ -0,0 +1,52 @@
+:template: changelogOverview.html
+.. include:: /Includes.rst.txt
+..  _changelog-7-3:
+
+7.3 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-*