TYPO3 v15 dev-main snapshot ()

Documentation/Changelog/7.1/Breaking-24900-CompatVersion-Setting-Removed.rst

@@ -0,0 +1,44 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-24900:
+
+======================================================================
+Breaking: #24900 - Remove $TYPO3_CONF_VARS[SYS][compat_version] option
+======================================================================
+
+See :issue:`24900`
+
+Description
+===========
+
+The option `$TYPO3_CONF_VARS[SYS][compat_version]`, which was modified on update in the Install Tool wizard,
+has been removed.
+
+Any checks on `GeneralUtility::compat_version` are now made against the common constant `TYPO3_branch` instead of
+the former TYPO3_CONF_VARS option.
+
+Impact
+======
+
+Any usage of `$TYPO3_CONF_VARS[SYS][compat_version]` where the value is different than `TYPO3_branch` will result
+in unexpected behaviour.
+
+TypoScript conditions which check for older compat_version will have different behaviour now.
+
+Affected installations
+======================
+
+Any installation where `$TYPO3_CONF_VARS[SYS][compat_version]` was not set to the currently running version
+or where the value of compat_version was used to simulate behaviour of an older version.
+E.g. TypoScript conditions or `GeneralUtility::compat_version` in extensions.
+
+
+Migration
+=========
+
+Remove any direct usage of the option, and use the "compat_version" method within `GeneralUtility` as well as the
+TypoScript condition "compat_version" which gives more accurate results.
+
+
+.. index:: LocalConfiguration, PHP-API, TypoScript

Documentation/Changelog/7.1/Breaking-44879-CSSStyledContentTypoScriptBlockQuoteInlineStylesRemoved.rst

@@ -0,0 +1,49 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-44879:
+
+=======================================================================
+Breaking: #44879 - TypoScript inline styles from blockquote tag removed
+=======================================================================
+
+See :issue:`44879`
+
+Description
+===========
+
+CSS Styled Content renders blockquote tags using :code:`lib.parseFunc_RTE` TypoScript.
+For TYPO3 CMS 7.1, the following TypoScript lines have been removed without substitution:
+
+.. code-block:: typoscript
+
+    lib.parseFunc_RTE.externalBlocks.blockquote.callRecursive.tagStdWrap.HTMLparser = 1
+    lib.parseFunc_RTE.externalBlocks.blockquote.callRecursive.tagStdWrap.HTMLparser.tags.blockquote.overrideAttribs = style="margin-bottom:0;margin-top:0;"
+
+The effect is that the following inline styles have been removed from blockquote tags without substitution:
+
+.. code-block:: css
+
+	margin-bottom:0;
+	margin-top:0;
+
+Impact
+======
+
+Styling of blockquote tags based on CSS Styled Content could differ after an upgrade to CMS 7.1.
+
+
+Affected installations
+======================
+
+All CMS 7.1 installations that were upgraded from 7.0 and below which use blockquote tags rendered by :code:`lib.parseFunc_RTE`.
+
+
+Migration
+=========
+
+It is recommended to fix the margins inside your website CSS. Alternatively, you can re-add the above TypoScript lines
+to your website TypoScript template (not recommended).
+
+
+.. index:: TypoScript, Frontend, ext:css_styled_content

Documentation/Changelog/7.1/Breaking-57089-ShortcutBehaviour.rst

@@ -0,0 +1,39 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-57089:
+
+=====================================================================================
+Breaking: #57089 - Behaviour of page shortcut to "Parent of selected or current page"
+=====================================================================================
+
+See :issue:`57089`
+
+Description
+===========
+
+In former versions of TYPO3 CMS the page shortcut type "Parent of selected or current page" had a misleading label
+as the selected page was never taken into account, it always chose the parent of the current page.
+
+This has been changed and the selected page is now considered, so the parent of the selected page will be used as the target page.
+
+Impact
+======
+
+Assuming the supplied upgrade wizard was run, the behaviour of existing shortcuts will not change.
+
+If you fail to run the upgrade wizard, the target of a shortcut is changed to the parent of the
+selected page as the selected page is now respected.
+
+Affected installations
+======================
+
+Any installation using shortcut pages with shortcut type "Parent of selected or current page"
+
+Migration
+=========
+
+Run the supplied upgrade wizard in the Install Tool if it shows up.
+
+
+.. index:: PHP-API, Backend

Documentation/Changelog/7.1/Breaking-61510-IndexedSearch.rst

@@ -0,0 +1,60 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-61510:
+
+================================================
+Breaking: #61510 - Improvement of indexed_search
+================================================
+
+See :issue:`61510`
+
+Description
+===========
+
+The extension indexed_search is improved in the backend and frontend.
+
+Backend
+-------
+
+Previously the functionality of indexed_search has been scattered to multiple modules.
+Information about indexed_search was available in a custom module in "Admin tools" and 2 sections in the "Info" module.
+
+The complete code has been moved to a central place, which is now a custom module in the area "Web" and has been rewritten
+by using Extbase & Fluid. Translations and a modern UI have been added as well.
+
+
+Impact
+======
+
+Changes in the Backend
+----------------------
+
+The previous user configuration for indexed_search modules is not working anymore.
+Therefore editors won't see the module anymore after login.
+
+Changes in the Frontend
+-----------------------
+
+The TypoScript configuration changed. If indexed_search is installed, it is automatically activated:
+
+.. code-block:: typoscript
+
+	config.index_enable = 1
+	config.index_externals = 1
+
+Affected installations
+======================
+
+All installations using indexed_search
+
+Migration
+=========
+
+Backend
+-------
+
+Reconfigure the backend users and groups if users need to see the module of indexed_search.
+
+
+.. index:: PHP-API, Backend, Frontend, TypoScript, ext:indexed_search

Documentation/Changelog/7.1/Breaking-62415-DisableAutoCreateRemoved.rst

@@ -0,0 +1,34 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-62415:
+
+===========================================================================
+Breaking: #62415 - Remove deprecated disable_autocreate field in workspaces
+===========================================================================
+
+See :issue:`62415`
+
+Description
+===========
+
+The field "disable_autocreate" from ext:workspaces has been removed.
+
+Impact
+======
+
+If a 3rd party extension relies on the removed field an SQL error will be thrown.
+
+
+Affected installations
+======================
+
+An installation is affected if a 3rd party extension relies on the removed field in the database.
+
+Migration
+=========
+
+Remove any usage of the removed field in 3rd party extensions.
+
+
+.. index:: Database, Backend, ext:workspaces

Documentation/Changelog/7.1/Breaking-62886-RemoveMeaningfulTempFilePrefix.rst

@@ -0,0 +1,36 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-62886:
+
+==================================================================
+Breaking: #62886 - Removed setting config.meaningfulTempFilePrefix
+==================================================================
+
+See :issue:`62886`
+
+Description
+===========
+
+The setting *config.meaningfulTempFilePrefix* which was still used for images built by GIFBUILDER that were saved in
+typo3temp/GB/ has been removed. With this option it was possible to configure a meaningful file prefix limiting
+the filename prefix to a certain character length.
+
+Impact
+======
+
+All files will always have their original filename fully prepended when stored in the folder typo3temp/GB/.
+
+Affected Installations
+======================
+
+All installations using GIFBUILDER to generate images. The files within typo3temp/GB/ will now be called
+with the full name of each original file before the hash and the file extension.
+
+Migration
+=========
+
+The setting should be removed from any TypoScript configuration because it has no impact anymore.
+
+
+.. index:: TypoScript, Frontend

Documentation/Changelog/7.1/Breaking-62925-RemoveExtJsDateTimePicker.rst

@@ -0,0 +1,35 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-62925:
+
+======================================================
+Breaking: #62925 - ExtJS Ext.ux.DateTimePicker removed
+======================================================
+
+See :issue:`62925`
+
+Description
+===========
+
+The old ExtJS component Ext.ux.DateTimePicker has been removed and replaced with a
+bootstrap alternative. For technical reasons, the feature had to be removed.
+Thus the possibility to use "+3d" or "today" in input fields is no longer
+available.
+
+
+Impact
+======
+
+Extensions which rely on Ext.ux.DateTimePicker will break.
+
+
+Migration
+=========
+
+Use the new bootstrap DateTimePicker component which can be loaded with
+require.js. Example implementations can be found in EXT:belog, EXT:scheduler
+and the FormEngine component of the TYPO3 CMS core.
+
+
+.. index:: JavaScript, Backend

Documentation/Changelog/7.1/Breaking-63296-Removed-Files.rst

@@ -0,0 +1,45 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-63296:
+
+==================================================
+Breaking: #63296 - Deprecated typo3/ files removed
+==================================================
+
+See :issue:`63296`
+
+Description
+===========
+
+The following script entry points have been removed without substitution:
+
+- typo3/file_edit.php
+- typo3/file_newfolder.php
+- typo3/file_rename.php
+- typo3/file_upload.php
+- typo3/show_rechis.php
+- typo3/listframe_loader.php
+
+The corresponding ListFrameLoaderController class is now marked as deprecated.
+
+Impact
+======
+
+Any script pointing to one of these file resources will trigger a 404 server response.
+
+Affected installations
+======================
+
+An extension needs to be adapted in the unlikely case that it uses a link to any of the files.
+
+Migration
+=========
+
+The functionality of these scripts (except listframe_loader.php which is not used at all any more) have been moved to "modules".
+Use BackendUtility::getModuleUrl() to link to them. The module name is identical to the file name without the ".php" suffix.
+
+e.g. BackendUtility::getModuleUrl('file_edit');
+
+
+.. index:: PHP-API, Backend

Documentation/Changelog/7.1/Breaking-63310-Wizard-Modules-Moved.rst

@@ -0,0 +1,36 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-63310:
+
+================================================
+Breaking: #63310 - Web=>Functions=>Wizards moved
+================================================
+
+See :issue:`63310`
+
+Description
+===========
+
+The two module functions "Create Pages" and "Sort Pages" located within the extensions "wizard_crpages" and
+"wizard_sortpages" were located under Web => Functions => Wizards. This structure is now simplified as the wizards
+are moved one level up in Web => Functions.
+
+Impact
+======
+
+Any options set via TSconfig for these wizards for the module menu have changed. The existing options don't work
+anymore.
+
+Affected installations
+======================
+
+Any installation using TSconfig like "web_func.menu.wiz" needs to be adapted.
+
+Migration
+=========
+
+The respective options "web_func.menu.wiz" have been moved to "web_func.menu.functions".
+
+
+.. index:: TSConfig, Backend, ext:wizard_crpages, ext:wizard_sortpages

Documentation/Changelog/7.1/Breaking-63431-BackendToolbarRefactored.rst

@@ -0,0 +1,45 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-63431:
+
+=============================================
+Breaking: #63431 - Backend toolbar refactored
+=============================================
+
+See :issue:`63431`
+
+Description
+===========
+
+The upper right backend toolbar has been refactored with TYPO3 CMS 7.0. A new PHP interface
+and a new registration were introduced.
+
+
+Impact
+======
+
+Extensions that are not adapted to the new interface will not show up in the toolbar anymore, but
+will not throw a fatal PHP error.
+
+Method BackendController::addToolbarItem() has been marked as deprecated.
+
+
+Affected installations
+======================
+
+If a TYPO3 CMS instance uses extensions based on the old interface and registration, the
+according items will no longer show up in the toolbar.
+
+
+Migration
+=========
+
+Extensions must implement the new interface \TYPO3\CMS\Backend\Toolbar\ToolbarItemInterface
+and must be registered in $GLOBALS['TYPO3_CONF_VARS']['BE']['toolbarItems'].
+
+Warning: The new interface is not 100% finished, method `checkAccess()` will probably be
+substituted by two other methods in later versions of TYPO3 CMS.
+
+
+.. index:: PHP-API, Backend

Documentation/Changelog/7.1/Breaking-63437-ClassAliasesMovedToLegacyExtension.rst

@@ -0,0 +1,52 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-63437:
+
+==========================================================
+Breaking: #63437 - Class aliases moved to legacy extension
+==========================================================
+
+See :issue:`63437`
+
+Description
+===========
+
+With the switch to namespaced classes in TYPO3 CMS 6.0, a class alias mechanism
+has been set up to support the old class names as aliases for a while. All those
+class aliases have been moved to the dedicated extension "compatibility6". This
+extension will be removed at some point during the development of TYPO3 CMS 7.
+
+Removing the class aliases from the core results in a significant performance gain
+especially during first load with empty caches.
+
+
+Impact
+======
+
+If extensions still rely on old non-namespaced class names, EXT:compatibility6 can
+be loaded to keep further backwards compatibility for now - with the side-effect of
+drained performance.
+
+
+Affected installations
+======================
+
+
+TYPO3 CMS 7 installations need EXT:compatibility6 loaded if old extensions are used that
+are still not adapted to the namespaced core classes.
+
+
+Migration
+=========
+
+During an upgrade, the "Extension check" of the install tool may find old extensions that
+still rely on old class names and can unload those. The backend may work again to load
+EXT:compatibility6, or to unload further extensions that rely on old class names.
+
+Another option is to manually set all extensions that rely on old class names to "inactive"
+in typo3conf/PackageStates.php, or to set EXT:compatibility6 to "active". If a manual change is
+done, typo3temp/Cache directory have to be flushed afterwards.
+
+
+.. index:: PHP-API

Documentation/Changelog/7.1/Breaking-63464-IncludeOnceArraysRemoved.rst

@@ -0,0 +1,50 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-63464:
+
+========================================================================
+Breaking: #63464 - Remove include_once inclusions inside ModuleFunctions
+========================================================================
+
+See :issue:`63464`
+
+Description
+===========
+
+The functionality to include PHP files within module functions (e.g. info module) via an `include_once` array
+has been removed. The API did not use the include_once array anymore and certain places were marked as deprecated
+since TYPO3 CMS 6.2. All module functions are using the common autoloading functionality via namespaced classes.
+
+The following `include_once` arrays within the following modules have been removed:
+
+* Web => Page
+* Web => Page - New Content Element Wizard
+* Web => Functions
+* Web => Info
+* Web => Template
+* Web => Recycler
+* User => Task Center
+* System => Scheduler
+
+Impact
+======
+
+Any non-API usage of the `include_once` array in any custom module function will fail.
+
+
+Affected installations
+======================
+
+Any installation with an extension using the property `$include_once` to load additional files via direct access instead
+of using the API via `ExtensionManagementUtility::insertModuleFunction()`.
+
+
+Migration
+=========
+
+Use the autoloader to load any custom classes inside your code, or any hooks if available in the custom module functions
+to include any file.
+
+
+.. index:: PHP-API, Backend

Documentation/Changelog/7.1/Breaking-63687-WebFunctionsWizards-Moved.rst

@@ -0,0 +1,42 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-63687-1668719172:
+
+====================================================================
+Breaking: #63687 - Web=>Functions=>Wizards moved to legacy extension
+====================================================================
+
+See :issue:`63687`
+
+Description
+===========
+
+Within the "Web" => "Functions" module was a nested layer called "Wizards" where "Sort pages" and
+"Bulk-create new pages" resided until TYPO3 CMS 7.1. These are now moved directly underneath "Web" => "Functions",
+so the "Wizards" module function becomes obsolete, and with it the whole extension called "func_wizards" that provided
+this nested layer. The module function "Wizards" has been moved to the legacy extension EXT:compatibility6. The
+extension "func_wizards" has been completely removed from the core.
+
+Impact
+======
+
+The existing "Functions" provided by the TYPO3 CMS Core are now directly dependant and hooked into "Web" => "Functions".
+Any extensions using "Web" => "Functions" => "Wizards" will not show up anymore.
+
+
+Affected installations
+======================
+
+TYPO3 CMS 7 installations need EXT:compatibility6 extension loaded if old extensions are still hooked into
+"Web" => "Functions" => "Wizards".
+
+Migration
+=========
+
+Any extension hooking into "Web" => "Functions" => "Wizards" need to be adapted. In their ext_tables.php the
+`insertModuleFunction` call does not need to have a 5th parameter given. EXT:compatibility6 is then no longer
+needed.
+
+
+.. index:: Backend

Documentation/Changelog/7.1/Breaking-63780-RemoveWordStringsFromReferenceIndex.rst

@@ -0,0 +1,40 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-63780:
+
+======================================================================================
+Breaking: #63780 - Remove public properties words and word_strings from ReferenceIndex
+======================================================================================
+
+See :issue:`63780`
+
+Description
+===========
+
+Public properties `words` and `word_strings` have been removed from class `\TYPO3\CMS\Core\Database\ReferenceIndex`.
+`ReferenceIndex->words` was always an empty array and `ReferenceIndex->word_strings` contained strings from
+input- and text fields of every record that was given to this class instance.
+
+
+Impact
+======
+
+An extension relying on one of these public properties will fail.
+
+
+Affected installations
+======================
+
+It is unlikely that any extension used the properties words or word_strings. An instance could be
+checked by searching for usages of class `ReferenceIndex`.
+
+
+Migration
+=========
+
+The according logic needs to be re-implemented in an extension that used the content of these
+properties.
+
+
+.. index:: PHP-API, Backend

Documentation/Changelog/7.1/Breaking-63818-RemovedStaticFileEdit.rst

@@ -0,0 +1,39 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-63818:
+
+=========================================================
+Breaking: #63818 - Removed Static file edit functionality
+=========================================================
+
+See :issue:`63818`
+
+Description
+===========
+
+A special TCA configuration enabled RTE fields to write its content to sections within files. The configuration
+was done in `defaultExtras` array, `static_write` section and documented in
+TCA reference->AdditionalFeatures->SpecialConfigurationOptions.
+
+This functionality has been removed without substitution.
+
+Impact
+======
+
+Content of RTE fields can no longer be written to files.
+
+
+Affected installations
+======================
+
+In the unlikely case that this feature was used by anyone its usage can be located by searching for `static_write`
+keyword in TCA configuration.
+
+Migration
+=========
+
+Move this logic elsewhere, eg. use hooks in DataHandler to write out DB content.
+
+
+.. index:: TCA, RTE, Backend

Documentation/Changelog/7.1/Breaking-64059-Rewritten-JavaScript-Tree-Components.rst

@@ -0,0 +1,46 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-64059:
+
+=======================================================
+Breaking: #64059 - Rewritten Javascript Tree Components
+=======================================================
+
+See :issue:`64059`
+
+Description
+===========
+
+In the process of refactoring prototype/scripta.culo.us code and migrate these to an AMD module, the tree component and its
+drag&drop parts have been migrated to a RequireJS / jQuery module.
+
+The page tree filter functionality of the prototype tree, which is not used in the TYPO3 core, was removed from the
+tree component.
+
+The file :file:`typo3/js/tree.js` has been removed, the replacement code, based on jQuery is located under
+EXT:backend/Resources/Public/JavaScript/LegacyTree.js.
+
+
+Impact
+======
+
+Any usages in third party extensions that include :file:`js/tree.js` will fail, as the tree component has been removed.
+Any extension using the filter part of the tree.js component will not work.
+
+
+Affected installations
+======================
+
+Any installation with its own backend module using the tree component from the core.
+
+
+Migration
+=========
+
+Rewrite any needed logic for filtering, and include the RequireJS module like in e.g.
+FileSystemNavigationFrameController.php, to use the tree component. If the old code is needed, the :file:`tree.js` file
+and prototype need to be included as part of the extension, not from the core.
+
+
+.. index:: JavaScript, Backend

Documentation/Changelog/7.1/Breaking-64070-GlobalWebmountsRemoved.rst

@@ -0,0 +1,35 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-64070:
+
+====================================================
+Breaking: #64070 - Removed global variable WEBMOUNTS
+====================================================
+
+See :issue:`64070`
+
+Description
+===========
+
+The global variable WEBMOUNTS has been removed, as the same data from the WEBMOUNTS can always be fetched via
+`$GLOBALS['BE_USER']->returnWebmounts()`.
+
+Impact
+======
+
+The variable `$GLOBALS['WEBMOUNTS']` will no longer be filled.
+
+
+Affected installations
+======================
+
+Any installation using `$GLOBALS['WEBMOUNTS']` directly within an extension will produce a wrong result.
+
+Migration
+=========
+
+Replace all occurrences of `$GLOBALS['WEBMOUNTS']` with `$GLOBALS['BE_USER']->returnWebmounts()`.
+
+
+.. index:: PHP-API, Backend

Documentation/Changelog/7.1/Breaking-64102-MoveT3TableAndT3ButtonToBootstrap.rst

@@ -0,0 +1,40 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-64102:
+
+===========================================================
+Breaking: #64102 - Move t3-table and t3-button to bootstrap
+===========================================================
+
+See :issue:`64102`
+
+Description
+===========
+
+In transition to full bootstrap coverage and streamlining the backend, we are dropping the support for the CSS classes
+.t3-table and .t3-button. We are replacing them with the corresponding bootstrap CSS classes for tables and buttons.
+See http://getbootstrap.com/css/#tables and http://getbootstrap.com/css/#buttons for more details.
+
+
+Impact
+======
+
+Custom implementations of tables and buttons in backend modules will lose the TYPO3 default styling.
+
+
+Affected installations
+======================
+
+Extensions that provide custom backend modules that are using the css classes `.t3-table` or `.t3-button`.
+
+
+Migration
+=========
+
+For tables we recommend the usage of the CSS class combination `table table-striped table-hover` instead of `t3-table`.
+
+For buttons we recommend the usage of the CSS class combination `btn btn-default` instead of `t3-button`.
+
+
+.. index:: Backend

Documentation/Changelog/7.1/Breaking-64131-ResizableTextareasOptionDropped.rst

@@ -0,0 +1,23 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-64131:
+
+====================================================
+Breaking: #64131 - Resizable Textarea option removed
+====================================================
+
+See :issue:`64131`
+
+Description
+===========
+
+The User Setting "Resizable Textarea" for FormEngine textarea fields has been removed.
+
+Impact
+======
+
+The option and its feature are no longer available.
+
+
+.. index:: Backend

Documentation/Changelog/7.1/Breaking-64143-FlagFilesMoved.rst

@@ -0,0 +1,35 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-64143:
+
+======================================================
+Breaking: #64143 - Language / Country Flag files moved
+======================================================
+
+See :issue:`64143`
+
+Description
+===========
+
+The static GIF file collection representing flags within :file:`typo3/gfx/flags/` has been removed. All PNG flag images
+from EXT:t3skin are moved from :file:`typo3/sysext/t3skin/images/flags/` to
+:file:`typo3/sysext/core/Resources/Public/Icons/flags/`. The according stylesheets for the that :file:`flags-*` icon
+files have been moved to EXT:core as well.
+
+Impact
+======
+
+Any hard-coded reference on any of the files within :file:`typo3/gfx/flags/` and
+:file:`typo3/sysext/core/Resources/Public/Icons/flags/` will result in an error.
+
+Changing the EXT:t3skin flags sprite now means changing the flags sprite of EXT:core.
+
+Affected installations
+======================
+
+Any installation using third-party extensions that access :file:`typo3/gfx/flags/` or
+:file:`typo3/sysext/t3skin/images/flags/` will fail.
+
+
+.. index:: PHP-API, Backend

Documentation/Changelog/7.1/Breaking-64190-FormEngineCheckboxElement.rst

@@ -0,0 +1,39 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-64190:
+
+=========================================================================
+Breaking: #64190 - FormEngine Checkbox Element limitation of cols setting
+=========================================================================
+
+See :issue:`64190`
+
+Description
+===========
+
+The TCA configuration for checkbox cols has been changed. We reduced the
+number of accepted values to 1, 2, 3, 4 and 6 to provide a responsive experience.
+
+For usecases like checkboxes for weekdays like mo, tu, we, th, fr, sa, su
+we introduced a new value `inline`.
+
+Impact
+======
+
+For values equals 5 or above 6 the rendering of 6 will be used.
+
+
+Affected installations
+======================
+
+Installations with TCA column configurations for checkboxes with values
+equals 5 or above 6.
+
+Migration
+=========
+
+Choose between one of the supported values or change the display to `inline`.
+
+
+.. index:: TCA, Backend

Documentation/Changelog/7.1/Breaking-64226-OptionAccessListRenderModeRemoved.rst

@@ -0,0 +1,52 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-64226:
+
+============================================================================
+Breaking: #64226 - Option $TYPO3_CONF_VARS[BE][accessListRenderMode] removed
+============================================================================
+
+See :issue:`64226`
+
+Description
+===========
+
+The `$GLOBALS[TYPO3_CONF_VARS][BE][accessListRenderMode]` option, which acted as a shorthand function
+to set permission-related fields for modules and excludeFields, has been removed.
+
+All corresponding fields in TCA tables be_users and be_groups are set to the already-default value `checkbox`
+given in the DefaultConfiguration.php file.
+
+Impact
+======
+
+All respective fields will show up as a checkbox selection within FormEngine (implying the value
+`renderMethod=checkbox`).
+
+
+Affected installations
+======================
+
+Installations having this option set to something different than `checkbox` will result in a having the fields
+displayed as checkboxes.
+
+Migration
+=========
+
+Choose between the default value `checkbox` (no change required then) or set the following values inside the
+`Configuration/TCA/Overrides` files of your project specific extension to the option of your needs.
+
+.. code-block:: php
+
+	$GLOBALS['TCA']['be_users']['columns']['file_permissions']['config']['renderMode'] = 'singlebox';
+	$GLOBALS['TCA']['be_users']['columns']['userMods']['config']['renderMode'] = 'singlebox';
+	$GLOBALS['TCA']['be_groups']['columns']['file_permissions']['config']['renderMode'] = 'singlebox';
+	$GLOBALS['TCA']['be_groups']['columns']['pagetypes_select']['config']['renderMode'] = 'singlebox';
+	$GLOBALS['TCA']['be_groups']['columns']['tables_select']['config']['renderMode'] = 'singlebox';
+	$GLOBALS['TCA']['be_groups']['columns']['tables_modify']['config']['renderMode'] = 'singlebox';
+	$GLOBALS['TCA']['be_groups']['columns']['non_exclude_fields']['config']['renderMode'] = 'singlebox';
+	$GLOBALS['TCA']['be_groups']['columns']['userMods']['config']['renderMode'] = 'singlebox';
+
+
+.. index:: LocalConfiguration, TCA, Backend

Documentation/Changelog/7.1/Breaking-64229-TrimSubmittedLoginFormData.rst

@@ -0,0 +1,40 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-64229:
+
+==============================================================
+Breaking: #64229 - Trim submitted login-form-data before usage
+==============================================================
+
+See :issue:`64229`
+
+Description
+===========
+
+Data submitted through the login-forms (frontend and backend) will now be trimmed before the login is performed.
+So now all fields (like username or password) with leading/trailing whitespace will have those removed.
+Any whitespace inside fields will not be touched.
+
+
+Impact
+======
+
+Users that have had whitespace at the beginning or end of their username or password will not be able to log in anymore.
+
+
+Affected installations
+======================
+
+Any installation relying on whitespace at the beginning or end of either a username or a password.
+Please note that the TYPO3 backend didn't allow whitespace for username in frontend or backend
+and only allowed whitespace for passwords of backend users until now.
+
+
+Migration
+=========
+
+Update usernames and/or passwords.
+
+
+.. index:: PHP-API, Backend, Frontend

Documentation/Changelog/7.1/Breaking-64637-CSSStyledContentLegacyTypoScriptRemoved.rst

@@ -0,0 +1,47 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-64637:
+
+================================================================================
+Breaking: #64637 - Compatibility CSS Styled Content TypoScript templates removed
+================================================================================
+
+See :issue:`64637`
+
+Description
+===========
+
+CSS Styled Content ships compatibility TypoScript templates for being compatible with older versions. For TYPO3 CMS 7,
+all templates to render a compatibility frontend for the following versions have been removed without substitution.
+
+* TYPO3 CMS 6.1
+* TYPO3 CMS 6.0
+* TYPO3 CMS 4.7
+* TYPO3 CMS 4.6
+* TYPO3 CMS 4.5
+
+Impact
+======
+
+It is not possible to have the TYPO3 CMS 7 Frontend rendering based on CSS Styled Content to behave like a version
+prior to TYPO3 CMS 6.2.
+
+
+Affected installations
+======================
+
+All installations using the TypoScript templates to have the TYPO3 frontend powered via CSS Styled Content with
+a compatibility TypoScript will result in no Frontend output.
+
+
+Migration
+=========
+
+For installations still needing the old templates, an old version of the template (e.g. from TYPO3 CMS 6.2)
+need to be included separately. Any other installation still using the old TypoScript templates should migrate to
+the latest TypoScript templates of CSS Styled Content by choosing the correct version inside the Web=>Template
+module.
+
+
+.. index:: Frontend, TypoScript

Documentation/Changelog/7.1/Breaking-64639-RemovedContentObjects.rst

@@ -0,0 +1,36 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-63687:
+
+====================================================================
+Breaking: #63687 - Outdated ContentObjects moved to legacy extension
+====================================================================
+
+See :issue:`63687`
+
+Description
+===========
+
+The TypoScript Content Objects (cObjects) CLEARGIF, COLUMNS, CTABLE, OTABLE and HRULER have been moved into the legacy extension
+EXT:compatibility6.
+
+Impact
+======
+
+Any TypoScript using the cObjects above will result in an empty output in the TYPO3 Frontend.
+
+
+Affected installations
+======================
+
+TYPO3 CMS 7 installations still using the cObjects need EXT:compatibility6 to be loaded if the rendering should
+be continued.
+
+Migration
+=========
+
+Any installation should migrate to alternatives such as FLUIDTEMPLATE to customize the output of the content.
+
+
+.. index:: Backend, Frontend, TypoScript

Documentation/Changelog/7.1/Breaking-64643-RemoveEnableTypo3tempDbTracking.rst

@@ -0,0 +1,39 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-64643:
+
+========================================================================
+Breaking: #64643 - Remove functionality for enable_typo3temp_db_tracking
+========================================================================
+
+See :issue:`64643`
+
+Description
+===========
+
+The logic and the database table for tracking generated typo3temp/ images by GraphicalFunctions have been removed
+without substitution. The option to enable this functionality `$TYPO3_CONF_VARS[GFX][enable_typo3temp_db_tracking]`
+has been removed.
+
+
+Impact
+======
+
+Images generated with GraphicalFunctions with the option above enabled will not be tracked in the database anymore.
+
+
+Affected installations
+======================
+
+Any installation having the option `$TYPO3_CONF_VARS[GFX][enable_typo3temp_db_tracking]` enabled.
+
+
+Migration
+=========
+
+If the functionality or a similar functionality is needed for some edge-cases, an own implementation via a third-party
+extension is necessary.
+
+
+.. index:: LocalConfiguration

Documentation/Changelog/7.1/Breaking-64668-MailformMovedToLegacyExtension.rst

@@ -0,0 +1,58 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-64668:
+
+=====================================================================
+Breaking: #64668 - Content Element mailform moved to legacy extension
+=====================================================================
+
+See :issue:`64668`
+
+Description
+===========
+
+The fallback "mailform" functionality, containing the `FORM` ContentObject, the submission logic for sending mailform
+and the content element (CType=mailform) has been moved to the legacy extension "compatibility6". This mailform
+was available when the "Form" extension, introduced in TYPO3 CMS 4.7, was not installed.
+
+The following options have been marked for deprecation:
+
+.. code-block:: php
+
+	$TYPO3_CONF_VARS][FE][secureFormmail]
+	$TYPO3_CONF_VARS][FE][strictFormmail]
+	$TYPO3_CONF_VARS][FE][formmailMaxAttachmentSize]
+
+The following methods within TypoScriptFrontendController have been removed:
+
+.. code-block:: php
+
+	protected checkDataSubmission()
+	protected sendFormmail()
+	public extractRecipientCopy()
+	public codeString()
+	protected roundTripCryptString()
+
+
+Impact
+======
+
+Mailform elements are missing and not rendered in the frontend anymore unless EXT:compatibility6 is loaded.
+
+
+Affected installations
+======================
+
+Any installation using the fallback "mailform" Content Element, the FrontendDataSubmissionController or the FORM
+Content Object directly will break. Additionally, any third party extension using the TypoScriptFrontendController
+methods directly will stop working with a fatal error.
+
+Migration
+=========
+
+For TYPO3 CMS 7, installing EXT:compatibility6 brings back the existing functionality. For the long term the affected
+installations should migrate to a different, better suited solution for sending mails and building forms.
+
+
+.. index:: PHP-API, Backend, Frontend, LocalConfiguration, ext:form, TypoScript

Documentation/Changelog/7.1/Breaking-64671-ContentObjectImgTextMovedToLegacyExtension.rst

@@ -0,0 +1,36 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-64671:
+
+===========================================================================
+Breaking: #64671 - Outdated ContentObject IMGTEXT moved to legacy extension
+===========================================================================
+
+See :issue:`64671`
+
+Description
+===========
+
+The TypoScript Content Object IMGTEXT has been moved to the legacy extension "compatibility6".
+
+Impact
+======
+
+Any TypoScript using the cObject directly or via CSS Styled Content configured using `renderMethod=table` will result
+in an empty output in the TYPO3 Frontend.
+
+
+Affected installations
+======================
+
+TYPO3 CMS 7 installations still using the cObject need EXT:compatibility6 to be loaded.
+
+Migration
+=========
+
+Any installation should migrate to alternatives such as CSS Styled Content without a table-based rendering for
+text w/ image elements to customize the output of content.
+
+
+.. index:: Backend, Frontend, TypoScript

Documentation/Changelog/7.1/Breaking-64696-MoveSearchCTypeToLegacyExtension.rst

@@ -0,0 +1,39 @@
+
+.. include:: /Includes.rst.txt
+
+.. _breaking-64696:
+
+=====================================================================
+Breaking: #64696 - Content Element "search" moved to legacy extension
+=====================================================================
+
+See :issue:`64696`
+
+Description
+===========
+
+The TYPO3 default `search` functionality, which was based on the `FORM` and `SEARCHRESULTS` ContentObjects and the
+content element CType=search itself has been moved to the legacy extension EXT:compatibility6.
+
+
+Impact
+======
+
+Content elements of the Type "Search" are gone and will no longer be rendered in the frontend
+unless EXT:compatibility6 is loaded. TypoScript using `SEARCHRESULTS` directly will return nothing.
+
+
+Affected installations
+======================
+
+Any installation using the simple "search" content element or the `SEARCHRESULTS` ContentObject directly will break.
+
+
+Migration
+=========
+
+For TYPO3 CMS 7, installing EXT:compatibility6 brings back the existing functionality. For the long term
+the affected installations should be migrate to a better suited solution for searching.
+
+
+.. index:: Frontend, Backend, TypoScript

Documentation/Changelog/7.1/Deprecation-24387-Xhtml2.rst

@@ -0,0 +1,31 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-24387:
+
+===================================================================
+Deprecation: #24387 - TypoScript option config.xhtmlDoctype=xhtml_2
+===================================================================
+
+See :issue:`24387`
+
+Description
+===========
+
+The TypoScript option `config.xhtmlDoctype = xhtml_2` is marked for removal in CMS 8, due to the W3C decision to
+fully work on HTML5 instead of XHTML2. See http://www.w3.org/MarkUp/ and http://www.w3.org/News/2010.html#entry-8982
+for more details.
+
+
+Affected installations
+======================
+
+Any TYPO3 installation with TypoScript that relies on `config.xhtmlDoctype = xhtml_2`.
+
+Migration
+=========
+
+Use other doctypes like html5 to render the frontend of the TYPO3 site.
+
+
+.. index:: TypoScript, Frontend

Documentation/Changelog/7.1/Deprecation-25112-andWhere.rst

@@ -0,0 +1,63 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-25112:
+
+==============================================================
+Deprecation: #25112 - Deprecate TypoScript property "andWhere"
+==============================================================
+
+See :issue:`25112`
+
+Description
+===========
+
+The select-property `andWhere` has been marked as deprecated.
+
+Impact
+======
+
+A deprecation message is logged for every usage of this property.
+
+
+Affected installations
+======================
+
+All installations or extensions using the select-property `andWhere`.
+
+
+Migration
+=========
+
+Use the properties `where` and `markers` instead.
+
+.. code-block:: typoscript
+
+	page.30 = CONTENT
+	page.30 {
+		table = tt_content
+		select {
+			pidInList = this
+			orderBy = sorting
+			where {
+				dataWrap = sorting>{field:sorting}
+			}
+		}
+	}
+	page.60 = CONTENT
+	page.60 {
+		table = tt_content
+		select {
+			pidInList = 73
+			where = header != ###whatever###
+			orderBy = ###sortfield###
+			markers {
+				whatever.data = GP:first
+				sortfield.value = sor
+				sortfield.wrap = |ting
+			}
+		}
+	}
+
+
+.. index:: TypoScript, Frontend

Documentation/Changelog/7.1/Deprecation-46523-BackendUtilityImplodeTSParams.rst

@@ -0,0 +1,31 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-46523:
+
+=======================================================
+Deprecation: #46523 - BackendUtility::implodeTSParams()
+=======================================================
+
+See :issue:`46523`
+
+Description
+===========
+
+The method `TYPO3\CMS\Backend\Utility\BackendUtility::implodeTSParams()` has been marked as deprecated and will be
+removed in TYPO3 CMS 8.
+
+
+Impact
+======
+
+Any installation with third-party extensions using this method will throw a deprecation warning.
+
+
+Affected installations
+======================
+
+Any installation with third-party extensions using the method.
+
+
+.. index:: PHP-API, Backend

Documentation/Changelog/7.1/Deprecation-46770-LocalImageProcessorGraphicalFunctions.rst

@@ -0,0 +1,36 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-46770:
+
+==============================================================================
+Deprecation: #46770 - Deprecate LocalImageProcessor::getTemporaryImageWithText
+==============================================================================
+
+See :issue:`46770`
+
+Description
+===========
+
+The public method `LocalImageProcessor::getTemporaryImageWithText()` has been marked as deprecated, it is directly
+replaced by `\TYPO3\CMS\Core\Imaging\GraphicalFunctions::getTemporaryImageWithText()`.
+
+
+Impact
+======
+
+Calling `LocalImageProcessor::getTemporaryImageWithText()` will trigger a deprecation log message.
+
+Affected installations
+======================
+
+TYPO3 Installations with custom extensions using the API of the File Abstraction Layer for custom image processing.
+
+Migration
+=========
+
+Replace all calls to the method to the `LocalImageProcessor` with an instantiation of `GraphicalFunctions` and a call
+to `getTemporaryImageWithText()` on the `GraphicalFunctions` object.
+
+
+.. index:: PHP-API

Documentation/Changelog/7.1/Deprecation-49247-textStyleTableStyleAddParams.rst

@@ -0,0 +1,38 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-49247:
+
+=================================================================================
+Deprecation: #49247 - Deprecate TypoScript functions "textStyle" and "tableStyle"
+=================================================================================
+
+See :issue:`49247`
+
+Description
+===========
+
+The following stdWrap methods have been marked as deprecated:
+
+* textStyle
+* tableStyle
+
+Impact
+======
+
+Usage of the mentioned stdWrap methods is deprecated.
+
+
+Affected installations
+======================
+
+All installations or extensions using the stdWrap methods `textStyle` and `tableStyle`.
+
+
+Migration
+=========
+
+Use CSS instead.
+
+
+.. index:: TypoScript, Frontend

Documentation/Changelog/7.1/Deprecation-60559-MakeLoginBoxImage.rst

@@ -0,0 +1,38 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-60559:
+
+=========================================
+Deprecation: #60559 - makeLoginBoxImage()
+=========================================
+
+See :issue:`60559`
+
+Description
+===========
+
+Method `TYPO3\CMS\Backend\Controller::makeLoginBoxImage()` has been marked as deprecated.
+
+
+Impact
+======
+
+Backend login images are no longer rendered. The method body is empty and does not return rendered HTML any longer.
+
+
+Affected installations
+======================
+
+The method was unused with default backend login screen for a long time already, an installation is only affected if a
+3rd party extension was loaded that changed the default login screen and used `makeLoginBoxImage()` or the template marker
+`LOGINBOX_IMAGE`.
+
+
+Migration
+=========
+
+Free an affected 3rd party extension from using this method or unload the extension.
+
+
+.. index:: PHP-API, Backend

Documentation/Changelog/7.1/Deprecation-61605-ChangeNamingOfIncludeJSlibs.rst

@@ -0,0 +1,37 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-61605:
+
+=============================================================================
+Deprecation: #61605 - Change naming of TypoScript property page.includeJSlibs
+=============================================================================
+
+See :issue:`61605`
+
+Description
+===========
+
+The existing TypoScript option `page.includeJSlibs` has been renamed
+to `page.includeJSLibs` to follow the lower camel case naming scheme.
+The existing property has been marked as deprecated.
+
+Impact
+======
+
+The old property will be removed with CMS 8 and should be avoided if
+it has been used before.
+
+Affected Installations
+======================
+
+Any installation using the `page.includeJSlibs` option.
+
+Migration
+=========
+
+Search and replace all TypoScript code of the installation from
+`includeJSlibs` to `includeJSLibs`.
+
+
+.. index:: TypoScript, Frontend

Documentation/Changelog/7.1/Deprecation-62329-DocumentTemplate-table.rst

@@ -0,0 +1,36 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-62329:
+
+======================================================
+Deprecation: #62329 - Deprecate DocumentTable::table()
+======================================================
+
+See :issue:`62329`
+
+Description
+===========
+
+`DocumentTable::table()` has been marked as deprecated.
+
+
+Impact
+======
+
+Calling `table()` of the `DocumentTable` class will trigger a deprecation log message.
+
+
+Affected installations
+======================
+
+Instances which use `DocumentTable::table()` for rendering tables.
+
+
+Migration
+=========
+
+Use fluid for rendering instead.
+
+
+.. index:: PHP-API, Backend

Documentation/Changelog/7.1/Deprecation-62855-XHTMLCleaningMovedToLegacyExtension.rst

@@ -0,0 +1,49 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-62855:
+
+==============================================================================
+Deprecation: #62855 - "XHTML cleaning" functionality moved to legacy extension
+==============================================================================
+
+See :issue:`62855`
+
+Description
+===========
+
+XHTML cleaning is not necessary anymore, since modern technology bases completely on HTML5. Therefore the
+according functionality has been moved to the legacy extension EXT:compatibility6.
+
+The following TypoScript option has been marked for deprecation:
+
+.. code-block:: typoscript
+
+   config.xhtml_cleaning
+
+The following PHP method has been marked for deprecation:
+
+.. code-block:: php
+
+   TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController::doXHTML_cleaning()
+
+Impact
+======
+
+The content output of the TYPO3 frontend is not cleaned anymore unless EXT:compatibility6 is loaded.
+
+
+Affected installations
+======================
+
+Any installation having the TypoScript option :typoscript:`config.xhtml_cleaning`
+set will have different behaviour in the
+frontend rendering.
+
+Migration
+=========
+
+For TYPO3 CMS 7, installing EXT:compatibility6 brings back the existing functionality.
+
+
+.. index:: TypoScript, Frontend

Documentation/Changelog/7.1/Deprecation-63324-DataHandler-IncludeFileFunctions.rst

@@ -0,0 +1,36 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-62864-1668719172:
+
+===================================================================
+Deprecation: #62864 - DataHandler->include_filefunctions deprecated
+===================================================================
+
+See :issue:`62864`
+
+Description
+===========
+
+The public property `->include_filefunctions` has been marked as deprecated.
+It has not been formally defined and was only created dynamically in the code.
+
+Impact
+======
+
+In the history of the core this property has never been used (read). Extensions might have used it.
+
+
+Affected installations
+======================
+
+All installations running extensions that rely on reading this property. Currently no affected extensions are known.
+
+Migration
+=========
+
+If your extension needs to know whether the BasicFileUtility has been instantiated in DataHandler it
+could use `$datahandler->fileFunc instanceof \TYPO3\CMS\Core\Utility\File\BasicFileUtility`
+
+
+.. index:: PHP-API, Backend

Documentation/Changelog/7.1/Deprecation-63522-ClientRelatedConditionDevice.rst

@@ -0,0 +1,38 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-63522:
+
+=================================================================
+Deprecation: #63522 - Deprecate the "device" TypoScript condition
+=================================================================
+
+See :issue:`63522`
+
+Description
+===========
+
+Client related TypoScript conditions the `device` type condition have been marked as deprecated.
+
+Impact
+======
+
+Using a condition like `[device = wap]` is considered outdated and should be solved differently.
+
+Affected installations
+======================
+
+Instances with TypoScript that rely on `[device = ...]`.
+
+Migration
+=========
+
+* Most usual conditions for specific browsers can nowadays be turned into conditional CSS includes
+* Use libraries such as modernizr for browser support
+* If conditions for specific clients or devices are still needed, they
+  should be done with a userFunc condition and a project like WURFL
+  that keep the device information more recent than the current core
+  code like matching AMIGA
+
+
+.. index:: TypoScript, Frontend

Documentation/Changelog/7.1/Deprecation-64059-Pagetree-Navigation-Component.rst

@@ -0,0 +1,41 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-64059:
+
+==========================================================
+Deprecation: #64059 - Non-ExtJS Page Tree Navigation Frame
+==========================================================
+
+See :issue:`64059`
+
+Description
+===========
+
+The non-ExtJS page tree navigation frame which was used in the core until TYPO3 CMS 4.5, is still available and can be
+included within a module, if the module is registering a navFrameScript in ext_tables.php:
+
+.. code-block:: php
+
+	'navFrameScript' => 'alt_db_navframe.php'
+
+
+Impact
+======
+
+Usage of the PHP class, and the entry script typo3/alt_db_navframe.php has been marked as deprecated.
+
+
+Affected installations
+======================
+
+All installations with extensions using modules with the non-ExtJS page tree navigation frame.
+
+
+Migration
+=========
+
+Use the ExtJS navigationComponentID instead within the module registration.
+
+
+.. index:: PHP-API, JavaScript, Backend

Documentation/Changelog/7.1/Deprecation-64109-Hook-softRefParserGL.rst

@@ -0,0 +1,41 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-64109:
+
+============================================================
+Deprecation: #64109 - Deprecate global hook softRefParser_GL
+============================================================
+
+See :issue:`64109`
+
+
+Description
+===========
+
+The hook `$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['GLOBAL']['softRefParser_GL']` has been marked as deprecated.
+It was a hook to add a general softRefParser which parsed every SoftReference regardless of its type.
+The `softRefParser_GL`-hook was undocumented and used neither in core nor in any known extension.
+
+
+Impact
+======
+
+Creating a global softRefParser by adding a hook to
+`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['GLOBAL']['softRefParser_GL']` will trigger a deprecation log message.
+
+
+Affected installations
+======================
+
+Instances with extensions using a `$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['GLOBAL']['softRefParser_GL']`-hook
+
+
+Migration
+=========
+
+A `softRefParser_GL` hook in an extension has to be replaced with multiple `softRefParser` hooks for each type the
+parser can handle.
+
+
+.. index:: PHP-API

Documentation/Changelog/7.1/Deprecation-64134-TypoScriptTemplateObjectBrowserModuleFunctionController-verify_TSobjects.rst

@@ -0,0 +1,36 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-64134-1668719172:
+
+===========================================================================================================
+Deprecation: #64134 - Deprecate TypoScriptTemplateObjectBrowserModuleFunctionController::verify_TSobjects()
+===========================================================================================================
+
+See :issue:`64134`
+
+Description
+===========
+
+`TypoScriptTemplateObjectBrowserModuleFunctionController::verify_TSobjects()` has been marked as deprecated.
+
+
+Impact
+======
+
+Using `TypoScriptTemplateObjectBrowserModuleFunctionController::verify_TSobjects()` will trigger a deprecation log message.
+
+
+Affected installations
+======================
+
+Instances which use of `TypoScriptTemplateObjectBrowserModuleFunctionController::verify_TSobjects()`.
+
+
+Migration
+=========
+
+No migration possible.
+
+
+.. index:: PHP-API, Backend

Documentation/Changelog/7.1/Deprecation-64147-ConstantEditorFunctions.rst

@@ -0,0 +1,38 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-64147:
+
+======================================================
+Deprecation: #64147 - TemplateService->ext_getKeyImage
+======================================================
+
+See :issue:`64147`
+
+Description
+===========
+
+`ExtendedTemplateService::ext_getKeyImage()` has been marked as deprecated.
+`ConfigurationForm::ext_getKeyImage()` has been marked as deprecated.
+
+
+Impact
+======
+
+Using the two methods will throw a deprecation message.
+
+
+Affected installations
+======================
+
+TYPO3 installations with extensions that call the methods above directly.
+
+
+Migration
+=========
+
+As in the methods directly, plain HTML based on Twitter bootstrap can be used.
+Example: `<span class="label label-danger">3</span>`.
+
+
+.. index:: PHP-API, Backend

Documentation/Changelog/7.1/Deprecation-64361-ComposerClassLoading.rst

@@ -0,0 +1,56 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-64361:
+
+============================================
+Deprecation: #64361 - Composer Class Loading
+============================================
+
+See :issue:`64361`
+
+Description
+===========
+
+TYPO3 CMS started integrating composer support and by that embracing PHP standards PSR-0 and PSR-4 for class
+loading that comes with composer.
+The old class loader is still present and registered and will handle loading extension classes
+that do not follow the above mentioned standards.
+
+For the time being a pre-compiled composer class loader is shipped with the git repository,
+so that people using the TYPO3 sources directly from there can use it without requiring a `composer install`
+step.
+
+It is possible however to do a `composer install` in the TYPO3 sources directory or a top level distribution directory
+to gain full control over class loading of your TYPO3 installation. This step is optional and currently requires
+thorough knowledge of composer and as such currently is only recommended for people familiar with this process.
+
+Further technical details can be found in the `documentation`_.
+
+Impact
+======
+
+Third party libraries added to a TYPO3 installation via composer can immediately be used without
+further manual intervention. The classes cache for most core classes will be gone. Resolving classes
+is slowly shifted from a run time task - executed and monitored in every request - to an installation task
+with composer.
+
+Affected installations
+======================
+
+Some installations could be affected which were previously installed via composer,
+but now not properly updated using composer. And outdated Packages/Libraries/autoload.php file
+present in the system will lead to fatal errors.
+
+
+Migration
+=========
+
+If you previously installed TYPO3 via composer, make sure you perform a `composer update` command to reflect
+the current changes in your Packages folder.
+
+
+.. _`documentation`: https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/Autoloading/Background.html
+
+
+.. index:: PHP-API

Documentation/Changelog/7.1/Deprecation-64388-ContentObjectMethods.rst

@@ -0,0 +1,74 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-64388:
+
+===============================================================================
+Deprecation: #64388 - Direct ContentObject methods within ContentObjectRenderer
+===============================================================================
+
+See :issue:`64388`
+
+Description
+===========
+
+The following wrapper methods for ContentObject rendering within ContentObjectRenderer
+have been marked for removal for TYPO3 CMS 8.
+
+.. code-block:: php
+
+	FLOWPLAYER()
+	TEXT()
+	CLEARGIF()
+	COBJ_ARRAY()
+	USER()
+	FILE()
+	FILES()
+	IMAGE()
+	IMG_RESOURCE()
+	IMGTEXT()
+	CONTENT()
+	RECORDS()
+	HMENU()
+	CTABLE()
+	OTABLE()
+	COLUMNS()
+	HRULER()
+	CASEFUNC()
+	LOAD_REGISTER()
+	FORM()
+	SEARCHRESULT()
+	TEMPLATE()
+	FLUIDTEMPLATE()
+	MULTIMEDIA()
+	MEDIA()
+	SWFOBJECT()
+	QTOBJECT()
+	SVG()
+
+
+Impact
+======
+
+Using the methods above directly in any third party extension will trigger a deprecation log message.
+
+
+Affected installations
+======================
+
+Instances which use custom calls to ContentObjects via the methods above.
+
+
+Migration
+=========
+
+Replace the direct method calls to `$contentObject->COBJECT()` with the common method.
+
+Example for the SVG() ContentObject call:
+
+.. code-block:: php
+
+	$cObj->cObjGetSingle('SVG', $conf);
+
+
+.. index:: PHP-API, Frontend

Documentation/Changelog/7.1/Deprecation-64711-UnusedCssStyledContentMethods.rst

@@ -0,0 +1,36 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-64711:
+
+==========================================================================
+Deprecation: #64711 - Various methods within CSS Styled Content Controller
+==========================================================================
+
+See :issue:`64711`
+
+Description
+===========
+
+The following methods within the main CSS Styled Content Controller responsible for rendering
+custom HTML due to lack of TypoScript logic in the past have been marked for removal for TYPO3 CMS 8.
+They are not part of the default CSS Styled Content TypoScript code since TYPO3 CMS 6.
+
+.. code-block:: php
+
+	CssStyledContentController->render_bullets()
+	CssStyledContentController->render_uploads()
+	CssStyledContentController->beautifyFileLink()
+
+Impact
+======
+
+Using the methods in custom TypoScript code or CSS Styled Content methods will throw a deprecation message.
+
+Migration
+=========
+
+Use default TypoScript from CSS Styled Content derived from the current version.
+
+
+.. index:: PHP-API, ext:css_styled_content

Documentation/Changelog/7.1/Deprecation-64922-DeprecatedEntryPoints.rst

@@ -0,0 +1,49 @@
+
+.. include:: /Includes.rst.txt
+
+.. _deprecation-64922:
+
+=============================================
+Deprecation: #64922 - Deprecated entry points
+=============================================
+
+See :issue:`64922`
+
+Description
+===========
+
+The following entry points have been marked as deprecated:
+
+* typo3/tce_file.php
+* typo3/move_el.php
+* typo3/tce_db.php
+* typo3/login_frameset.php
+* typo3/sysext/cms/layout/db_new_content_el.php
+* typo3/sysext/cms/layout/db_layout.php
+
+
+Impact
+======
+
+Using one of the entry points in a backend module will throw a deprecation message.
+
+
+Migration
+=========
+
+Use `\TYPO3\CMS\Backend\Utility\BackendUtility::getModuleUrl()` instead with the according module name.
+
+typo3/tce_file.php
+`\TYPO3\CMS\Backend\Utility\BackendUtility::getModuleUrl('tce_file')`
+
+typo3/move_el.php
+`\TYPO3\CMS\Backend\Utility\BackendUtility::getModuleUrl('move_element')`
+
+typo3/tce_db.php
+`\TYPO3\CMS\Backend\Utility\BackendUtility::getModuleUrl('tce_db')`
+
+typo3/login_frameset.php
+`\TYPO3\CMS\Backend\Utility\BackendUtility::getModuleUrl('login_frameset')`
+
+
+.. index:: PHP-API, Backend

Documentation/Changelog/7.1/Feature-15619-LeaveUnchagedInAccessModule.rst

@@ -0,0 +1,19 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-15619:
+
+==============================================================
+Feature: #15619 - Access module: Allow selector as "unchanged"
+==============================================================
+
+See :issue:`15619`
+
+Description
+===========
+
+In order to only overwrite permissions in the access module and not the owner/group it is now possible
+to set the selector to " - leave unchanged - ".
+
+
+.. index:: Backend

Documentation/Changelog/7.1/Feature-16794-MakeSectionLinkingForIndexedSearchResultsConfigurable.rst

@@ -0,0 +1,27 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-16794:
+
+===========================================================
+Feature: #16794 - Linking of Indexed Search result sections
+===========================================================
+
+See :issue:`16794`
+
+Description
+===========
+
+Per default the section headlines of indexed search results are links.
+It is possible to disable those links, thus having the sections
+displayed as simple text.
+
+.. code-block:: typoscript
+
+	plugin.tx_indexedsearch.linkSectionTitles = 0
+
+Will result in not linked section headlines.
+The setting is per default set to 1 in order to preserve current behaviour.
+
+
+.. index:: TypoScript, Frontend, ext:indexed_search

Documentation/Changelog/7.1/Feature-20767-getDataByNestedKey.rst

@@ -0,0 +1,34 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-20767:
+
+===============================================================
+Feature: #20767 - Allow nested array access on getData of field
+===============================================================
+
+See :issue:`20767`
+
+Description
+===========
+
+Right now the `getData` type in TS only allows to access nested arrays in types GPVar and TSFE.
+Now the same is allowed for `field` too.
+
+If the field value is :code:`array('somekey' => array('level1' => array('level2' => 'somevalue')));`, you can get the
+`somevalue` by configuring the following TypoScript.
+
+.. code-block:: typoscript
+
+	10 = TEXT
+	10.data = field:fieldname|level1|level2
+
+
+Impact
+======
+
+You can now access nested keys via getData `field:`. Nested keys are not available with the default set of
+content objects, however just content objects and `USER` object may return such a field structure.
+
+
+.. index:: TypoScript, Frontend

Documentation/Changelog/7.1/Feature-22086-StdWrapForHeadTag.rst

@@ -0,0 +1,30 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-22086:
+
+=====================================================
+Feature: #22086 - Add .stdWrap to page.headTag option
+=====================================================
+
+See :issue:`22086`
+
+Description
+===========
+
+The TypoScript setting page.headTag now has stdWrap functionality available.
+
+The new option can be set like this:
+
+.. code-block:: typoscript
+
+	page = PAGE
+	page.headTag = <head>
+	page.headTag.override = <head class="special">
+	page.headTag.override.if {
+	  isInList.field = uid
+	  value = 24
+	}
+
+
+.. index:: TypoScript, Frontend

Documentation/Changelog/7.1/Feature-24906-MaxForTextElement.rst

@@ -0,0 +1,38 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-24906:
+
+================================================================
+Feature: #24906 - Configuration for maximum chars in TextElement
+================================================================
+
+See :issue:`24906`
+
+Description
+===========
+
+TCA type `text` now supports the HTML5 attribute `maxlength` to restrict
+text to a given maximum length. Line breaks are usually counted as two
+characters.
+
+Not every browser supports this, see sites like
+`w3schools.com <http://www.w3schools.com/tags/att_textarea_maxlength.asp>`_
+for details.
+
+The new option can be used like this:
+
+.. code-block:: php
+
+	'teaser' => array(
+		'label' => 'Teaser',
+		'config' => array(
+			'type' => 'text',
+			'cols' => 60,
+			'rows' => 2,
+			'max' => '30',
+		)
+	),
+
+
+.. index:: TCA, Backend

Documentation/Changelog/7.1/Feature-28382-AddAsyncPropertyToJavaScriptFiles.rst

@@ -0,0 +1,39 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-28382:
+
+========================================================
+Feature: #28382 - Add async property to JavaScript files
+========================================================
+
+See :issue:`28382`
+
+Description
+===========
+
+Add a property `async="async"` to JavaScript files via TypoScript
+
+`page.includeJSlibs.<array>.async = 1`
+
+This patch affects the TypoScript PAGE properties
+
+* includeJSLibs
+* includeJSFooterlibs
+* includeJS
+* includeJSFooter
+
+Usage:
+------
+
+.. code-block:: typoscript
+
+	page {
+		includeJS {
+			jsFile = /Path/To/jsFile.js
+			jsFile.async = 1
+		}
+	}
+
+
+.. index:: TypoScript, JavaScript, Frontend

Documentation/Changelog/7.1/Feature-33491-StdWrapForTitleTag.rst

@@ -0,0 +1,27 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-33491:
+
+==========================================================
+Feature: #33491 - Add stdWrap functionality to <title> tag
+==========================================================
+
+See :issue:`33491`
+
+Description
+===========
+
+The <title> tag of a frontend page can already be controlled by various settings via TypoScript. However, the stdWrap
+part was not available yet, but is now compliant and available as an option `config.pageTitle`. This option will be
+executed after all other existing processing options like `config.titleTagFunction` and `config.pageTitleFirst`.
+
+The new option can be used like this, e.g. in order to write everything in uppercase in the title tag:
+
+.. code-block:: typoscript
+
+	page = PAGE
+	page.config.pageTitle.case = upper
+
+
+.. index:: TypoScript, Frontend

Documentation/Changelog/7.1/Feature-34944-PaginateHandleNonQueryResultObjects.rst

@@ -0,0 +1,31 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-34944:
+
+=====================================================================
+Feature: #34944 - PaginateViewHelper handles non-query-result objects
+=====================================================================
+
+See :issue:`34944`
+
+Description
+===========
+
+The PaginateViewHelper accepts input collections of following types:
+
+- :code:`QueryResultInterface`
+- :code:`ObjectStorage`
+- :code:`\ArrayAccess`
+- :code:`array`
+
+.. code-block:: html
+
+	<f:widget.paginate objects="{blogs}" as="paginatedBlogs">
+		<f:for each="{paginatedBlogs}" as="blog">
+			<h4>{blog.title}</h4>
+		</f:for>
+	</f:widget.paginate>
+
+
+.. index:: Fluid

Documentation/Changelog/7.1/Feature-35891-AddTCAItemsWithIconsViaPageTSConfig.rst

@@ -0,0 +1,32 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-35891:
+
+=======================================================================
+Feature: #35891 - FormEngine: Possibility to add icons via PageTSconfig
+=======================================================================
+
+See :issue:`35891`
+
+Description
+===========
+
+The possibility to add a new value/label pair for a select field in FormEngine is given via the pageTSconfig option
+"addItems". Now, it is also possible to give the items an icon. Either with the .icon subproperty or with the
+separate option "altIcons".
+
+.. code-block:: typoscript
+
+	TCEFORM.pages.doktype.addItems {
+		13 = My Label
+		13.icon = EXT:t3skin/icons/gfx/i/pages.gif
+	}
+	TCEFORM.pages.doktype.altIcons {
+		123 = EXT:myext/icon.gif
+	}
+
+If the path is not prefixed with "EXT:" it needs to be relative to the typo3/ directory.
+
+
+.. index:: TSConfig, TCA, Backend

Documentation/Changelog/7.1/Feature-46624-AdditionalWhereForMenu.rst

@@ -0,0 +1,26 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-46624:
+
+==========================================================
+Feature: #46624 - HMENU item selection via additionalWhere
+==========================================================
+
+See :issue:`46624`
+
+Description
+===========
+
+The TypoScript Content Object HMENU menu options have a new property called "additionalWhere" to
+allow for a more specific database query based on any page properties.
+
+.. code-block:: typoscript
+
+	lib.authormenu = HMENU
+	lib.authormenu.1 = TMENU
+	lib.authormenu.1.additionalWhere = AND author!=""
+	...
+
+
+.. index:: TypoScript, Frontend

Documentation/Changelog/7.1/Feature-47666-AttributeMulitpleForFormUploadViewhelper.rst

@@ -0,0 +1,28 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-47666:
+
+=====================================================================
+Feature: #47666 - Attribute \"multiple\" for f:form.upload Viewhelper
+=====================================================================
+
+See :issue:`47666`
+
+Description
+===========
+
+The Viewhelper allows now an attribute \"multiple\", that will provide
+a possibility to upload several files at once.
+
+.. code-block:: html
+
+	<f:form.upload property="files" multiple="multiple" />
+
+Will result in the according HTML tag providing the field content as array.
+
+Be aware, that you need to prepare the incoming value for the property mapping yourself,
+by writing your own TypeConverter.
+
+
+.. index:: Fluid

Documentation/Changelog/7.1/Feature-49060-MySqlCommentsShownInSchemaMigrator.rst

@@ -0,0 +1,22 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-49060:
+
+============================================================
+Feature: #49060 - MySql Comments reflected in SchemaMigrator
+============================================================
+
+See :issue:`49060`
+
+Description
+===========
+
+Comments in the :file:`*.sql` files are stored the database table and shown
+by the Schema Migration Feature in Install Tool.
+
+Existing comments are overridden with changes provided by other extensions.
+
+
+
+.. index:: Database, Backend

Documentation/Changelog/7.1/Feature-50780-AppendElementBrowserMountPoints.rst

@@ -0,0 +1,48 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-50780:
+
+=====================================================
+Feature: #50780 - Append element browser mount points
+=====================================================
+
+See :issue:`50780`
+
+Description
+===========
+
+A new UserTSconfig option is introduced:
+
+::
+
+	options.pageTree.altElementBrowserMountPoints.append
+
+This option allows administrators to add additional mount points
+in the RTE and the Wizard element browser instead of replacing
+the configured database mount points of the user when using the
+existing UserTSconfig option:
+
+::
+
+	options.pageTree.altElementBrowserMountPoints
+
+Usage:
+
+Set these options in User TSconfig:
+
+::
+
+	options.pageTree.altElementBrowserMountPoints = 20,31
+	options.pageTree.altElementBrowserMountPoints.append = 1
+
+
+Impact
+======
+
+Mount point overriding is centralized in the BackendUser object and
+used by element browsers of rtehtmlarea and recordlist for calculating
+the page tree mount points that are displayed to the user.
+
+
+.. index:: TSConfig, Backend

Documentation/Changelog/7.1/Feature-52131-HookForPageRepositoryInit.rst

@@ -0,0 +1,27 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-52131:
+
+========================================================
+Feature: #52131 - Hook for end of PageRepository->init()
+========================================================
+
+See :issue:`52131`
+
+Description
+===========
+
+A new hook at the very end of the `PageRepository->init()` has been introduced.
+This function allows manipulation of where clause in order to modify select queries that involve visibility of pages.
+
+Register the hook as follows:
+
+.. code-block:: php
+
+	$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS'][\TYPO3\CMS\Frontend\Page\PageRepository::class]['init']
+
+The hook class must implement the interface :code:`\TYPO3\CMS\Frontend\Page\PageRepositoryInitHookInterface`.
+
+
+.. index:: PHP-API, Frontend

Documentation/Changelog/7.1/Feature-56236-Multiple-HTTP-Headers-In-Frontend.rst

@@ -0,0 +1,47 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-56236:
+
+===========================================================================
+Feature: #56236 - Multiple HTTP headers of the same type in Frontend Output
+===========================================================================
+
+See :issue:`56236`
+
+Description
+===========
+
+It is now possible to use `config.additionalHeaders` as a TypoScript array object to add multiple headers
+at the same time
+
+Usage:
+
+.. code-block:: typoscript
+
+	config.additionalHeaders {
+		10 {
+			# the header string
+			header = WWW-Authenticate: Negotiate
+
+			# replace previous headers with the same name
+            # optional, default is "on"
+			replace = 0
+
+			# optional, force the HTTP response code
+			httpResponseCode = 401
+		}
+		# always set cache headers to private, overwriting the sophisticated TYPO3 option
+		20.header = Cache-control: Private
+	}
+
+See also: https://php.net/header
+
+Impact
+======
+
+The previous option `config.additionalHeaders = X-Header: ABC|X-Header2: DEF` is deprecated in favor of the more
+flexible solution.
+
+
+.. index:: TypoScript, Frontend

Documentation/Changelog/7.1/Feature-56529-SupportHasInArrayObject.rst

@@ -0,0 +1,20 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-56529:
+
+====================================================================
+Feature: #56529 - Support \"has*\" Functions in extbase ObjectAccess
+====================================================================
+
+See :issue:`56529`
+
+Description
+===========
+
+ObjectAccess supports \"is*\" and \"get*\" functions to return
+property values. Another convenience method is \"has*\", which
+can be used in the same way.
+
+
+.. index:: PHP-API, ext:extbase

Documentation/Changelog/7.1/Feature-57178-SpecialHmenuExcludeSpecialParameters.rst

@@ -0,0 +1,30 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-46624-1668719172:
+
+===============================================
+Feature: #46624 - Additional HMENU browse menus
+===============================================
+
+See :issue:`46624`
+
+Description
+===========
+
+The TypoScript Content Object HMENU with a `special=browse` option does not exclude "not in menu" pages nor
+pages that have a "no search" checkbox set. The two new options allow for more fine-grained selection of the items
+within the menu.
+
+The existing option "includeNotInMenu" was not available yet for the `HMENU` with `special=browse` enabled.
+
+.. code-block:: typoscript
+
+	lib.browsemenu = HMENU
+	lib.browsemenu.special = browse
+	lib.browsemenu.special.excludeNoSearchPages = 1
+	lib.browsemenu.includeNotInMenu = 1
+	...
+
+
+.. index:: TypoScript, Frontend

Documentation/Changelog/7.1/Feature-58031-ConfigurableWidthOfElementBrowser.rst

@@ -0,0 +1,29 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-50039-1668719172:
+
+===========================================================
+Feature: #50039 - Configurable width of the Element Browser
+===========================================================
+
+See :issue:`50039`
+
+Description
+===========
+
+It is now possible to set the width and height of the element browser on a per-user basis via UserTSConfig.
+
+Usage:
+
+::
+	options.popupWindowSize = 400x900
+	options.RTE.popupWindowSize = 200x200
+
+Impact
+======
+
+The Element Browser width and height can be set for better usability and user experience.
+
+
+.. index:: TSConfig, Backend

Documentation/Changelog/7.1/Feature-58033-AltLabelsForFormEngineCheckboxAndRadioButtons.rst

@@ -0,0 +1,44 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-58033:
+
+=================================================================================
+Feature: #58033 - Enable label override of checkbox and radio buttons by TSconfig
+=================================================================================
+
+See :issue:`58033`
+
+Description
+-----------
+
+Use TSconfig to override labels of radio buttons and checkboxes used in FormEngine.
+
+For single checkboxes the key `default` is used:
+
+.. code-block:: typoscript
+
+	TCEFORM.pages.hidden.altLabels.default = individual label
+
+.. code-block:: typoscript
+
+	TCEFORM.pages.hidden.altLabels.default = LLL:path/to/languagefile.xlf:individualLabel
+
+For fields with multiple checkboxes, the value or the corresponding numeration (0,1,2,3) of the checkbox is used:
+
+.. code-block:: typoscript
+
+	TCEFORM.pages.l18n_cfg.altLabels.0 = individual label for the first checkbox
+	TCEFORM.pages.l18n_cfg.altLabels.1 = individual label for the second checkbox
+
+The same functionality works on radio buttons, where the "key" is the value of the radio button.
+
+As seen in the example, hard-coded strings or references to language files are allowed.
+
+Impact
+------
+
+The feature enables even more customization for FormEngine for any custom crafted backend instance.
+
+
+.. index:: TSConfig, Backend

Documentation/Changelog/7.1/Feature-58366-AutomaticAbsRefPrefix.rst

@@ -0,0 +1,49 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-58366:
+
+===========================================================
+Feature: #58366 - Add "auto" Option for config.absRefPrefix
+===========================================================
+
+See :issue:`58366`
+
+Description
+===========
+
+The TypoScript setting `config.absRefPrefix` can be used to allow URL rewriting like giving a hard
+prefix for all relative paths. As an alternative to `config.baseURL` to be set to a specific domain
+absRefPrefix can autodetect the site root and use that instead of manually setting this option.
+
+Frontend:
+
+The new option can be set like this:
+
+.. code-block:: typoscript
+
+	config.absRefPrefix = auto
+
+instead of hardcoded values for different environments or when moving installations in subfolders.
+
+.. code-block:: typoscript
+
+	[ApplicationContext = Production]
+	config.absRefPrefix = /
+
+	[ApplicationContext = Testing]
+	config.absRefPrefix = /my_site_root/
+
+As the feature only works with path prefixes, and not with host name variables from the server,
+the new option is also safe for multi-domain environments to avoid duplicate caching mechanism.
+
+
+Impact
+======
+
+The new special option can be used to automatically set up installations and distributions like
+the Introduction Package where a site configuration is shipped with the system but might need
+to be adjusted.
+
+
+.. index:: TypoScript, Frontend

Documentation/Changelog/7.1/Feature-58929-FooterHookInPageLayoutView.rst

@@ -0,0 +1,18 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-58929:
+
+====================================================================
+Feature: #58929 - PageLayoutView: Add hook for tt_content_drawFooter
+====================================================================
+
+See :issue:`58929`
+
+Description
+===========
+
+A hook has been added to the PageLayoutView to manipulate the rendering of the footer of a content element.
+
+
+.. index:: PHP-API, Backend

Documentation/Changelog/7.1/Feature-60019-SplFileInfo-MimeTypeGuesser-hook.rst

@@ -0,0 +1,41 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-60019:
+
+===============================================================================
+Feature: #60019 - New SplFileInfo implementation with new mimeTypeGuessers hook
+===============================================================================
+
+See :issue:`60019`
+
+Description
+===========
+
+A new class `\TYPO3\CMS\Core\Type\File\FileInfo` which extends `SplFileInfo` is now
+available as an API for fetching meta information from files.
+
+Besides the native .. _SplFileInfo API: https://php.net/manual/en/class.splfileinfo.php,
+it provides a new method `getMimeType()` to get the mime type of a file, e.g. text/html.
+It uses the native PHP function `finfo_file()` and `mime_content_type()` as a fallback.
+
+Example: Get the MIME type of a file
+
+.. code-block:: php
+
+  $fileIdentifier = '/tmp/foo.html';
+  $fileInfo = GeneralUtility::makeInstance(\TYPO3\CMS\Core\Type\File\FileInfo::class, $fileIdentifier);
+  echo $fileInfo->getMimeType();
+  // text/html
+
+New Hook 'mimeTypeGuessers'
+===========================
+
+Custom implementations to determine the MIME type can be added with a hook. Register the hook as follows:
+
+.. code-block:: php
+
+  $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS'][\TYPO3\CMS\Core\Type\File\FileInfo::class]['mimeTypeGuessers']
+
+
+.. index:: PHP-API, FAL

Documentation/Changelog/7.1/Feature-61542-AddIsoLanguageKeys.rst

@@ -0,0 +1,78 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-61542:
+
+===============================================================
+Feature: #61542 - Add two-letter ISO 639-1 keys to sys_language
+===============================================================
+
+See :issue:`61542`
+
+Description
+===========
+
+The handling of the languages is done by the sys_language database table, which is usually referenced via the common
+sys_language_uid. The commonly referenced ISO 639-1 two-letter-code is only in use when static_info_tables is installed,
+which brings all ISO 639-1 letter-codes in a separate table. The CMS Core uses a hard-coded dependency on the extension
+to retrieve the ISO codes where needed, however, already ships an empty and invisible field "static_lang_isocode" which is
+already supplied by the CMS Core.
+
+As a first step to identify languages by their proper ISO 639-1 two-letter code a new DB field for sys_language called
+"language_isocode" is introduced, which is used in all places of the TYPO3 CMS Core.
+
+Additionally the new TypoScript option `config.sys_language_isocode` can be used to set the existing
+`$TSFE->sys_language_isocode` variable via TypoScript. Previously this was done via static_info_tables.
+
+The ISO code is also used for the language attribute of the HTML tag. Therefore the setting `config.htmlTag_langKey`
+is not needed anymore if it is the same as the ISO code.
+
+Impact
+======
+
+Frontend:
+The value `$TSFE->sys_language_isocode` is now filled at any time. It can be set via TypoScript, or is automatically
+set if the `config.sys_language_uid` parameter is set > 0 from the language_isocode DB field.
+
+.. code-block:: typoscript
+
+	# danish by default
+	config.sys_language_uid = 0
+	config.sys_language_isocode_default = da
+
+	[globalVar = GP:L = 1]
+		# isocode is filled by the respective DB value from sys_language (uid 1)
+		config.sys_language_uid = 1
+
+		# you can override this of course
+		config.sys_language_isocode = fr
+	[GLOBAL]
+
+The new field can be used in any TypoScript variable like
+
+.. code-block:: typoscript
+
+	page.10 = TEXT
+	page.10.data = TSFE:sys_language_isocode
+	page.10.wrap = <div class="main" data-language="|">
+
+Backend:
+
+All ISO code usages based on sys_language in the Backend (FormEngine, Translation Tools) is now done via the new field
+but still uses static_info_tables as fallback if already in use.
+
+Each sys_language record is now editable with the new DB field to select the respective ISO 639-1 code.
+
+Migration
+=========
+
+The upgrade wizard makes sure that the new DB field is filled properly so no deprecation warnings are written
+if static_info_tables in conjunction with the DB field "static_lang_isocode" was used before. If this field is
+used in a 3rd party extension, the extension developers and site integrators need to make sure it is switched
+to the new DB field sys_language.language_isocode.
+
+If a site uses multiple languages without static_info_tables each sys_language record should be modified to select
+the proper ISO 639-1 code for the languages.
+
+
+.. index:: TypoScript, Frontend

Documentation/Changelog/7.1/Feature-61725-AddHookToBackendUtilityCountVersionsOfRecordsOnPage.rst

@@ -0,0 +1,26 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-61725:
+
+=========================================================================
+Feature: #61725 - Hook for BackendUtility::countVersionsOfRecordsOnPage()
+=========================================================================
+
+See :issue:`61725`
+
+Description
+===========
+
+Hook to post-process `BackendUtility::countVersionsOfRecordsOnPage`
+result. `BackendUtility::countVersionsOfRecordsOnPage` is used to
+visualize workspace states in e.g. the page tree.
+
+Register like this:
+
+.. code-block:: php
+
+	$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_befunc.php']['countVersionsOfRecordsOnPage'][] = 'My\Package\HookClass->hookMethod';
+
+
+.. index:: PHP-API, Backend

Documentation/Changelog/7.1/Feature-62944-UserFuncAsDisplayCond.rst

@@ -0,0 +1,28 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-62944:
+
+=========================================================
+Feature: #62944 - UserFunc available as Display Condition
+=========================================================
+
+See :issue:`62944`
+
+Description
+===========
+
+Being able to use userFunc as `displayCondition` makes it possible to
+check on any imaginable condition or state. If any situation can not
+be evaluated with any of the existing checks the developer is free
+to add an own user function which provides a boolean result whether
+to show or hide the TCA field.
+
+.. code-block:: php
+
+	$GLOBALS['TCA']['tt_content']['columns']['bodytext']['displayCond'] = 'USER:Evoweb\\Example\\User\\ElementConditionMatcher->checkHeaderGiven:any:more:information';
+
+Any parameters can be added (separated by colons) that are sent to the ConditionMatcher class.
+
+
+.. index:: PHP-API, TCA, Backend

Documentation/Changelog/7.1/Feature-62960-SignalForMailerInitialization.rst

@@ -0,0 +1,59 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-62960:
+
+==================================================
+Feature: #62960 - Signal for mailer initialization
+==================================================
+
+See :issue:`62960`
+
+Description
+===========
+
+This signal allows for additional processing upon initialization of a mailer object,
+e.g. registering a Swift mailer plugin.
+
+Registering the signal:
+
+::
+
+	$signalSlotDispatcher = \\TYPO3\\CMS\\Core\\Utility\\GeneralUtility::makeInstance(\\TYPO3\\CMS\\Extbase\\SignalSlot\\Dispatcher::class);
+	$signalSlotDispatcher->connect(
+		\\TYPO3\\CMS\\Core\\Mail\\Mailer::class,
+		'postInitializeMailer',
+		\\Vendor\\Package\\Slots\\MailerSlot::class,
+		'registerPlugin'
+	);
+
+..
+
+The slot class:
+
+::
+
+	<?php
+	namespace Vendor\\Package\\Slots;
+
+	use TYPO3\\CMS\\Core\\Mail\\Mailer;
+
+	class MailerSlot {
+		/**
+		 * @param Mailer $mailer
+		 * @return void
+		 */
+		public function registerPlugin(Mailer $mailer) {
+			// Processing here
+		}
+	}
+
+..
+
+Impact
+======
+
+Extensions may now perform arbitrary processing for every mail.
+
+
+.. index:: PHP-API

Documentation/Changelog/7.1/Feature-63207-SplitActionButtonsIntoGroups.rst

@@ -0,0 +1,47 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-63207:
+
+===============================================
+Feature: #63207 - Split buttons into two groups
+===============================================
+
+See :issue:`63207`
+
+Description
+===========
+
+The action buttons in Web>List for pages and content elements have been split into two groups to organize
+the actions as primary and secondary actions. Primary actions are common RUD actions:
+
+- Show
+- Edit
+- Hide
+- Delete
+- Move up/down
+
+Secondary actions keep any other action. If "Extended view" is disabled, the primary actions are now
+still displayed, the secondary action are collapsed but can be expanded by clicking the expand trigger.
+
+
+Impact
+======
+
+Existing hooks will work like before. If an action is added to one of the two sections, the icon
+on rootlevel must be reset, please see Migration_.
+
+
+Migration
+=========
+
+.. code-block:: php
+
+	unset($cells['edit']);
+	$cells['primary']['edit'] = '<a class="btn btn-default"><span class="t3-icon fa fa-trash"></span></a>';
+	$cells['secondary']['edit'] = '<a class="btn btn-default"><span class="t3-icon fa fa-trash"></span></a>';`
+
+Icons, that are not added into a section, will be sorted into the secondary group.
+
+
+.. index:: PHP-API, Backend

Documentation/Changelog/7.1/Feature-63600-CustomTypoScriptConditionsInBackend.rst

@@ -0,0 +1,43 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-61489-1668719172:
+
+====================================================================
+Feature: #61489 - Allow own TypoScript Conditions in Backend as well
+====================================================================
+
+See :issue:`61489`
+
+Description
+===========
+
+It is now possible to add own TypoScript conditions via a separate API in the Backend. The API for the frontend
+was introduced with TYPO3 CMS 7.0.
+
+An extension/package can now ship an implementation of a new abstract class AbstractCondition. Via the existing
+TypoScript Condition Syntax the class is called by the simple fully namespaced class name.
+The class' main function "matchCondition" can flexibly evaluate any parameters given after the class name.
+
+Usage:
+
+.. code-block:: typoscript
+
+	[BigCompanyName\TypoScriptLovePackage\MyCustomTypoScriptCondition]
+
+	[BigCompanyName\TypoScriptLovePackage\MyCustomTypoScriptCondition = 7]
+
+	[BigCompanyName\TypoScriptLovePackage\MyCustomTypoScriptCondition = 7, != 6]
+
+	[BigCompanyName\TypoScriptLovePackage\MyCustomTypoScriptCondition = {$mysite.myconstant}]
+
+where the TypoScript Condition class deals with =/!= etc itself.
+
+Impact
+======
+
+If you've previously used the `userFunc` condition, you are encouraged to use this new API for your own TypoScript
+conditions.
+
+
+.. index:: TypoScript, Frontend, PHP-API

Documentation/Changelog/7.1/Feature-63729-ApiForBootstrapModals.rst

@@ -0,0 +1,121 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-63729:
+
+==================================================
+Feature: #63729 - API for Twitter Bootstrap modals
+==================================================
+
+See :issue:`63729`
+
+Description
+===========
+
+Actions that require a users' attention must be visualized by modal windows. TWBS provides those,
+but extension authors or core developers must take care of its creation and handling themselves.
+
+This API provides a basis to create modal windows with severity representation. For a better UX,
+if actions (buttons) are attached to the modal, one button must be a positive action. This button
+should get a btnClass and set as active.
+
+Modals should be used rarely and only for confirmations. For information the TYPO3.Flashmessage API should be used.
+For complex content, like forms or a lot of information, please use normal pages.
+
+
+Impact
+======
+
+API
+---
+
+The API provides only two public methods:
+
+#. :code:`TYPO3.Modal.confirm(title, content, severity, buttons)`
+#. :code:`TYPO3.Modal.dismiss()`
+
+Modal Settings
+~~~~~~~~~~~~~~
+
+========= =============== ============ ======================================================================================================
+Name      DataType        Mandatory    Description
+========= =============== ============ ======================================================================================================
+title     string          Yes          The title displayed in the modal
+content   string|jQuery   Yes          The content displayed in the modal
+severity  int                          Represents the severity of a modal. Please see TYPO3.Severity. Default is :code:`TYPO3.Severity.info`.
+buttons   object[]                     Actions rendered into the modal footer. If empty, the footer is not rendered. See table below.
+========= =============== ============ ======================================================================================================
+
+Button Settings
+~~~~~~~~~~~~~~~
+
+========= =============== ============ ===============================================================
+Name      DataType        Mandatory    Description
+========= =============== ============ ===============================================================
+text      string          Yes          The text rendered into the button.
+trigger   function        Yes          Callback that's triggered on button click.
+active    bool                         Marks the button as active. If true, the button gets the focus.
+btnClass  string                       The css class for the button
+========= =============== ============ ===============================================================
+
+Data-Attributes
+~~~~~~~~~~~~~~~
+
+It is also possible to use data-attributes to trigger a modal.
+e.g. on an anchor element, which prevents the default behavior.
+
+========================= ==================================================================
+Name                      Description
+========================= ==================================================================
+data-title                the title text for the modal
+data-content              the content text for the modal
+data-severity             the severity for the modal, default is info (see TYPO3.Severity.*)
+data-href                 the target URL, default is the href attribute of the element
+data-button-close-text    button text for the close/cancel button
+data-button-ok-text       button text for the ok button
+========================= ==================================================================
+
+:code:`class="t3js-modal-trigger"` marks the element as modal trigger
+
+Examples
+--------
+
+A basic modal without any specials can be created this way:
+
+.. code-block:: javascript
+
+	TYPO3.Modal.confirm('The title of the modal', 'This the body of the modal');
+
+A modal as warning with button:
+
+.. code-block:: javascript
+
+	TYPO3.Modal.confirm('Warning', 'You may break the internet!', TYPO3.Severity.warning, [
+		{
+			text: 'Break it',
+			active: true,
+			trigger: function() {
+				// break the net
+			}
+		}, {
+			text: 'Abort!',
+			trigger: function() {
+				TYPO3.Modal.dismiss();
+			}
+		}
+	]);
+
+A modal as warning:
+
+.. code-block:: javascript
+
+	TYPO3.Modal.confirm('Warning', 'You may break the internet!', TYPO3.Severity.warning);
+
+A modal triggered on an anchor element:
+
+.. code-block:: html
+
+	<a href="delete.php" class="t3js-modal-trigger" data-title="Delete" data-content="Really delete?">delete</a>
+
+
+.. index:: PHP-API, JavaScript, Backend

Documentation/Changelog/7.1/Feature-63913-AllowRequireJsModulesForContainerViewHelper.rst

@@ -0,0 +1,29 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-63913:
+
+=====================================================================
+Feature: #63913 - Allow ContainerViewHelper to load RequireJS modules
+=====================================================================
+
+See :issue:`63913`
+
+Description
+===========
+
+The ContainerViewHelper can load RequireJS modules via the `includeRequireJsModules` attribute. The scripts are passed
+as array.
+
+.. code-block:: html
+
+	<f:be.container pageTitle="Extension Module" loadJQuery="true"
+		includeRequireJsModules="{
+		0:'TYPO3/CMS/Extension/Module',
+		1:'TYPO3/CMS/Extension/Module2',
+		2:'TYPO3/CMS/Extension/Module3',
+		3:'TYPO3/CMS/Extension/Module4'
+	}">
+
+
+.. index:: Fluid, JavaScript, Backend

Documentation/Changelog/7.1/Feature-64031-JavaScript-Storage-API.rst

@@ -0,0 +1,57 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-64031:
+
+========================================
+Feature: #64031 - JavaScript Storage API
+========================================
+
+See :issue:`64031`
+
+Description
+===========
+
+Accessing the Backend User configuration ($BE_USER->uc) can be handled in JavaScript with a common and simple
+key-value storage manner, allowing to store any data. Additionally, the use of HTML5s localStorage allows to
+store any data in the same way inside the browser. All localStorage data is prefixed with "t3-" in order to avoid
+collisions with other data from the same browserStorage.
+
+Impact
+======
+
+API Methods
+-----------
+
+The API provides two objects available in the top frame attached to the global TYPO3 object:
+
+1) `top.TYPO3.Storage.Client`
+2) `top.TYPO3.Storage.Persistent`
+
+Each object has the following API methods
+
+* `get(key)` To fetch the data behind the key.
+* `set(key, value)` To set/override a key with any arbitrary content.
+* `isset(key)` (bool) checks if the key is in use.
+* `clear()` to empty all data inside the storage.
+
+
+Examples
+--------
+
+To fetch data from the persistent user configuration, simple use the key known already:
+
+.. code-block:: javascript
+
+	top.TYPO3.Storage.Persistent.get('startModule');
+
+Storing / Updating data in the storage works like this, and can contain any data type.
+
+.. code-block:: javascript
+
+	top.TYPO3.Storage.Persistent.set('startModule', 'web_info');
+
+The same is possible for browserStorage using top.TYPO3.Storage.Client.
+
+
+.. index:: JavaScript, Backend

Documentation/Changelog/7.1/Feature-64190-FormEngineCheckboxElement.rst

@@ -0,0 +1,47 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-64190:
+
+==================================================================
+Feature: #64190 - Inline rendering for FormEngine Checkbox Element
+==================================================================
+
+See :issue:`64190`
+
+Description
+===========
+
+The checkbox setting `inline` for cols can be used to render the checkboxes
+directly next to each other to reduce the amount of used space.
+
+Example Configuration:
+
+::
+
+	'weekdays' => array(
+		'label' => 'Weekdays',
+		'config' => array(
+			'type' => 'check',
+			'items' => array(
+				array('Mo', ''),
+				array('Tu', ''),
+				array('We', ''),
+				array('Th', ''),
+				array('Fr', ''),
+				array('Sa', ''),
+				array('Su', ''),
+			),
+			'cols' => 'inline',
+		),
+	),
+
+..
+
+Impact
+======
+
+Checkboxes will be placed directly next to each other to reduce the amount of used space.
+
+
+.. index:: TCA, Backend

Documentation/Changelog/7.1/Feature-64257-MultipleUidInPageRepositoryGetMenu.rst

@@ -0,0 +1,28 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-64257:
+
+===================================================================
+Feature: #64257 - Support multiple UID in PageRepository::getMenu()
+===================================================================
+
+See :issue:`64257`
+
+Description
+===========
+
+An array of `uid` values can be passed to
+`PageRepository::getMenu()`, providing the chance to build menus
+from several roots.
+
+Example: Fetch children of pages #2 and #3:
+
+.. code-block:: php
+
+    $pageRepository = new \TYPO3\CMS\Frontend\Page\PageRepository();
+    $pageRepository->init(false);
+    $rows = $pageRepository->getMenu(array(2, 3));
+
+
+.. index:: PHP-API, Frontend

Documentation/Changelog/7.1/Feature-64386-ContentObjectRegistration.rst

@@ -0,0 +1,32 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-64386:
+
+====================================================
+Feature: #64386 - Public Content Object Registration
+====================================================
+
+See :issue:`64386`
+
+Description
+===========
+
+A new global option is now available to register and/or extend/overwrite content objects like TEXT.
+A list of all available Content Objects that was previously registered within the main ContentObjectRenderer class
+is now moved to the global array `$GLOBALS['TYPO3_CONF_VARS']['FE']['ContentObjects']` which allows for modifications
+via third-party extensions.
+
+Example: Register a new Content Object EXAMPLE in a third-party extension
+
+.. code-block:: php
+
+  $GLOBALS['TYPO3_CONF_VARS']['FE']['ContentObjects']['EXAMPLE'] = Acme\MyExtension\ContentObject\ExampleContentObject::class
+
+The registered class must be a subclass of `TYPO3\CMS\Frontend\ContentObject\AbstractContentObject`.
+
+For future autoloading mechanisms, it is encouraged to place the custom ContentObject class inside
+`EXT:myextension/Classes/ContentObject/`.
+
+
+.. index:: PHP-API, Frontend

Documentation/Changelog/7.1/Feature-64921-FlexibleSubmoduleConfiguration.rst

@@ -0,0 +1,43 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-64921:
+
+=========================================================================
+Feature: #64921 - Needed changes for flexible configuration of submodules
+=========================================================================
+
+See :issue:`64921`
+
+Description
+===========
+
+The additional configuration for submodules can now be configured with an extra
+parameter in `ExtensionManagementUtility::addModule()` since https://forge.typo3.org/issues/62880.
+This makes it possible to remove the conf.php file by setting the configuration within `ExtensionManagementUtility::addModule()` in ext_tables.php.
+
+When doing so you might have some issues with $this->MCONF not being set. This happens if your backend module extends
+from `\TYPO3\CMS\Backend\Module\BaseScriptClass`.
+
+To fix this problem you need to add the module name in $this->MCONF.
+
+.. code-block:: php
+
+	/**
+	 * The name of the module
+	 *
+	 * @var string
+	 */
+	protected $moduleName = 'file_list';
+
+	/**
+	 * Constructor
+	 */
+	public function __construct() {
+		$this->MCONF = array(
+			'name' => $this->moduleName
+		);
+	}
+
+
+.. index:: PHP-API, Backend

Documentation/Changelog/7.1/Feature-65960-IntroduceGruntJS.rst

@@ -0,0 +1,52 @@
+
+.. include:: /Includes.rst.txt
+
+.. _feature-63729-1668719172:
+
+===================================
+Feature: #63729 - Introduce GruntJS
+===================================
+
+See :issue:`63729`
+
+Description
+===========
+
+In order to unify build processes in the backend we introduce
+`GruntJS <http://gruntjs.com/>`_ as a central taskrunner. It will
+provide a global config that takes over the responsibility
+for all build processes in the future starting with the less
+files of the backend skin.
+
+The build files are located in the *Build* folder located in the root directory.
+
+For detailed information about setting up GruntJS please head to http://gruntjs.com/.
+
+
+Initial setup
+~~~~~~~~~~~~~
+
+.. code-block:: bash
+
+	npm install
+	npm install -g grunt-cli
+
+
+Registered Tasks
+~~~~~~~~~~~~~~~~
+
+Compiling Less files:
+
+.. code-block:: bash
+
+	grunt less
+
+
+Watching Less files:
+
+.. code-block:: bash
+
+	grunt watch
+
+
+.. index:: JavaScript

Documentation/Changelog/7.1/Index.rst

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