[DOCS] 8.0 Part 4/5 - Feature Docs 22/47322/2
authorMathias Schreiber <mathias.schreiber@wmdb.de>
Fri, 18 Mar 2016 14:23:00 +0000 (15:23 +0100)
committerBenni Mack <benni@typo3.org>
Fri, 18 Mar 2016 20:42:19 +0000 (21:42 +0100)
Proofread breaking Docs

Resolves: #
Releases: master
Change-Id: I1c86c278d466d47e4bc866443f9267f00d2973e3
Reviewed-on: https://review.typo3.org/47322
Reviewed-by: Benni Mack <benni@typo3.org>
Tested-by: Benni Mack <benni@typo3.org>
50 files changed:
typo3/sysext/core/Documentation/Changelog/8.0/Feature-1835-RecoverPagesRecursivelyToTop.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/8.0/Feature-19157-impexpCouldHaveAnOptionToExcludeAllHiddenRecords.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/8.0/Feature-28230-AddSupportForPBKDF2ToSaltedpasswords.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/8.0/Feature-54887-Post-processingOfThePreviewUrl.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/8.0/Feature-67236-AddedAllowedTagsArgumentToFformatstripTagsViewHelper.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/8.0/Feature-69794-SupportPecl-memcachedInMemcachedBackend.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/8.0/Feature-69863-UseNewStandaloneFluidAsComposerDependency.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/8.0/Feature-72337-CharsetConversionAutodetection.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/8.0/Feature-72505-IntroduceHookToOverrideARecordOverlay.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/8.0/Feature-72904-AddPreProcessStorageSignalToResourceFactory.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/8.0/Feature-73042-IntroduceNativeSupportForSymfonyConsole.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/8.0/Feature-73050-AddACSPRNGAPI.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/8.0/Feature-73429-WizardComponentHasBeenAdded.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/8.0/Feature-73720-TriggerEventAfterModalWindowDismissed.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/8.0/Feature-73752-AllowAccessingObjectStorageAsArrayInFluidAndOtherPlaces.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/8.0/Feature-74038-ReportForCheckingDatabaseCharacterSet.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/8.0/Feature-74109-SetTheAlternativeBackendLogoViaExtensionManager.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/8.0/Feature-74179-PageModuleDragDropCanDoCopiesViaCTRLKeyNow.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/8.0/Feature-74319-CheckDefaultDatabaseCharacterSetDuringInstallationAndProvideUpdateWizardForFixingDefaultCharacterSetOtherThanUtf-8.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/8.0/need_github_docs/Feature-69394-EXTform-DirectlyLoadFormWizardAsInlineWizard.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/8.0/need_github_docs/Feature-70849-MakeSearchLevelsConsistent.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/8.0/need_github_docs/Feature-71331-MakeIndexedSearchExtbasePluginFormTargetPidConfigurable.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/8.0/need_github_docs/Feature-71876-MakeNewContentElementWizardTabSortOrderConfigurable.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/8.0/need_github_docs/Feature-72045-KeepTagsInHtmlParserWhenStrippingEmptyTags.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/8.0/need_github_docs/Feature-72309-EXTform-AllowIntegrationOfPredefinedForms.rst [new file with mode: 0644]
typo3/sysext/core/Documentation/Changelog/master/Feature-1835-RecoverPagesRecursivelyToTop.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-19157-impexpCouldHaveAnOptionToExcludeAllHiddenRecords.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-28230-AddSupportForPBKDF2ToSaltedpasswords.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-54887-Post-processingOfThePreviewUrl.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-67236-AddedAllowedTagsArgumentToFformatstripTagsViewHelper.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-69394-EXTform-DirectlyLoadFormWizardAsInlineWizard.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-69794-SupportPecl-memcachedInMemcachedBackend.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-69863-UseNewStandaloneFluidAsComposerDependency.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-71331-MakeIndexedSearchExtbasePluginFormTargetPidConfigurable.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-71876-MakeNewContentElementWizardTabSortOrderConfigurable.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-72045-KeepTagsInHtmlParserWhenStrippingEmptyTags.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-72309-EXTform-AllowIntegrationOfPredefinedForms.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-72337-CharsetConversionAutodetection.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-72505-IntroduceHookToOverrideARecordOverlay.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-72904-AddPreProcessStorageSignalToResourceFactory.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-73042-IntroduceNativeSupportForSymfonyConsole.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-73050-AddACSPRNGAPI.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-73429-WizardComponentHasBeenAdded.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-73720-TriggerEventAfterModalWindowDismissed.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-73752-AllowAccessingObjectStorageAsArrayInFluidAndOtherPlaces.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-74038-ReportForCheckingDatabaseCharacterSet.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-74109-SetTheAlternativeBackendLogoViaExtensionManager.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-74179-PageModuleDragDropCanDoCopiesViaCTRLKeyNow.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Feature-74319-CheckDefaultDatabaseCharacterSetDuringInstallationAndProvideUpdateWizardForFixingDefaultCharacterSetOtherThanUtf-8.rst [deleted file]
typo3/sysext/core/Documentation/Changelog/master/Important-70849-MakeSearchLevelsConsistent.rst [deleted file]

diff --git a/typo3/sysext/core/Documentation/Changelog/8.0/Feature-1835-RecoverPagesRecursivelyToTop.rst b/typo3/sysext/core/Documentation/Changelog/8.0/Feature-1835-RecoverPagesRecursivelyToTop.rst
new file mode 100644 (file)
index 0000000..172b466
--- /dev/null
@@ -0,0 +1,10 @@
+=============================================================
+Feature: #1835 - Recover pages recursively to top of rootline
+=============================================================
+
+Description
+===========
+
+The Recycler now supports the recursive recovery of deleted pages to the top of the
+rootline. This feature is available for admin users only due to internal
+permission restrictions.
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/8.0/Feature-19157-impexpCouldHaveAnOptionToExcludeAllHiddenRecords.rst b/typo3/sysext/core/Documentation/Changelog/8.0/Feature-19157-impexpCouldHaveAnOptionToExcludeAllHiddenRecords.rst
new file mode 100644 (file)
index 0000000..7cb0916
--- /dev/null
@@ -0,0 +1,14 @@
+========================================================================
+Feature: #19157 - Add option to exclude all hidden records in EXT:impexp
+========================================================================
+
+Description
+===========
+
+The export configuration of EXT:impexp has been extended to allow to
+completely deactivate exporting of hidden/deactivated records. This
+behaviour can be controlled via a new option which is checked by default.
+
+Furthermore, if the inclusion of hidden records is activated (which is
+now an explicit choice), then an additional button is shown, allowing
+users to preselect all hidden records for manual exclusion.
diff --git a/typo3/sysext/core/Documentation/Changelog/8.0/Feature-28230-AddSupportForPBKDF2ToSaltedpasswords.rst b/typo3/sysext/core/Documentation/Changelog/8.0/Feature-28230-AddSupportForPBKDF2ToSaltedpasswords.rst
new file mode 100644 (file)
index 0000000..5ba6078
--- /dev/null
@@ -0,0 +1,16 @@
+===========================================================
+Feature: #28230 - Add support for PBKDF2 to saltedpasswords
+===========================================================
+
+Description
+===========
+
+A new password hashing algorithm ``PBKDF2`` has been added to the system extension ``saltedpasswords``.
+PBKDF2 is designed to be computationally expensive to resist brute force password cracking.
+
+
+Impact
+======
+
+None, the new hashing algorithm needs to be enabled by the system administrator in the extension
+configuration and will upgrade existing passwords transparently on login.
diff --git a/typo3/sysext/core/Documentation/Changelog/8.0/Feature-54887-Post-processingOfThePreviewUrl.rst b/typo3/sysext/core/Documentation/Changelog/8.0/Feature-54887-Post-processingOfThePreviewUrl.rst
new file mode 100644 (file)
index 0000000..941f5e3
--- /dev/null
@@ -0,0 +1,36 @@
+===================================================
+Feature: #54887 - Post-processing of the previewUrl
+===================================================
+
+Description
+===========
+
+An additional hook has been added to the method ``BackendUtility::viewOnClick()`` to
+post-process the preview url.
+
+The hook is called with the following signature:
+
+.. code-block:: php
+
+   /**
+    * @param string $previewUrl
+    * @param int $pageUid
+    * @param string $backPath
+    * @param array $rootLine
+    * @param string $anchorSection
+    * @param string $viewScript
+    * @param string $additionalGetVars
+    * @param bool $switchFocus
+    * @return string The processed preview URL
+    */
+   function postProcess($previewUrl, $pageUid, $backPath, $rootLine, $anchorSection, $viewScript, $additionalGetVars, $switchFocus)
+
+
+Register the hook
+-----------------
+
+Register a hook class which implements the method with the name ``postProcess``:
+
+.. code-block:: php
+
+   $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_befunc.php']['viewOnClickClass'][] = \VENDOR\MyExt\Hooks\BackendUtilityHook::class;
diff --git a/typo3/sysext/core/Documentation/Changelog/8.0/Feature-67236-AddedAllowedTagsArgumentToFformatstripTagsViewHelper.rst b/typo3/sysext/core/Documentation/Changelog/8.0/Feature-67236-AddedAllowedTagsArgumentToFformatstripTagsViewHelper.rst
new file mode 100644 (file)
index 0000000..e6babb4
--- /dev/null
@@ -0,0 +1,17 @@
+===============================================================================
+Feature: #67236 - Added "allowedTags" argument to f:format.stripTags ViewHelper
+===============================================================================
+
+Description
+===========
+
+The argument ``allowedTags`` containing a list of HTML tags which will not be stripped
+can now be used on ``f:format.stripTags``. Tag list syntax is identical to second
+parameter of PHP function ``strip_tags``.
+
+
+Impact
+======
+
+New ViewHelper argument (string) ``allowedTags`` becomes available, allowing passing
+the tag list as second parameter to ``strip_tags``.
diff --git a/typo3/sysext/core/Documentation/Changelog/8.0/Feature-69794-SupportPecl-memcachedInMemcachedBackend.rst b/typo3/sysext/core/Documentation/Changelog/8.0/Feature-69794-SupportPecl-memcachedInMemcachedBackend.rst
new file mode 100644 (file)
index 0000000..4f7c64e
--- /dev/null
@@ -0,0 +1,32 @@
+============================================================
+Feature: #69794 - Support pecl-memcached in MemcachedBackend
+============================================================
+
+Description
+===========
+
+Support for the PECL module "memcached" has been added to the MemcachedBackend of the Caching Framework.
+
+
+Impact
+======
+
+The MemcachedBackend checks if either "memcache" or "memcached" is installed. If both plugins are installed, the
+MemcachedBackend uses "memcache" over "memcached" to avoid being a breaking change. An integrator may set the option
+``peclModule` to use the preferred PECL module.
+
+Example code:
+
+.. code-block:: php
+
+       $GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['my_memcached'] = [
+               'frontend' => \TYPO3\CMS\Core\Cache\Frontend\VariableFrontend::class
+               'backend' => \TYPO3\CMS\Core\Cache\Backend\MemcachedBackend::class,
+               'options' => [
+                       'peclModule' => 'memcached',
+                       'servers' => [
+                          'localhost',
+                          'server2:port'
+                       ]
+               ]
+       ];
diff --git a/typo3/sysext/core/Documentation/Changelog/8.0/Feature-69863-UseNewStandaloneFluidAsComposerDependency.rst b/typo3/sysext/core/Documentation/Changelog/8.0/Feature-69863-UseNewStandaloneFluidAsComposerDependency.rst
new file mode 100644 (file)
index 0000000..e8b35cb
--- /dev/null
@@ -0,0 +1,361 @@
+=================================================================
+Feature: #69863 - Use new standalone Fluid as composer dependency
+=================================================================
+
+Description
+===========
+
+The Fluid rendering engine of TYPO3 CMS is replaced by the standalone capable Fluid which is now included as composer dependency.
+The old Fluid extension is converted to a so-called Fluid adapter which allows TYPO3 CMS to use standalone Fluid with the many
+new features this facilitates.
+
+
+Impact
+======
+
+New features/capabilities have been added in nearly all areas of Fluid. Most importantly: several of the Fluid components which
+in the past were completely internal and impossible to replace, are now easy to replace and have been fitted with a public API.
+Unless noted otherwise each feature below is part of such a new API component which you can replace. This gives you unprecedented
+control over almost all of Fluid's behaviours in a way that can be controlled via each View instance, for example from within a
+controller's initializeView method.
+
+Developers working with just the template side of Fluid will not notice many differences. Those that they will notice are, for
+the most part, hidden away beneath a compatibility flag that is set via the View, allowing each extension to opt-in to the
+extended capabilities or to stick with the legacy behaviour of Fluid. The new features that relate to these new behaviours are:
+
+RenderingContext
+----------------
+
+The most important new piece of public API is the RenderingContext. The previously internal-only RenderingContext used by Fluid
+has been expanded to be responsible for a vital new Fluid feature: implementation provisioning. This enables a developer to
+change a range of classes Fluid uses for parsing, resolving, caching etc. by either including a custom RenderingContext or
+manipulating the default RenderingContext by public methods, a developer is able to change a range of classes Fluid uses for
+parsing, resolving, caching etc.
+
+Each component which can be replaced this way is described in further detail below.
+
+Impact for template developers
+==============================
+
+The following behaviours can all be controlled by manipulating the RenderingContext. By default, none of them are enabled - but
+calling a simple method (via your View instance) allows you to enable them:
+
+.. code-block:: php
+
+       $view->getRenderingContext()->setLegacyMode(false);
+
+Doing so causes the RenderingContext to deliver different implementations, which simply means that in addition to what you
+already know Fluid to be capable of (variable access, inline syntax etc.) you gain access to the following features:
+
+ExpressionNodes
+---------------
+
+Expression Nodes are a new type of Fluid syntax structures which all share a common trait: they only work inside the curly braces
+previously only used by variable accessing and inline syntax of ViewHelpers. You can define the exact collection of
+ExpressionNodes that are active for your rendering process, via the View instance:
+
+.. code-block:: php
+
+       $view->getRenderingContext()->setExpressionNodeTypes(array(
+               'Class\Number\One',
+               'Class\Number\Two'
+       ));
+
+When added to this collection these Expression Node types allow new syntaxes such as ``{myVariable + 1}`` or
+``{myArrayLikeObject as array}``. When the legacy mode toggle is set to ``false`` this will enable the following
+expression types:
+
+1. CastingExpressionNode - this type allows casting a variable to certain types, for example to guarantee an integer or a
+   boolean. It is used simply with an ``as`` keyword: ``{myStringVariable as boolean}``, ``{myBooleanVariable as integer}`` and
+   so on. Attempting to cast a variable to an incompatible type causes a standard Fluid error.
+2. MathExpressionNode - this type allows basic mathematical operations on variables, for example ``{myNumber + 1}``,
+   ``{myPercent / 100}``, ``{myNumber * 100}`` and so on. An impossible expression returns an empty output.
+3. TernaryExpressionNode - this type allows an inline ternary condition which only operates on variables. The use case is "if
+   this variable then use that variable else use another variable". It is used as
+   ``{myToggleVariable ? myThenVariable : myElseVariable}``. Note that it does not support any nested expressions, inline
+   ViewHelper syntaxes or similar inside it - it must be used only with standard variables as input.
+
+Developers can add their own additional ExpressionNodeTypes. Each one consists of a pattern to be matched and methods dictated
+by an interface to process the matches - any existing ExpressionNode type can be used as reference.
+
+Namespaces are extensible
+-------------------------
+
+Fluid now allows each namespace alias (for example ``f:``) to be extended by adding to it additional PHP namespaces that are
+also checked for the presence of ViewHelper classes. This is what allows TYPO3 CMS to transparently add just the ViewHelpers that
+are unique to TYPO3 CMS and let Fluid add the rest. It also means that developers can override individual ViewHelpers with custom
+versions and have their ViewHelpers called when the ``f:`` namespace is used.
+
+This change also implies that namespaces are no longer monadic - any time you use ``{namespace f=My\Extension\ViewHelpers}`` you
+will no longer receive an error with "namespace already registered". Fluid will instead add this PHP namespace and look for
+ViewHelpers there as well. Additional namespaces are checked from the bottom up, allowing the additional namespaces to override
+ViewHelper classes by placing them in the same scope (e.g. ``f:format.nl2br`` can be overridden with
+``My\Extension\ViewHelpers\Format\Nl2brViewHelper`` given the namespace registration example above.
+
+The behaviour is used both for legacy namespace registration in curly braces and the modern ``xmlns`` approach using a
+container HTML tag.
+
+Rendering using f:render
+------------------------
+
+This specific ViewHelper is fundamentally different in the standalone Fluid version - in the default (current) usage scenarios
+it behaves completely like you are used to, but has been fitted with some major impact features that you can use whenever you
+want to, in any template.
+
+There are two specific changes both documented in their respective commits:
+
+1. Default content (when section/partial is missing) now possible - https://github.com/TYPO3Fluid/Fluid/commit/cd67f9d974bc489058bde1c4272b480eb349da09
+2. Tag content of ``f:render`` can now be passed as a variable to the section/partial being rendered (essentially becoming a
+   wrapping/block strategy) - https://github.com/TYPO3Fluid/Fluid/commit/454121cba81baed4e3fe526412ff3e14f7c499a9
+
+All TagBasedViewHelpers natively support data- prefixed attributes
+------------------------------------------------------------------
+
+Simply put - any TagBasedViewHelper can now receive ``data-`` prefixed attributes without requiring those attributes to be
+declared by the ViewHelper. Any suffix can be used as long as the prefix is ``data-``.
+
+Complex conditional statements
+------------------------------
+
+As a forced new feature - which is backwards compatible - Fluid now supports any degree of complex conditional statements with
+nesting and grouping:
+
+.. code-block:: xml
+
+       <f:if condition="({variableOne} && {variableTwo}) || {variableThree} || {variableFour}">
+               // Done if both variable one and two evaluate to true, or if either variable three or four do.
+       </f:if>
+
+In addition, ``f:else`` has been fitted with an "elseif"-like behavior:
+
+.. code-block:: xml
+
+       <f:if condition="{variableOne}">
+               <f:then>Do this</f:then>
+               <f:else if="{variableTwo}">Do this instead if variable two evals true</f:else>
+               <f:else if="{variableThree}">Or do this if variable three evals true</f:else>
+               <f:else>Or do this if nothing above is true</f:else>
+       </f:if>
+
+Dynamic variable name parts
+---------------------------
+
+Another forced new feature, likewise backwards compatible, is the added ability to use sub-variable references when accessing
+your variables. Consider the following Fluid template variables array:
+
+.. code-block:: php
+
+       $mykey = 'foo'; // or 'bar', set by any source
+       $view->assign('data', ['foo' => 1, 'bar' => 2]);
+       $view->assign('key', $mykey);
+
+With the following Fluid template:
+
+.. code-block:: xml
+
+       You chose: {data.{key}}.
+       (output: "1" if key is "foo" or "2" if key is "bar")
+
+The same approach can also be used to generate dynamic parts of a string variable name:
+
+.. code-block:: php
+
+       $mydynamicpart = 'First'; // or 'Second', set by any source
+       $view->assign('myFirstVariable', 1);
+       $view->assign('mySecondVariable', 2);
+       $view->assign('which', $mydynamicpart);
+
+With the following Fluid template:
+
+.. code-block:: xml
+
+       You chose: {my{which}Variable}.
+       (output: "1" if which is "First" or "2" if which is "Second")
+
+This syntax can be used anywhere a variable is referenced, with one exception: variables passed as pure variable accessors cannot
+contain dynamic parts, e.g. the following will **NOT** work:
+
+.. code-block:: xml
+
+       {f:if(condition: my{which}Variable, then: 'this', else: 'that')}
+
+Whereas the following **will** work because the variables are accessed wrapped in a text node:
+
+.. code-block:: xml
+
+       {f:if(condition: '{my{which}Variable}', then: 'this', else: 'that')}
+
+In other words: unless your outer variable reference is enclosed with curly braces, Fluid does not detect that you are
+referencing a dynamic variable and will instead assume you meant a variable actually named ``my{which}Variable`` which was added
+as ``$view->assign('my{which}Variable', 'value')``.
+
+New ViewHelpers
+---------------
+
+A few new ViewHelpers have been added to the collection as part of standalone Fluid and as such are also available in TYPO3 from now on:
+
+* ``f:or`` which is a shorter way to write (chained) conditions. It supports syntax like
+  ``{variableOne -> f:or(alternative: variableTwo) -> f:or(alternative: variableThree)}`` which checks each variable and outputs
+  the first one that's not empty.
+* ``f:spaceless`` which can be used in tag-mode around template code to eliminate redundant whitespace and blank lines for
+  example caused by indenting ViewHelper usages.
+
+Improved error reporting
+------------------------
+
+Syntax errors or problems with required arguments or incorrect argument types will now be reported with line number and template
+code example from the line that fails. Any ViewHelper Exception is turned into this improved error type by converting it to a
+special syntax error and attaching the original Exception to it.
+
+An example error could be:
+
+``TYPO3Fluid\Fluid\Core\Parser\Exception: Fluid parse error in template Default_action_Default_1cb8dc11e29962882f629f79c0b9113ff33d6219,
+line 11 at character 3. Error: The ViewHelper "<f:serender>" could not be resolved. Based on your spelling, the system would load
+the class "TYPO3Fluid\Fluid\ViewHelpers\SerenderViewHelper", however this class does not exist. (1407060572). Template code:
+<f:serender section="Foo" optional="1">``. A stack trace is still included if TYPO3 does not run in Production context.
+
+Impact for extension developers
+===============================
+
+Extension developers are affected mainly by gaining access to a range of new APIs that control Fluid's behavior. These new APIs
+can all be accessed via the RenderingContext which is available in Views and ViewHelpers (also when compiled). Developers can
+provide custom implementations or manipulate the standard implementations by retrieving each API through the RenderingContext
+and using methods of those.
+
+There are no significant changes to best practices and the ViewHelper API (which you use when creating custom ViewHelpers)
+remains largely untouched. The most notable change is that ``$this->renderingContext`` in ViewHelpers and Views now allows direct
+access to on-the-fly changes in Fluid's behavior.
+
+RenderingContext as implementation API
+--------------------------------------
+
+Rather than just being a simple context which hangs on to variables, the RenderingContext has been given a completely new and
+even more vital role in Fluid - it is now the API for delivering custom implementations for a range of features that until now
+were only possible to achieve via means like XCLASSing. A RenderingContext now delivers the following components:
+
+* The VariableProvider (previously known as TemplateVariableContainer, see below) used in rendering
+* The ViewHelperVariableContainer (already known) used in rendering
+* The ViewHelperResolver (new pattern) responsible for handling namespaces and resolving/creating ViewHelper instances
+  and arguments
+* The ViewHelperInvoker (new pattern) responsible for calling ViewHelpers (circumvented when ViewHelpers implement a custom
+  ``compile()`` method)
+* The TemplatePaths (new pattern) which is a template file resolving class that now contains resolving methods previously found
+  on the View itself
+* The TemplateParser (already known) which is responsible for parsing the template and creating a ParsedTemplate
+* The TemplateCompiler (already known) which is responsible for converting a ParsedTemplate to a native PHP class
+* The FluidCache (new pattern) which is a custom caching implementation compatible with TYPO3 caching frontends/backends
+  storing PHP files
+* An array of ExpressionNodeTypes (class names, new pattern) - see description of those above
+* An array of TemplateProcessors (instances, new pattern) which pre-process template source code before it gets handed off to the
+  TemplateParser, allowing things like extracting registered namespaces in custom ways.
+* The controller name, if one applies to the context
+* The controller action name, if one applies to the context
+* And for TYPO3 CMS only, the Extbase ControllerContext (which is as it has always been; contains a Request etc.).
+
+All (!) of which can be replaced with custom implementations and all of which are accessible through View and ViewHelpers alike.
+Just a few of the capabilities you gain:
+
+* You can create custom VariableProvider implementations which retrieve variables in new ways from new sources - Fluid itself now
+  includes a JSON-based VariableProvider as well as a ChainedVariableProvider which allows "plugging" multiple variable sources.
+* You can create a custom ViewHelperResolver implementation which can do things like automatically register namespaces that are
+  always available or change the way ViewHelper classes are detected, instantiated, how arguments are detected, and more.
+* You can create a custom ViewHelperInvoker implementation which calls ViewHelpers in new ways - combined with a custom
+  ViewHelperResolver this can for example allow non-ViewHelper classes to be used as if they actually were ViewHelpers.
+* You can create custom TemplatePaths implementations which for example read template sources not from the local file system but
+  from database, remote storage, zip files, whatever you desire.
+* You can replace the TemplateParser itself (but be careful if you do, obviously). There are no current use cases for this, but
+  the possibility exists.
+* You can replace the TemplateCompiler (be careful here too). No use case exists but this could be used to compile Fluid
+  templates to other things than PHP.
+* You can replace the Cache implementation - for example to cache compiled Fluid templates in memcache or a distributed cache
+  accessible by PHP opcache.
+* You can change which Expression Node types are possible to use in templates rendered with your context, for example disabling
+  ternary expressions or adding a custom type of expression of your own.
+* You can change which TemplateProcessors will be used to process templates when rendered with your context, to do whatever you
+  like - transform, analyse and so on the template source.
+
+All of these parts are possible to replace via the provided RenderingContext - you don't necessarily have to create your own -
+but when creating multiple implementations it is often easier to combine those in a custom RenderingContext and just provide
+that for your View.
+
+But perhaps most importantly, because all of these components are contained in the RenderingContext which is available to Views
+and ViewHelpers alike (also once compiled!), it becomes possible for your View or ViewHelpers to actually interact with the Fluid
+environment in powerful ways. To illustrate how powerful, you could create a single ViewHelper which: manipulates the Expression
+Node types usable in its tag content, changes the paths used to resolve Partials, registers a number of other ViewHelper
+namespaces, changes the variable source to be a JSON file or URL and adds a pre-processing class that triggers on every template
+source read from within the ViewHelper's tag contents, to strip some undesired namespace from third party Partials. And it could
+restore the context afterwards so that all of this only applies inside that ViewHelper's tag content.
+
+ViewHelper namespaces can be extended also from PHP
+---------------------------------------------------
+
+By accessing the ViewHelperResolver of the RenderingContext, developers can change the ViewHelper namespace inclusions on a
+global (read: per View instance) basis:
+
+.. code-block:: php
+
+       $resolver = $view->getRenderingContext()->getViewHelperResolver();
+       // equivalent of registering namespace in template(s):
+       $resolver->registerNamespace('news', 'GeorgRinger\News\ViewHelpers');
+       // adding additional PHP namespaces to check when resolving ViewHelpers:
+       $resolver->extendNamespace('f', 'My\Extension\ViewHelpers');
+       // setting all namespaces in advance, globally, before template parsing:
+       $resolver->setNamespaces(array(
+               'f' => array(
+                       'TYPO3Fluid\\Fluid\\ViewHelpers',
+                       'TYPO3\\CMS\\Fluid\\ViewHelpers',
+                       'My\\Extension\\ViewHelpers'
+               ),
+               'vhs' => array(
+                   'FluidTYPO3\\Vhs\\ViewHelpers',
+                   'My\\Extension\\ViewHelpers'
+               ),
+               'news' => array(
+                       'GeorgRinger\\News\\ViewHelpers',
+               );
+       ));
+
+By "extending" a namespace Fluid adds additional lookup namespaces when detecting ViewHelper classes and uses the last added path first, allowing you to replace ViewHelpers by placing a class with the same sub-name in your own ViewHelpers namespace that extends Fluid's. Doing so also allows you to change the arguments the ViewHelper accepts/requires.
+
+ViewHelpers can accept arbitrary arguments
+------------------------------------------
+
+This feature allows your ViewHelper class to receive any number of additional arguments using any names you desire. It works by
+separating the arguments that are passed to each ViewHelper into two groups: those that are declared using ``registerArgument``
+(or render method arguments), and those that are not. Those that are not declared are then passed to a special function -
+``handleAdditionalArguments`` - on the ViewHelper class, which in the default implementation throws an error if additional
+arguments exist. So by overriding this method in your ViewHelper you can change if and when the ViewHelper should throw an
+error on receiving unregistered arguments.
+
+This feature is also the one allowing TagBasedViewHelpers to freely accept arbitrary ``data-`` prefixed arguments without
+failing - on TagBased ViewHelpers, the ``handleAdditionalArguments`` method simply adds new attributes to the tag that gets
+generated and throws an error if any additional arguments which are neither registered nor prefixed with ``data-`` are given.
+
+ViewHelpers automatically compilable
+------------------------------------
+
+All ViewHelpers, including those you write yourself, are now automatically compilable. This means you no longer have to care
+about implementing the CompilableInterface or a custom ``compile()`` function, and that every Fluid template can now be cached
+to a compiled PHP script regardless of ViewHelpers.
+
+ViewHelpers still are able to define a custom ``compile()`` function but are no longer required to do so. When they don't define
+such a method, an execution is chosen which is identical in performance to calling the ViewHelper from a template that before
+this could not be compiled. The ViewHelpers that do define a custom compiling method can further increase performance.
+
+When you explicitly require a ViewHelper of yours to prevent template caching it is possible to implement a custom ``compile()``
+method which calls ``$templateParser->disable();`` and nothing else. Doing this disables the compiling inside the scope (template,
+partial or section) currently being rendered.
+
+New and more efficient escaping
+-------------------------------
+
+Contrary to earlier versions of Fluid which used a ViewHelperNode for ``f:format.htmlentities`` around other nodes it wished to
+escape, standalone Fluid has implemented a custom SyntaxTreeNode type which does the escaping in a more efficient manner
+(directly using ``htmlentities``). Although it means you cannot override this escaping behaviour by overriding the
+``f:format.htmlentities`` ViewHelper (which is completely possible to do with Fluid now) it should mean a significant boost to
+performance as it avoids an excessive amount of ViewHelper resolving and -rendering operations, replacing them with a single PHP
+function call wrapped in a tiny class, which compiles also to a single function call and which compiles in a way that it wraps
+the compiled output of the Node it escapes as a pure string operation.
+
+Escaping interception is still contained within the ``Configuration`` instance given to the TemplateParser - and those can be
+manipulated with a custom RenderingContext (see above).
diff --git a/typo3/sysext/core/Documentation/Changelog/8.0/Feature-72337-CharsetConversionAutodetection.rst b/typo3/sysext/core/Documentation/Changelog/8.0/Feature-72337-CharsetConversionAutodetection.rst
new file mode 100644 (file)
index 0000000..48ed4b8
--- /dev/null
@@ -0,0 +1,21 @@
+==================================================
+Feature: #72337 - Charset Conversion Autodetection
+==================================================
+
+Description
+===========
+
+The Charset Converter which is used to handle multi-byte charset conversions now
+auto-detects which conversion strategy - either ``mbstring``, ``iconv`` or the
+TYPO3-internal functionality - should be used, based on the available PHP modules
+in the system.
+
+``mbstring`` takes precedence over ``iconv`` and the TYPO3-internal functionality.
+
+
+Impact
+======
+
+The options ``$TYPO3_CONF_VARS['SYS'][t3lib_cs_utils]`` and
+``$TYPO3_CONF_VARS[SYS][t3lib_cs_convMethod]`` have no effect anymore and can be
+removed. TYPO3 chooses the best strategy at runtime.
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/8.0/Feature-72505-IntroduceHookToOverrideARecordOverlay.rst b/typo3/sysext/core/Documentation/Changelog/8.0/Feature-72505-IntroduceHookToOverrideARecordOverlay.rst
new file mode 100644 (file)
index 0000000..ce23299
--- /dev/null
@@ -0,0 +1,31 @@
+=============================================================
+Feature: #72505 - Introduce hook to override a record overlay
+=============================================================
+
+Description
+===========
+
+Prior to TYPO3 7 LTS, it was possible to override a record overlay in Web > List.
+This patch introduces a new hook with the old functionality.
+
+The hook is called with the following signature:
+
+.. code-block:: php
+
+   /**
+    * @param string $table
+    * @param array $row
+    * @param array $status
+    * @param string $iconName
+    * @return string the new (or given) $iconName
+    */
+   function postOverlayPriorityLookup($table, array $row, array $status, $iconName)
+
+Register the hook
+-----------------
+
+Register the hook class which implements the method with the name ``postOverlayPriorityLookup``:
+
+.. code-block:: php
+
+   $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS'][IconFactory::class]['overrideIconOverlay'][] = \VENDOR\MyExt\Hooks\IconFactoryHook::class;
diff --git a/typo3/sysext/core/Documentation/Changelog/8.0/Feature-72904-AddPreProcessStorageSignalToResourceFactory.rst b/typo3/sysext/core/Documentation/Changelog/8.0/Feature-72904-AddPreProcessStorageSignalToResourceFactory.rst
new file mode 100644 (file)
index 0000000..c13f96e
--- /dev/null
@@ -0,0 +1,26 @@
+=================================================================
+Feature: #72904 - Add preProcessStorage signal to ResourceFactory
+=================================================================
+
+Description
+===========
+
+This patch introduces a new signal before a resource storage is initialized.
+
+Register the class which implements your logic in ``ext_localconf.php``:
+
+.. code-block:: php
+
+   $dispatcher = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Extbase\SignalSlot\Dispatcher::class);
+   $dispatcher->connect(
+       \TYPO3\CMS\Core\Resource\ResourceFactory::class,
+       ResourceFactoryInterface::SIGNAL_PreProcessStorage,
+       \MY\ExtKey\Slots\ResourceFactorySlot::class,
+       'preProcessStorage'
+   );
+
+The method is called with the following arguments:
+
+* int ``$uid`` the uid of the record
+* array ``$recordData`` all record data as array
+* string ``$fileIdentifier`` the file identifier
diff --git a/typo3/sysext/core/Documentation/Changelog/8.0/Feature-73042-IntroduceNativeSupportForSymfonyConsole.rst b/typo3/sysext/core/Documentation/Changelog/8.0/Feature-73042-IntroduceNativeSupportForSymfonyConsole.rst
new file mode 100644 (file)
index 0000000..6f39545
--- /dev/null
@@ -0,0 +1,54 @@
+==============================================================
+Feature: #73042 - Introduce native support for Symfony Console
+==============================================================
+
+Description
+===========
+
+TYPO3 supports the Symfony Console component out-of-the-box now by providing a new Command Line script
+located in ``typo3/sysext/core/bin/typo3``. On TYPO3 instances installed via Composer, the binary is
+linked into the ``bin-dir``, e.g. ``bin/typo3``.
+
+The new binary still supports the existing command-line arguments when no proper Symfony Console command
+was found as a fallback.
+
+Registering a command to be available via the ``typo3`` command line tool works by putting a
+``Configuration/Commands.php`` file into any installed extension. This lists the Symfony/Console/Command classes
+to be executed by ``typo3`` is an associative array. The key is the name of the command to be called as
+the first argument to ``typo3``.
+
+A required parameter when registering a command is the ``class`` property. Optionally the ``user`` parameter can be
+set so a backend user is logged in when calling the command.
+
+A ``Configuration/Commands.php`` could look like this:
+
+.. code-block:: php
+
+    return [
+        'backend:lock' => [
+            'class' => \TYPO3\CMS\Backend\Command\LockBackendCommand::class
+        ],
+        'referenceindex:update' => [
+            'class' => \TYPO3\CMS\Backend\Command\ReferenceIndexUpdateCommand::class,
+            'user' => '_cli_lowlevel'
+        ]
+    ];
+
+
+An example call could look like:
+
+.. code-block:: sh
+
+       bin/typo3 backend:lock http://www.mydomain.com/maintenance.html
+
+For a non-Composer installation:
+
+.. code-block:: sh
+
+       typo3/sysext/core/bin/typo3 backend:lock http://www.mydomain.com/maintenance.html
+
+Impact
+======
+
+Using Symfony Commands and calling ``typo3`` instead of using ``typo3/cli_dispatch.phpsh`` is
+now the preferred way for writing command line code.
diff --git a/typo3/sysext/core/Documentation/Changelog/8.0/Feature-73050-AddACSPRNGAPI.rst b/typo3/sysext/core/Documentation/Changelog/8.0/Feature-73050-AddACSPRNGAPI.rst
new file mode 100644 (file)
index 0000000..4339763
--- /dev/null
@@ -0,0 +1,56 @@
+==================================
+Feature: #73050 - Add a CSPRNG API
+==================================
+
+Description
+===========
+
+A new cryptographically secure pseudo-random number generator (CSPRNG) has been
+introduced in TYPO3 core. It takes advantage of the new CSPRNG functions in PHP 7.
+
+
+API overview
+============
+
+The API resides in the class :php:`\TYPO3\CMS\Core\Crypto\Random`. It provides several
+methods. Here is a brief overview of the interface:
+
+.. code-block:: php
+
+    class Random {
+        /**
+         * Generates cryptographic secure pseudo-random bytes
+         */
+        public function generateRandomBytes($length);
+
+        /**
+         * Generates cryptographic secure pseudo-random integers
+         */
+        public function generateRandomInteger($min, $max);
+
+        /**
+         * Generates cryptographic secure pseudo-random hex string
+         */
+        public function generateRandomHexString($length);
+    }
+
+
+Example
+-------
+
+.. code-block:: php
+
+    use \TYPO3\CMS\Core\Crypto\Random;
+    use \TYPO3\CMS\Core\Utility\GeneralUtility;
+
+    // Retrieving random bytes
+    $someRandomString = GeneralUtility::makeInstance(Random::class)->generateRandomBytes(64);
+
+    // Rolling the dice..
+    $tossedValue = GeneralUtility::makeInstance(Random::class)->generateRandomInteger(1, 6);
+
+
+Impact
+======
+
+None, you can start to use the CSPRNG in your code by now.
diff --git a/typo3/sysext/core/Documentation/Changelog/8.0/Feature-73429-WizardComponentHasBeenAdded.rst b/typo3/sysext/core/Documentation/Changelog/8.0/Feature-73429-WizardComponentHasBeenAdded.rst
new file mode 100644 (file)
index 0000000..3287577
--- /dev/null
@@ -0,0 +1,115 @@
+=================================================
+Feature: #73429 - Wizard component has been added
+=================================================
+
+Description
+===========
+
+A new wizard component has been added. This component may be used for user-guided interactions.
+The RequireJS module can be used by including ``TYPO3/CMS/Backend/Wizard``.
+
+The wizard supports straight forward actions only, junctions are not possible yet.
+
+
+Impact
+======
+
+The wizard component has the following public methods:
+#. :code:`addSlide(identifier, title, content, severity, callback)`
+#. :code:`addFinalProcessingSlide(callback)`
+#. :code:`set(key, value)`
+#. :code:`show()`
+#. :code:`dismiss()`
+#. :code:`getComponent()`
+#. :code:`lockNextStep()`
+#. :code:`unlockNextStep()`
+
+addSlide
+~~~~~~~~
+
+Adds a slide to the wizard.
+
+========== =============== ============ ======================================================================================================
+Name       DataType        Mandatory    Description
+========== =============== ============ ======================================================================================================
+identifier string          Yes          The internal identifier of the slide
+title      string          Yes          The title of the slide
+content    string          Yes          The content of the slide
+severity   int                          Represents the severity of a slide. Please see TYPO3.Severity. Default is :code:`TYPO3.Severity.info`.
+callback   function                     Callback method run after the slide appeared. The callback receives two parameters:
+                                        :code:`$slide`: The current slide as a jQuery object
+                                        :code:`settings`: The settings defined via :js:`Wizard.set()`
+========== =============== ============ ======================================================================================================
+
+
+addFinalProcessingSlide
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Adds a slide to the wizard containing a spinner. This should always be the latest slide. This method returns a Promise
+object due to internal handling. This means you have to add a :js:`done()` callback containing :js:`Wizard.show()` and ,
+:js:`Wizard.getComponent()` please see the example below.
+
+========== =============== ============ ======================================================================================================
+Name       DataType        Mandatory    Description
+========== =============== ============ ======================================================================================================
+callback   function                     Callback method run after the slide appeared. If no callback method is given, the wizard dismisses
+                                        without any further action.
+========== =============== ============ ======================================================================================================
+
+Example code:
+
+.. code-block:: js
+
+        Wizard.addFinalProcessingSlide().done(function() {
+            Wizard.show();
+
+            Wizard.getComponent().on('click', '.my-element', function(e) {
+                e.preventDefault();
+                $(this).doSomething();
+            });
+        });
+
+set
+~~~
+
+Adds values to the internal settings stack usable in other slides.
+
+========== =============== ============ ======================================================================================================
+Name       DataType        Mandatory    Description
+========== =============== ============ ======================================================================================================
+key        string          Yes          The key of the setting
+value      string          Yes          The value of the setting
+========== =============== ============ ======================================================================================================
+
+Events
+~~~~~~
+
+The event `wizard-visible` is fired when the wizard rendering has finished.
+
+Example code:
+
+.. code-block:: js
+
+        Wizard.getComponent().on('wizard-visible', function() {
+            Wizard.unlockNextButton();
+        });
+
+
+Wizards can be closed by firing the `wizard-dismiss` event.
+
+Example code:
+
+.. code-block:: js
+
+        Wizard.getComponent().trigger('wizard-dismiss');
+
+
+Wizards fire the `wizard-dismissed` event if the wizard is closed. You can integrate your own listener by using :js:`Wizard.getComponent()`.
+
+Example code:
+
+.. code-block:: js
+
+        Wizard.getComponent().on('wizard-dismissed', function() {
+            // Calculate the answer of life the universe and everything
+        });
diff --git a/typo3/sysext/core/Documentation/Changelog/8.0/Feature-73720-TriggerEventAfterModalWindowDismissed.rst b/typo3/sysext/core/Documentation/Changelog/8.0/Feature-73720-TriggerEventAfterModalWindowDismissed.rst
new file mode 100644 (file)
index 0000000..59ce369
--- /dev/null
@@ -0,0 +1,25 @@
+============================================================
+Feature: #73720 - Trigger event after modal window dismissed
+============================================================
+
+Description
+===========
+
+A new event ``modal-destroyed`` has been added that will be triggered after a modal window closed.
+
+
+Impact
+======
+
+Bind to the event ``modal-destroyed`` to achieve custom actions after the modal
+has been dismissed.
+
+Example code:
+
+.. code-block:: javascript
+
+       var $modal = Modal.confirm(); // stub code
+       $modal.on('modal-destroyed', function() {
+               // Reset the selection
+               $someCombobox.val('');
+       });
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/8.0/Feature-73752-AllowAccessingObjectStorageAsArrayInFluidAndOtherPlaces.rst b/typo3/sysext/core/Documentation/Changelog/8.0/Feature-73752-AllowAccessingObjectStorageAsArrayInFluidAndOtherPlaces.rst
new file mode 100644 (file)
index 0000000..9b97bfc
--- /dev/null
@@ -0,0 +1,25 @@
+==================================================================================
+Feature: #73752 - Allow accessing ObjectStorage as array in Fluid and other places
+==================================================================================
+
+Description
+===========
+
+Creates an alias of ``toArray()`` allowing the method to be called as ``getArray()``
+which in turn allows the method to be called transparently from
+``ObjectAccess::getPropertyPath``, enabling access in Fluid and other places.
+
+
+Impact
+======
+
+By creating an extremely simple aliasing of ``toArray()`` on ObjectStorage allowing
+it to be called as ``getArray()`` enables:
+
+.. code-block:: php
+
+       ObjectAccess::getPropertyPath($subject, 'objectstorageproperty.array.4') to get the 4th element
+
+.. code-block:: text
+
+       {myObject.objectstorageproperty.array.4} in Fluid (including {myObject.objectstorageproperty.array.{dynamicIndex}} in v8)
diff --git a/typo3/sysext/core/Documentation/Changelog/8.0/Feature-74038-ReportForCheckingDatabaseCharacterSet.rst b/typo3/sysext/core/Documentation/Changelog/8.0/Feature-74038-ReportForCheckingDatabaseCharacterSet.rst
new file mode 100644 (file)
index 0000000..f3cb75e
--- /dev/null
@@ -0,0 +1,17 @@
+============================================================
+Feature: #74038 - Report for checking database character set
+============================================================
+
+Description
+===========
+
+If a database has e.g. latin1 as default character set, new tables or fields created
+by TYPO3 will be created with this default charset as utf-8 is not enforced.
+A report has been added that checks the default charset and warns administrators if a
+wrong charset is used.
+
+Impact
+======
+
+If the default database character set is not utf-8, the report warns administrators
+about a wrong charset.
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/8.0/Feature-74109-SetTheAlternativeBackendLogoViaExtensionManager.rst b/typo3/sysext/core/Documentation/Changelog/8.0/Feature-74109-SetTheAlternativeBackendLogoViaExtensionManager.rst
new file mode 100644 (file)
index 0000000..6ce1b16
--- /dev/null
@@ -0,0 +1,17 @@
+========================================================================
+Feature: #74109 - Set the alternative Backend Logo via Extension Manager
+========================================================================
+
+Description
+===========
+
+The Backend Logo in the upper left corner can now be configured in the Extension Configuration of EXT:backend
+within the Extension Manager. A relative path to the TYPO3 installation ("PATH_site"), e.g. "fileadmin/myfile.jpg"
+or a path to an extension, e.g. "EXT:my_theme/Resources/Public/Icons/Logo.png" can be configured there.
+
+The configuration option within the Backend extension (EXT:backend) is called ``backendLogo``.
+
+Impact
+======
+
+The previously available ``$GLOBALS[TBE_STYLES][logo]`` option has no effect anymore.
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/8.0/Feature-74179-PageModuleDragDropCanDoCopiesViaCTRLKeyNow.rst b/typo3/sysext/core/Documentation/Changelog/8.0/Feature-74179-PageModuleDragDropCanDoCopiesViaCTRLKeyNow.rst
new file mode 100644 (file)
index 0000000..2af564e
--- /dev/null
@@ -0,0 +1,12 @@
+========================================================================
+Feature: #74179 - Page Module Drag & Drop Can Do Copies Via CTRL Key Now
+========================================================================
+
+Description
+===========
+
+Additionally to the usual drag  and drop in the page module, that was able to move
+content elements from position A to B, you can do copies via drag & drop now. Just
+press the CTRL-key while dropping to create a copy of the dragged element at the drop
+zone position. After dropping is finished the page module will reload to make sure
+the new element will be generated with all necessary information.
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/8.0/Feature-74319-CheckDefaultDatabaseCharacterSetDuringInstallationAndProvideUpdateWizardForFixingDefaultCharacterSetOtherThanUtf-8.rst b/typo3/sysext/core/Documentation/Changelog/8.0/Feature-74319-CheckDefaultDatabaseCharacterSetDuringInstallationAndProvideUpdateWizardForFixingDefaultCharacterSetOtherThanUtf-8.rst
new file mode 100644 (file)
index 0000000..7410e4d
--- /dev/null
@@ -0,0 +1,28 @@
+======================================================================================================================================================
+Feature: #74319 - check default database character set during Installation and provide Update wizard for fixing default character set other than utf-8
+======================================================================================================================================================
+
+
+Description
+===========
+
+If you install TYPO3 to an existing database with a default charset other than utf-8,
+TYPO3 will create tables with the default charset of that database.
+The install tool should check the default charset and notify the user if it is not utf-8.
+
+Furthermore the install tool should check for this issue too and provide an update
+wizard to fix this (=set the default charset to utf-8 and NOT convert existing tables
+to utf-8).
+A default charset set other than utf-8 leads to non-utf-8 tables when updating the
+database via the install tool or installing extensions.
+
+
+Impact
+======
+
+During installation on database select the default charset of the database is checked.
+If it is not utf-8 the installation will not proceed and the user is notified of the issue.
+
+For existing installations the install tool also provides an environment check and an
+upgrade wizard which changes the default database character set. The update wizard
+will NOT convert any existing tables though!
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/8.0/need_github_docs/Feature-69394-EXTform-DirectlyLoadFormWizardAsInlineWizard.rst b/typo3/sysext/core/Documentation/Changelog/8.0/need_github_docs/Feature-69394-EXTform-DirectlyLoadFormWizardAsInlineWizard.rst
new file mode 100644 (file)
index 0000000..1f19004
--- /dev/null
@@ -0,0 +1,23 @@
+=======================================================================
+Feature: #69394 - EXT:form - Directly load form wizard as inline wizard
+=======================================================================
+
+Description
+===========
+
+The wizard of EXT:form is loaded directly as inline wizard. There is no need anymore
+to save and reload the newly created content element in order to be able to open the
+wizard. This is a huge usability improvement. Additionally there is no need to provide
+individual doc headers. Instead, the centralized doc headers of the module template
+API are used.
+
+The whole integration utilizes the nodeRegistry of formEngine and registers the wizard
+as new render type.
+
+Furthermore, all JavaScript is loaded via require.js.
+
+Since integrators and editors had massive problems with overriden form configuration
+the wizard cannot be deactivated anymore. Instead, the integrator can configure whether
+to load the form wizard by default or not. The following UserTS is integrated by default:
+
+``setup.default.tx_form.showWizardByDefault = 1``
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/8.0/need_github_docs/Feature-70849-MakeSearchLevelsConsistent.rst b/typo3/sysext/core/Documentation/Changelog/8.0/need_github_docs/Feature-70849-MakeSearchLevelsConsistent.rst
new file mode 100644 (file)
index 0000000..aebec6f
--- /dev/null
@@ -0,0 +1,22 @@
+================================================================================
+Important: #70849 - Make search levels in live search and list search consistent
+================================================================================
+
+Description
+===========
+
+In order to make the searchlevel handling consistent between live and list search a new PageTS option has been added.
+
+.. code-block:: typoscript
+
+       mod.web_list.searchLevel.items {
+               -1 = EXT:lang/locallang_core.xlf:labels.searchLevel.infinite
+               0 = EXT:lang/locallang_core.xlf:labels.searchLevel.0
+               1 = EXT:lang/locallang_core.xlf:labels.searchLevel.1
+               2 = EXT:lang/locallang_core.xlf:labels.searchLevel.2
+               3 = EXT:lang/locallang_core.xlf:labels.searchLevel.3
+               4 = EXT:lang/locallang_core.xlf:labels.searchLevel.4
+       }
+
+This makes it possible to add custom search level entries.
+
diff --git a/typo3/sysext/core/Documentation/Changelog/8.0/need_github_docs/Feature-71331-MakeIndexedSearchExtbasePluginFormTargetPidConfigurable.rst b/typo3/sysext/core/Documentation/Changelog/8.0/need_github_docs/Feature-71331-MakeIndexedSearchExtbasePluginFormTargetPidConfigurable.rst
new file mode 100644 (file)
index 0000000..2c7711f
--- /dev/null
@@ -0,0 +1,11 @@
+=================================================================================
+Feature: #71331 - Make indexed_search extbase plugin form target Pid configurable
+=================================================================================
+
+Description
+===========
+
+The search form target page of the extbase variant of EXT:indexed_search can now be
+configured by using the TypoScript option ``plugin.tx_indexedsearch.settings.targetPid = 123``.
+
+If it is empty, the current page will be used.
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/8.0/need_github_docs/Feature-71876-MakeNewContentElementWizardTabSortOrderConfigurable.rst b/typo3/sysext/core/Documentation/Changelog/8.0/need_github_docs/Feature-71876-MakeNewContentElementWizardTabSortOrderConfigurable.rst
new file mode 100644 (file)
index 0000000..a9c0aed
--- /dev/null
@@ -0,0 +1,14 @@
+=============================================================================
+Feature: #71876 - Make new content element wizard tab sort order configurable
+=============================================================================
+
+Description
+===========
+
+It is possible to influence the order of the tabs in the new content element
+wizard by setting ``before`` and ``after`` values in Page TSconfig:
+
+.. code-block:: typoscript
+
+    mod.wizards.newContentElement.wizardItems.special.before = common
+    mod.wizards.newContentElement.wizardItems.forms.after = common,special
diff --git a/typo3/sysext/core/Documentation/Changelog/8.0/need_github_docs/Feature-72045-KeepTagsInHtmlParserWhenStrippingEmptyTags.rst b/typo3/sysext/core/Documentation/Changelog/8.0/need_github_docs/Feature-72045-KeepTagsInHtmlParserWhenStrippingEmptyTags.rst
new file mode 100644 (file)
index 0000000..14a56d5
--- /dev/null
@@ -0,0 +1,28 @@
+====================================================
+Feature: #72045 - HTMLparser.stripEmptyTags.keepTags
+====================================================
+
+Description
+===========
+
+A new option for the ``HTMLparser.stripEmptyTags`` configuration is added.
+It allows keeping configured tags. Before this change only a list of tags
+could be provided that should be removed.
+
+The following example will strip all empty tags **except** ``tr`` and ``td`` tags.
+
+::
+
+    HTMLparser.stripEmptyTags = 1
+    HTMLparser.stripEmptyTags.keepTags = tr,td
+
+
+**Important!** If this setting is used the ``stripEmptyTags.tags`` configuration will
+have no effect any more. You can only use one option at a time.
+
+
+Impact
+======
+
+Unless the configuration of the ``HTMLparser is changed``, the stripEmptyTags
+feature will work as before.
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/8.0/need_github_docs/Feature-72309-EXTform-AllowIntegrationOfPredefinedForms.rst b/typo3/sysext/core/Documentation/Changelog/8.0/need_github_docs/Feature-72309-EXTform-AllowIntegrationOfPredefinedForms.rst
new file mode 100644 (file)
index 0000000..b5e38ea
--- /dev/null
@@ -0,0 +1,109 @@
+============================================================
+Feature: #72309 - EXT:form - Integration of Predefined Forms
+============================================================
+
+Description
+===========
+
+The content element of EXT:form now allows the integration of predefined forms. An integrator can
+define forms - for example within a site package - using ``plugin.tx_form.predefinedForms``. An
+editor can add a new ``mailform`` content element to a page and choose a form from a list of
+predefined elements.
+
+There are even more advantages:
+
+*  Integrators can build there forms with TypoScript which offers much more
+   possibilites than doing it within the form wizard. Especially, the
+   integrator is able to use stdWrap functionalities which are not available when
+   using the form wizard (for security reasons).
+*  There is no need anymore for editors to use the form wizard. They can choose the
+   predefined forms which are optimized layout-wise.
+*  Forms can be re-used throughout the whole installation.
+*  Forms can be stored outside the DB and versionized.
+
+In order to be able to select the pre-defined form in the backend, the form has to be registered
+using PageTS.
+
+.. code-block:: typoscript
+
+   TCEFORM.tt_content.tx_form_predefinedform.addItems.contactForm = LLL:EXT:my_theme/Resources/Private/Language/locallang.xlf:contactForm
+
+Example form:
+
+.. code-block:: typoscript
+
+   plugin.tx_form.predefinedForms.contactForm = FORM
+   plugin.tx_form.predefinedForms.contactForm {
+     enctype = multipart/form-data
+     method = post
+     prefix = contact
+     confirmation = 1
+
+     postProcessor {
+       1 = mail
+       1 {
+         recipientEmail = test@mail.com
+         senderEmail = test@mail.com
+         subject {
+           value = Contact form
+           lang.de = Kontakt Formular
+         }
+       }
+     }
+
+     10 = TEXTLINE
+     10 {
+       name = name
+       type = text
+       required = required
+       label {
+         value = Name
+         lang.de = Name
+       }
+       placeholder {
+         value = Enter your name
+         lang.de = Name eingeben
+       }
+     }
+
+     20 = TEXTLINE
+     20 {
+       name = email
+       type = email
+       required = required
+       label {
+         value = Email
+         lang.de = E-Mail
+       }
+       placeholder {
+         value = Enter your email address
+         lang.de = E-Mail Adresse eingeben
+       }
+     }
+
+     30 = TEXTAREA
+     30 {
+       name = message
+       cols = 40
+       rows = 5
+       required = required
+       label {
+         value = Message
+         lang.de = Nachricht
+       }
+       placeholder {
+         value = Enter your message
+         lang.de = Nachricht eingeben
+       }
+     }
+
+     40 = SUBMIT
+     40 {
+       name = 5
+       type = submit
+       value {
+         value = Send
+         lang.de = Senden
+       }
+     }
+   }
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-1835-RecoverPagesRecursivelyToTop.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-1835-RecoverPagesRecursivelyToTop.rst
deleted file mode 100644 (file)
index 5c85b60..0000000
+++ /dev/null
@@ -1,9 +0,0 @@
-=============================================================
-Feature: #1835 - Recover pages recursively to top of rootline
-=============================================================
-
-Description
-===========
-
-The Recycler now supports the recursive recovery of deleted pages to the top of the rootline. This feature is available
-for admin users only due to internal permission restrictions.
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-19157-impexpCouldHaveAnOptionToExcludeAllHiddenRecords.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-19157-impexpCouldHaveAnOptionToExcludeAllHiddenRecords.rst
deleted file mode 100644 (file)
index 7cb0916..0000000
+++ /dev/null
@@ -1,14 +0,0 @@
-========================================================================
-Feature: #19157 - Add option to exclude all hidden records in EXT:impexp
-========================================================================
-
-Description
-===========
-
-The export configuration of EXT:impexp has been extended to allow to
-completely deactivate exporting of hidden/deactivated records. This
-behaviour can be controlled via a new option which is checked by default.
-
-Furthermore, if the inclusion of hidden records is activated (which is
-now an explicit choice), then an additional button is shown, allowing
-users to preselect all hidden records for manual exclusion.
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-28230-AddSupportForPBKDF2ToSaltedpasswords.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-28230-AddSupportForPBKDF2ToSaltedpasswords.rst
deleted file mode 100644 (file)
index 5ba6078..0000000
+++ /dev/null
@@ -1,16 +0,0 @@
-===========================================================
-Feature: #28230 - Add support for PBKDF2 to saltedpasswords
-===========================================================
-
-Description
-===========
-
-A new password hashing algorithm ``PBKDF2`` has been added to the system extension ``saltedpasswords``.
-PBKDF2 is designed to be computationally expensive to resist brute force password cracking.
-
-
-Impact
-======
-
-None, the new hashing algorithm needs to be enabled by the system administrator in the extension
-configuration and will upgrade existing passwords transparently on login.
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-54887-Post-processingOfThePreviewUrl.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-54887-Post-processingOfThePreviewUrl.rst
deleted file mode 100644 (file)
index 60c8ee0..0000000
+++ /dev/null
@@ -1,35 +0,0 @@
-===================================================
-Feature: #54887 - Post-processing of the previewUrl
-===================================================
-
-Description
-===========
-
-An additional hook is added to the method ``BackendUtility::viewOnClick()`` to post-process the preview url.
-
-The hook is called with the following signature:
-
-.. code-block:: php
-
-   /**
-    * @param string $previewUrl
-    * @param int $pageUid
-    * @param string $backPath
-    * @param array $rootLine
-    * @param string $anchorSection
-    * @param string $viewScript
-    * @param string $additionalGetVars
-    * @param bool $switchFocus
-    * @return string The processed preview URL
-    */
-   function postProcess($previewUrl, $pageUid, $backPath, $rootLine, $anchorSection, $viewScript, $additionalGetVars, $switchFocus)
-
-
-Register the hook
------------------
-
-Register a hook class which implements the method with the name ``postProcess``:
-
-.. code-block:: php
-
-   $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_befunc.php']['viewOnClickClass'][] = \VENDOR\MyExt\Hooks\BackendUtilityHook::class;
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-67236-AddedAllowedTagsArgumentToFformatstripTagsViewHelper.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-67236-AddedAllowedTagsArgumentToFformatstripTagsViewHelper.rst
deleted file mode 100644 (file)
index 6c437aa..0000000
+++ /dev/null
@@ -1,14 +0,0 @@
-===============================================================================
-Feature: #67236 - Added "allowedTags" argument to f:format.stripTags ViewHelper
-===============================================================================
-
-Description
-===========
-
-The argument ``allowedTags`` containing a list of HTML tags which will not be stripped can now be used on ``f:format.stripTags``. Tag list syntax is identical to second parameter of PHP function ``strip_tags``.
-
-
-Impact
-======
-
-New ViewHelper argument (string) ``allowedTags`` becomes available, allowing passing the tag list as second parameter to ``strip_tags``.
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-69394-EXTform-DirectlyLoadFormWizardAsInlineWizard.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-69394-EXTform-DirectlyLoadFormWizardAsInlineWizard.rst
deleted file mode 100644 (file)
index 1aeb041..0000000
+++ /dev/null
@@ -1,16 +0,0 @@
-=======================================================================
-Feature: #69394 - EXT:form - Directly load form wizard as inline wizard
-=======================================================================
-
-Description
-===========
-
-The wizard of EXT:form is loaded directly as inline wizard. There is no need anymore to save and reload the newly created content element in order to be able to open the wizard. This is a huge usability improvement. Additionally there is no need to provide individual doc headers. Instead, the centralized doc headers of the module template API are used.
-
-The whole integration utilizes the nodeRegistry of formEngine and registers the wizard as new render type.
-
-Furthermore, all JavaScript is loaded via require.js.
-
-Since integrators and editors had massive problems with overriden form configuration the wizard cannot be deactivated anymore. Instead, the integrator can configure whether to load the form wizard by default or not. The following UserTS is integrated by default:
-
-``setup.default.tx_form.showWizardByDefault = 1``
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-69794-SupportPecl-memcachedInMemcachedBackend.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-69794-SupportPecl-memcachedInMemcachedBackend.rst
deleted file mode 100644 (file)
index 4f7c64e..0000000
+++ /dev/null
@@ -1,32 +0,0 @@
-============================================================
-Feature: #69794 - Support pecl-memcached in MemcachedBackend
-============================================================
-
-Description
-===========
-
-Support for the PECL module "memcached" has been added to the MemcachedBackend of the Caching Framework.
-
-
-Impact
-======
-
-The MemcachedBackend checks if either "memcache" or "memcached" is installed. If both plugins are installed, the
-MemcachedBackend uses "memcache" over "memcached" to avoid being a breaking change. An integrator may set the option
-``peclModule` to use the preferred PECL module.
-
-Example code:
-
-.. code-block:: php
-
-       $GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['my_memcached'] = [
-               'frontend' => \TYPO3\CMS\Core\Cache\Frontend\VariableFrontend::class
-               'backend' => \TYPO3\CMS\Core\Cache\Backend\MemcachedBackend::class,
-               'options' => [
-                       'peclModule' => 'memcached',
-                       'servers' => [
-                          'localhost',
-                          'server2:port'
-                       ]
-               ]
-       ];
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-69863-UseNewStandaloneFluidAsComposerDependency.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-69863-UseNewStandaloneFluidAsComposerDependency.rst
deleted file mode 100644 (file)
index e8b35cb..0000000
+++ /dev/null
@@ -1,361 +0,0 @@
-=================================================================
-Feature: #69863 - Use new standalone Fluid as composer dependency
-=================================================================
-
-Description
-===========
-
-The Fluid rendering engine of TYPO3 CMS is replaced by the standalone capable Fluid which is now included as composer dependency.
-The old Fluid extension is converted to a so-called Fluid adapter which allows TYPO3 CMS to use standalone Fluid with the many
-new features this facilitates.
-
-
-Impact
-======
-
-New features/capabilities have been added in nearly all areas of Fluid. Most importantly: several of the Fluid components which
-in the past were completely internal and impossible to replace, are now easy to replace and have been fitted with a public API.
-Unless noted otherwise each feature below is part of such a new API component which you can replace. This gives you unprecedented
-control over almost all of Fluid's behaviours in a way that can be controlled via each View instance, for example from within a
-controller's initializeView method.
-
-Developers working with just the template side of Fluid will not notice many differences. Those that they will notice are, for
-the most part, hidden away beneath a compatibility flag that is set via the View, allowing each extension to opt-in to the
-extended capabilities or to stick with the legacy behaviour of Fluid. The new features that relate to these new behaviours are:
-
-RenderingContext
-----------------
-
-The most important new piece of public API is the RenderingContext. The previously internal-only RenderingContext used by Fluid
-has been expanded to be responsible for a vital new Fluid feature: implementation provisioning. This enables a developer to
-change a range of classes Fluid uses for parsing, resolving, caching etc. by either including a custom RenderingContext or
-manipulating the default RenderingContext by public methods, a developer is able to change a range of classes Fluid uses for
-parsing, resolving, caching etc.
-
-Each component which can be replaced this way is described in further detail below.
-
-Impact for template developers
-==============================
-
-The following behaviours can all be controlled by manipulating the RenderingContext. By default, none of them are enabled - but
-calling a simple method (via your View instance) allows you to enable them:
-
-.. code-block:: php
-
-       $view->getRenderingContext()->setLegacyMode(false);
-
-Doing so causes the RenderingContext to deliver different implementations, which simply means that in addition to what you
-already know Fluid to be capable of (variable access, inline syntax etc.) you gain access to the following features:
-
-ExpressionNodes
----------------
-
-Expression Nodes are a new type of Fluid syntax structures which all share a common trait: they only work inside the curly braces
-previously only used by variable accessing and inline syntax of ViewHelpers. You can define the exact collection of
-ExpressionNodes that are active for your rendering process, via the View instance:
-
-.. code-block:: php
-
-       $view->getRenderingContext()->setExpressionNodeTypes(array(
-               'Class\Number\One',
-               'Class\Number\Two'
-       ));
-
-When added to this collection these Expression Node types allow new syntaxes such as ``{myVariable + 1}`` or
-``{myArrayLikeObject as array}``. When the legacy mode toggle is set to ``false`` this will enable the following
-expression types:
-
-1. CastingExpressionNode - this type allows casting a variable to certain types, for example to guarantee an integer or a
-   boolean. It is used simply with an ``as`` keyword: ``{myStringVariable as boolean}``, ``{myBooleanVariable as integer}`` and
-   so on. Attempting to cast a variable to an incompatible type causes a standard Fluid error.
-2. MathExpressionNode - this type allows basic mathematical operations on variables, for example ``{myNumber + 1}``,
-   ``{myPercent / 100}``, ``{myNumber * 100}`` and so on. An impossible expression returns an empty output.
-3. TernaryExpressionNode - this type allows an inline ternary condition which only operates on variables. The use case is "if
-   this variable then use that variable else use another variable". It is used as
-   ``{myToggleVariable ? myThenVariable : myElseVariable}``. Note that it does not support any nested expressions, inline
-   ViewHelper syntaxes or similar inside it - it must be used only with standard variables as input.
-
-Developers can add their own additional ExpressionNodeTypes. Each one consists of a pattern to be matched and methods dictated
-by an interface to process the matches - any existing ExpressionNode type can be used as reference.
-
-Namespaces are extensible
--------------------------
-
-Fluid now allows each namespace alias (for example ``f:``) to be extended by adding to it additional PHP namespaces that are
-also checked for the presence of ViewHelper classes. This is what allows TYPO3 CMS to transparently add just the ViewHelpers that
-are unique to TYPO3 CMS and let Fluid add the rest. It also means that developers can override individual ViewHelpers with custom
-versions and have their ViewHelpers called when the ``f:`` namespace is used.
-
-This change also implies that namespaces are no longer monadic - any time you use ``{namespace f=My\Extension\ViewHelpers}`` you
-will no longer receive an error with "namespace already registered". Fluid will instead add this PHP namespace and look for
-ViewHelpers there as well. Additional namespaces are checked from the bottom up, allowing the additional namespaces to override
-ViewHelper classes by placing them in the same scope (e.g. ``f:format.nl2br`` can be overridden with
-``My\Extension\ViewHelpers\Format\Nl2brViewHelper`` given the namespace registration example above.
-
-The behaviour is used both for legacy namespace registration in curly braces and the modern ``xmlns`` approach using a
-container HTML tag.
-
-Rendering using f:render
-------------------------
-
-This specific ViewHelper is fundamentally different in the standalone Fluid version - in the default (current) usage scenarios
-it behaves completely like you are used to, but has been fitted with some major impact features that you can use whenever you
-want to, in any template.
-
-There are two specific changes both documented in their respective commits:
-
-1. Default content (when section/partial is missing) now possible - https://github.com/TYPO3Fluid/Fluid/commit/cd67f9d974bc489058bde1c4272b480eb349da09
-2. Tag content of ``f:render`` can now be passed as a variable to the section/partial being rendered (essentially becoming a
-   wrapping/block strategy) - https://github.com/TYPO3Fluid/Fluid/commit/454121cba81baed4e3fe526412ff3e14f7c499a9
-
-All TagBasedViewHelpers natively support data- prefixed attributes
-------------------------------------------------------------------
-
-Simply put - any TagBasedViewHelper can now receive ``data-`` prefixed attributes without requiring those attributes to be
-declared by the ViewHelper. Any suffix can be used as long as the prefix is ``data-``.
-
-Complex conditional statements
-------------------------------
-
-As a forced new feature - which is backwards compatible - Fluid now supports any degree of complex conditional statements with
-nesting and grouping:
-
-.. code-block:: xml
-
-       <f:if condition="({variableOne} && {variableTwo}) || {variableThree} || {variableFour}">
-               // Done if both variable one and two evaluate to true, or if either variable three or four do.
-       </f:if>
-
-In addition, ``f:else`` has been fitted with an "elseif"-like behavior:
-
-.. code-block:: xml
-
-       <f:if condition="{variableOne}">
-               <f:then>Do this</f:then>
-               <f:else if="{variableTwo}">Do this instead if variable two evals true</f:else>
-               <f:else if="{variableThree}">Or do this if variable three evals true</f:else>
-               <f:else>Or do this if nothing above is true</f:else>
-       </f:if>
-
-Dynamic variable name parts
----------------------------
-
-Another forced new feature, likewise backwards compatible, is the added ability to use sub-variable references when accessing
-your variables. Consider the following Fluid template variables array:
-
-.. code-block:: php
-
-       $mykey = 'foo'; // or 'bar', set by any source
-       $view->assign('data', ['foo' => 1, 'bar' => 2]);
-       $view->assign('key', $mykey);
-
-With the following Fluid template:
-
-.. code-block:: xml
-
-       You chose: {data.{key}}.
-       (output: "1" if key is "foo" or "2" if key is "bar")
-
-The same approach can also be used to generate dynamic parts of a string variable name:
-
-.. code-block:: php
-
-       $mydynamicpart = 'First'; // or 'Second', set by any source
-       $view->assign('myFirstVariable', 1);
-       $view->assign('mySecondVariable', 2);
-       $view->assign('which', $mydynamicpart);
-
-With the following Fluid template:
-
-.. code-block:: xml
-
-       You chose: {my{which}Variable}.
-       (output: "1" if which is "First" or "2" if which is "Second")
-
-This syntax can be used anywhere a variable is referenced, with one exception: variables passed as pure variable accessors cannot
-contain dynamic parts, e.g. the following will **NOT** work:
-
-.. code-block:: xml
-
-       {f:if(condition: my{which}Variable, then: 'this', else: 'that')}
-
-Whereas the following **will** work because the variables are accessed wrapped in a text node:
-
-.. code-block:: xml
-
-       {f:if(condition: '{my{which}Variable}', then: 'this', else: 'that')}
-
-In other words: unless your outer variable reference is enclosed with curly braces, Fluid does not detect that you are
-referencing a dynamic variable and will instead assume you meant a variable actually named ``my{which}Variable`` which was added
-as ``$view->assign('my{which}Variable', 'value')``.
-
-New ViewHelpers
----------------
-
-A few new ViewHelpers have been added to the collection as part of standalone Fluid and as such are also available in TYPO3 from now on:
-
-* ``f:or`` which is a shorter way to write (chained) conditions. It supports syntax like
-  ``{variableOne -> f:or(alternative: variableTwo) -> f:or(alternative: variableThree)}`` which checks each variable and outputs
-  the first one that's not empty.
-* ``f:spaceless`` which can be used in tag-mode around template code to eliminate redundant whitespace and blank lines for
-  example caused by indenting ViewHelper usages.
-
-Improved error reporting
-------------------------
-
-Syntax errors or problems with required arguments or incorrect argument types will now be reported with line number and template
-code example from the line that fails. Any ViewHelper Exception is turned into this improved error type by converting it to a
-special syntax error and attaching the original Exception to it.
-
-An example error could be:
-
-``TYPO3Fluid\Fluid\Core\Parser\Exception: Fluid parse error in template Default_action_Default_1cb8dc11e29962882f629f79c0b9113ff33d6219,
-line 11 at character 3. Error: The ViewHelper "<f:serender>" could not be resolved. Based on your spelling, the system would load
-the class "TYPO3Fluid\Fluid\ViewHelpers\SerenderViewHelper", however this class does not exist. (1407060572). Template code:
-<f:serender section="Foo" optional="1">``. A stack trace is still included if TYPO3 does not run in Production context.
-
-Impact for extension developers
-===============================
-
-Extension developers are affected mainly by gaining access to a range of new APIs that control Fluid's behavior. These new APIs
-can all be accessed via the RenderingContext which is available in Views and ViewHelpers (also when compiled). Developers can
-provide custom implementations or manipulate the standard implementations by retrieving each API through the RenderingContext
-and using methods of those.
-
-There are no significant changes to best practices and the ViewHelper API (which you use when creating custom ViewHelpers)
-remains largely untouched. The most notable change is that ``$this->renderingContext`` in ViewHelpers and Views now allows direct
-access to on-the-fly changes in Fluid's behavior.
-
-RenderingContext as implementation API
---------------------------------------
-
-Rather than just being a simple context which hangs on to variables, the RenderingContext has been given a completely new and
-even more vital role in Fluid - it is now the API for delivering custom implementations for a range of features that until now
-were only possible to achieve via means like XCLASSing. A RenderingContext now delivers the following components:
-
-* The VariableProvider (previously known as TemplateVariableContainer, see below) used in rendering
-* The ViewHelperVariableContainer (already known) used in rendering
-* The ViewHelperResolver (new pattern) responsible for handling namespaces and resolving/creating ViewHelper instances
-  and arguments
-* The ViewHelperInvoker (new pattern) responsible for calling ViewHelpers (circumvented when ViewHelpers implement a custom
-  ``compile()`` method)
-* The TemplatePaths (new pattern) which is a template file resolving class that now contains resolving methods previously found
-  on the View itself
-* The TemplateParser (already known) which is responsible for parsing the template and creating a ParsedTemplate
-* The TemplateCompiler (already known) which is responsible for converting a ParsedTemplate to a native PHP class
-* The FluidCache (new pattern) which is a custom caching implementation compatible with TYPO3 caching frontends/backends
-  storing PHP files
-* An array of ExpressionNodeTypes (class names, new pattern) - see description of those above
-* An array of TemplateProcessors (instances, new pattern) which pre-process template source code before it gets handed off to the
-  TemplateParser, allowing things like extracting registered namespaces in custom ways.
-* The controller name, if one applies to the context
-* The controller action name, if one applies to the context
-* And for TYPO3 CMS only, the Extbase ControllerContext (which is as it has always been; contains a Request etc.).
-
-All (!) of which can be replaced with custom implementations and all of which are accessible through View and ViewHelpers alike.
-Just a few of the capabilities you gain:
-
-* You can create custom VariableProvider implementations which retrieve variables in new ways from new sources - Fluid itself now
-  includes a JSON-based VariableProvider as well as a ChainedVariableProvider which allows "plugging" multiple variable sources.
-* You can create a custom ViewHelperResolver implementation which can do things like automatically register namespaces that are
-  always available or change the way ViewHelper classes are detected, instantiated, how arguments are detected, and more.
-* You can create a custom ViewHelperInvoker implementation which calls ViewHelpers in new ways - combined with a custom
-  ViewHelperResolver this can for example allow non-ViewHelper classes to be used as if they actually were ViewHelpers.
-* You can create custom TemplatePaths implementations which for example read template sources not from the local file system but
-  from database, remote storage, zip files, whatever you desire.
-* You can replace the TemplateParser itself (but be careful if you do, obviously). There are no current use cases for this, but
-  the possibility exists.
-* You can replace the TemplateCompiler (be careful here too). No use case exists but this could be used to compile Fluid
-  templates to other things than PHP.
-* You can replace the Cache implementation - for example to cache compiled Fluid templates in memcache or a distributed cache
-  accessible by PHP opcache.
-* You can change which Expression Node types are possible to use in templates rendered with your context, for example disabling
-  ternary expressions or adding a custom type of expression of your own.
-* You can change which TemplateProcessors will be used to process templates when rendered with your context, to do whatever you
-  like - transform, analyse and so on the template source.
-
-All of these parts are possible to replace via the provided RenderingContext - you don't necessarily have to create your own -
-but when creating multiple implementations it is often easier to combine those in a custom RenderingContext and just provide
-that for your View.
-
-But perhaps most importantly, because all of these components are contained in the RenderingContext which is available to Views
-and ViewHelpers alike (also once compiled!), it becomes possible for your View or ViewHelpers to actually interact with the Fluid
-environment in powerful ways. To illustrate how powerful, you could create a single ViewHelper which: manipulates the Expression
-Node types usable in its tag content, changes the paths used to resolve Partials, registers a number of other ViewHelper
-namespaces, changes the variable source to be a JSON file or URL and adds a pre-processing class that triggers on every template
-source read from within the ViewHelper's tag contents, to strip some undesired namespace from third party Partials. And it could
-restore the context afterwards so that all of this only applies inside that ViewHelper's tag content.
-
-ViewHelper namespaces can be extended also from PHP
----------------------------------------------------
-
-By accessing the ViewHelperResolver of the RenderingContext, developers can change the ViewHelper namespace inclusions on a
-global (read: per View instance) basis:
-
-.. code-block:: php
-
-       $resolver = $view->getRenderingContext()->getViewHelperResolver();
-       // equivalent of registering namespace in template(s):
-       $resolver->registerNamespace('news', 'GeorgRinger\News\ViewHelpers');
-       // adding additional PHP namespaces to check when resolving ViewHelpers:
-       $resolver->extendNamespace('f', 'My\Extension\ViewHelpers');
-       // setting all namespaces in advance, globally, before template parsing:
-       $resolver->setNamespaces(array(
-               'f' => array(
-                       'TYPO3Fluid\\Fluid\\ViewHelpers',
-                       'TYPO3\\CMS\\Fluid\\ViewHelpers',
-                       'My\\Extension\\ViewHelpers'
-               ),
-               'vhs' => array(
-                   'FluidTYPO3\\Vhs\\ViewHelpers',
-                   'My\\Extension\\ViewHelpers'
-               ),
-               'news' => array(
-                       'GeorgRinger\\News\\ViewHelpers',
-               );
-       ));
-
-By "extending" a namespace Fluid adds additional lookup namespaces when detecting ViewHelper classes and uses the last added path first, allowing you to replace ViewHelpers by placing a class with the same sub-name in your own ViewHelpers namespace that extends Fluid's. Doing so also allows you to change the arguments the ViewHelper accepts/requires.
-
-ViewHelpers can accept arbitrary arguments
-------------------------------------------
-
-This feature allows your ViewHelper class to receive any number of additional arguments using any names you desire. It works by
-separating the arguments that are passed to each ViewHelper into two groups: those that are declared using ``registerArgument``
-(or render method arguments), and those that are not. Those that are not declared are then passed to a special function -
-``handleAdditionalArguments`` - on the ViewHelper class, which in the default implementation throws an error if additional
-arguments exist. So by overriding this method in your ViewHelper you can change if and when the ViewHelper should throw an
-error on receiving unregistered arguments.
-
-This feature is also the one allowing TagBasedViewHelpers to freely accept arbitrary ``data-`` prefixed arguments without
-failing - on TagBased ViewHelpers, the ``handleAdditionalArguments`` method simply adds new attributes to the tag that gets
-generated and throws an error if any additional arguments which are neither registered nor prefixed with ``data-`` are given.
-
-ViewHelpers automatically compilable
-------------------------------------
-
-All ViewHelpers, including those you write yourself, are now automatically compilable. This means you no longer have to care
-about implementing the CompilableInterface or a custom ``compile()`` function, and that every Fluid template can now be cached
-to a compiled PHP script regardless of ViewHelpers.
-
-ViewHelpers still are able to define a custom ``compile()`` function but are no longer required to do so. When they don't define
-such a method, an execution is chosen which is identical in performance to calling the ViewHelper from a template that before
-this could not be compiled. The ViewHelpers that do define a custom compiling method can further increase performance.
-
-When you explicitly require a ViewHelper of yours to prevent template caching it is possible to implement a custom ``compile()``
-method which calls ``$templateParser->disable();`` and nothing else. Doing this disables the compiling inside the scope (template,
-partial or section) currently being rendered.
-
-New and more efficient escaping
--------------------------------
-
-Contrary to earlier versions of Fluid which used a ViewHelperNode for ``f:format.htmlentities`` around other nodes it wished to
-escape, standalone Fluid has implemented a custom SyntaxTreeNode type which does the escaping in a more efficient manner
-(directly using ``htmlentities``). Although it means you cannot override this escaping behaviour by overriding the
-``f:format.htmlentities`` ViewHelper (which is completely possible to do with Fluid now) it should mean a significant boost to
-performance as it avoids an excessive amount of ViewHelper resolving and -rendering operations, replacing them with a single PHP
-function call wrapped in a tiny class, which compiles also to a single function call and which compiles in a way that it wraps
-the compiled output of the Node it escapes as a pure string operation.
-
-Escaping interception is still contained within the ``Configuration`` instance given to the TemplateParser - and those can be
-manipulated with a custom RenderingContext (see above).
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-71331-MakeIndexedSearchExtbasePluginFormTargetPidConfigurable.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-71331-MakeIndexedSearchExtbasePluginFormTargetPidConfigurable.rst
deleted file mode 100644 (file)
index 0e0a0d8..0000000
+++ /dev/null
@@ -1,10 +0,0 @@
-=================================================================================
-Feature: #71331 - Make indexed search extbase plugin form target Pid configurable
-=================================================================================
-
-Description
-===========
-
-The search form target page of the extbase variant of indexed:search can now be configured by using the TypoScript option ``plugin.tx_indexedsearch.settings.targetPid = 123``.
-
-If it is empty, the current page will be used.
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-71876-MakeNewContentElementWizardTabSortOrderConfigurable.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-71876-MakeNewContentElementWizardTabSortOrderConfigurable.rst
deleted file mode 100644 (file)
index a9c0aed..0000000
+++ /dev/null
@@ -1,14 +0,0 @@
-=============================================================================
-Feature: #71876 - Make new content element wizard tab sort order configurable
-=============================================================================
-
-Description
-===========
-
-It is possible to influence the order of the tabs in the new content element
-wizard by setting ``before`` and ``after`` values in Page TSconfig:
-
-.. code-block:: typoscript
-
-    mod.wizards.newContentElement.wizardItems.special.before = common
-    mod.wizards.newContentElement.wizardItems.forms.after = common,special
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-72045-KeepTagsInHtmlParserWhenStrippingEmptyTags.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-72045-KeepTagsInHtmlParserWhenStrippingEmptyTags.rst
deleted file mode 100644 (file)
index 77571fb..0000000
+++ /dev/null
@@ -1,28 +0,0 @@
-====================================================
-Feature: #72045 - HTMLparser.stripEmptyTags.keepTags
-====================================================
-
-Description
-===========
-
-A new option for the HTMLparser.stripEmptyTags configuration is added.
-It allows keeping configured tags. Before this change only a list of tags
-could be provided that should be removed.
-
-The following example will strip all empty tags **except** ``tr`` and ``td`` tags.
-
-::
-
-    HTMLparser.stripEmptyTags = 1
-    HTMLparser.stripEmptyTags.keepTags = tr,td
-
-
-**Important!** If this setting is used the stripEmptyTags.tags configuration will
-have no effect any more. You can only use one option at a time.
-
-
-Impact
-======
-
-Unless the configuration of the HTMLparser is changed, the stripEmptyTags
-feature will work as before.
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-72309-EXTform-AllowIntegrationOfPredefinedForms.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-72309-EXTform-AllowIntegrationOfPredefinedForms.rst
deleted file mode 100644 (file)
index b35b795..0000000
+++ /dev/null
@@ -1,108 +0,0 @@
-============================================================
-Feature: #72309 - EXT:form - Integration of Predefined Forms
-============================================================
-
-Description
-===========
-
-The content element of EXT:form now allows the integration of predefined forms. An integrator can
-define forms - for example within a site package - using ``plugin.tx_form.predefinedForms``. An
-editor can add a new ``mailform`` content element to a page and choose a form from a list of
-predefined elements.
-
-There are even more advantages:
-
-- Integrators can build there forms with TypoScript which offers much more possibilites than doing
-it within the form wizard. Especially, the integrator is able to use stdWrap functionalities which
-are not available when using the form wizard (for security reasons).
-- There is no need anymore for editors to use the form wizard. They can choose the predefined forms
-which are optimized layout-wise.
-- Forms can be re-used throughout the whole installation.
-- Forms can be stored outside the DB and versionized.
-
-In order to be able to select the pre-defined form in the backend, the form has to be registered
-using PageTS.
-
-.. code-block:: typoscript
-
-   TCEFORM.tt_content.tx_form_predefinedform.addItems.contactForm = LLL:EXT:my_theme/Resources/Private/Language/locallang.xlf:contactForm
-
-Example form:
-
-.. code-block:: typoscript
-
-   plugin.tx_form.predefinedForms.contactForm = FORM
-   plugin.tx_form.predefinedForms.contactForm {
-     enctype = multipart/form-data
-     method = post
-     prefix = contact
-     confirmation = 1
-
-     postProcessor {
-       1 = mail
-       1 {
-         recipientEmail = test@mail.com
-         senderEmail = test@mail.com
-         subject {
-           value = Contact form
-           lang.de = Kontakt Formular
-         }
-       }
-     }
-
-     10 = TEXTLINE
-     10 {
-       name = name
-       type = text
-       required = required
-       label {
-         value = Name
-         lang.de = Name
-       }
-       placeholder {
-         value = Enter your name
-         lang.de = Name eingeben
-       }
-     }
-
-     20 = TEXTLINE
-     20 {
-       name = email
-       type = email
-       required = required
-       label {
-         value = Email
-         lang.de = E-Mail
-       }
-       placeholder {
-         value = Enter your email address
-         lang.de = E-Mail Adresse eingeben
-       }
-     }
-
-     30 = TEXTAREA
-     30 {
-       name = message
-       cols = 40
-       rows = 5
-       required = required
-       label {
-         value = Message
-         lang.de = Nachricht
-       }
-       placeholder {
-         value = Enter your message
-         lang.de = Nachricht eingeben
-       }
-     }
-
-     40 = SUBMIT
-     40 {
-       name = 5
-       type = submit
-       value {
-         value = Send
-         lang.de = Senden
-       }
-     }
-   }
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-72337-CharsetConversionAutodetection.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-72337-CharsetConversionAutodetection.rst
deleted file mode 100644 (file)
index 66eff8d..0000000
+++ /dev/null
@@ -1,18 +0,0 @@
-==================================================
-Feature: #72337 - Charset Conversion Autodetection
-==================================================
-
-Description
-===========
-
-The Charset Converter which is used to handle multi-byte charset conversions now autodetects which conversion
-strategy - either ``mbstring``, ``iconv`` or the TYPO3-internal functionality should be used, based on the available
-PHP modules in the system.
-
-``mbstring`` takes precedence over ``iconv`` and the TYPO3-internal functionality.
-
-
-Impact
-======
-
-The options ``$TYPO3_CONF_VARS['SYS'][t3lib_cs_utils]`` and ``$TYPO3_CONF_VARS[SYS][t3lib_cs_convMethod]`` have no effect anymore and can be removed. TYPO3 chooses the best strategy at runtime.
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-72505-IntroduceHookToOverrideARecordOverlay.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-72505-IntroduceHookToOverrideARecordOverlay.rst
deleted file mode 100644 (file)
index ce23299..0000000
+++ /dev/null
@@ -1,31 +0,0 @@
-=============================================================
-Feature: #72505 - Introduce hook to override a record overlay
-=============================================================
-
-Description
-===========
-
-Prior to TYPO3 7 LTS, it was possible to override a record overlay in Web > List.
-This patch introduces a new hook with the old functionality.
-
-The hook is called with the following signature:
-
-.. code-block:: php
-
-   /**
-    * @param string $table
-    * @param array $row
-    * @param array $status
-    * @param string $iconName
-    * @return string the new (or given) $iconName
-    */
-   function postOverlayPriorityLookup($table, array $row, array $status, $iconName)
-
-Register the hook
------------------
-
-Register the hook class which implements the method with the name ``postOverlayPriorityLookup``:
-
-.. code-block:: php
-
-   $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS'][IconFactory::class]['overrideIconOverlay'][] = \VENDOR\MyExt\Hooks\IconFactoryHook::class;
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-72904-AddPreProcessStorageSignalToResourceFactory.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-72904-AddPreProcessStorageSignalToResourceFactory.rst
deleted file mode 100644 (file)
index c13f96e..0000000
+++ /dev/null
@@ -1,26 +0,0 @@
-=================================================================
-Feature: #72904 - Add preProcessStorage signal to ResourceFactory
-=================================================================
-
-Description
-===========
-
-This patch introduces a new signal before a resource storage is initialized.
-
-Register the class which implements your logic in ``ext_localconf.php``:
-
-.. code-block:: php
-
-   $dispatcher = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Extbase\SignalSlot\Dispatcher::class);
-   $dispatcher->connect(
-       \TYPO3\CMS\Core\Resource\ResourceFactory::class,
-       ResourceFactoryInterface::SIGNAL_PreProcessStorage,
-       \MY\ExtKey\Slots\ResourceFactorySlot::class,
-       'preProcessStorage'
-   );
-
-The method is called with the following arguments:
-
-* int ``$uid`` the uid of the record
-* array ``$recordData`` all record data as array
-* string ``$fileIdentifier`` the file identifier
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-73042-IntroduceNativeSupportForSymfonyConsole.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-73042-IntroduceNativeSupportForSymfonyConsole.rst
deleted file mode 100644 (file)
index 6f39545..0000000
+++ /dev/null
@@ -1,54 +0,0 @@
-==============================================================
-Feature: #73042 - Introduce native support for Symfony Console
-==============================================================
-
-Description
-===========
-
-TYPO3 supports the Symfony Console component out-of-the-box now by providing a new Command Line script
-located in ``typo3/sysext/core/bin/typo3``. On TYPO3 instances installed via Composer, the binary is
-linked into the ``bin-dir``, e.g. ``bin/typo3``.
-
-The new binary still supports the existing command-line arguments when no proper Symfony Console command
-was found as a fallback.
-
-Registering a command to be available via the ``typo3`` command line tool works by putting a
-``Configuration/Commands.php`` file into any installed extension. This lists the Symfony/Console/Command classes
-to be executed by ``typo3`` is an associative array. The key is the name of the command to be called as
-the first argument to ``typo3``.
-
-A required parameter when registering a command is the ``class`` property. Optionally the ``user`` parameter can be
-set so a backend user is logged in when calling the command.
-
-A ``Configuration/Commands.php`` could look like this:
-
-.. code-block:: php
-
-    return [
-        'backend:lock' => [
-            'class' => \TYPO3\CMS\Backend\Command\LockBackendCommand::class
-        ],
-        'referenceindex:update' => [
-            'class' => \TYPO3\CMS\Backend\Command\ReferenceIndexUpdateCommand::class,
-            'user' => '_cli_lowlevel'
-        ]
-    ];
-
-
-An example call could look like:
-
-.. code-block:: sh
-
-       bin/typo3 backend:lock http://www.mydomain.com/maintenance.html
-
-For a non-Composer installation:
-
-.. code-block:: sh
-
-       typo3/sysext/core/bin/typo3 backend:lock http://www.mydomain.com/maintenance.html
-
-Impact
-======
-
-Using Symfony Commands and calling ``typo3`` instead of using ``typo3/cli_dispatch.phpsh`` is
-now the preferred way for writing command line code.
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-73050-AddACSPRNGAPI.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-73050-AddACSPRNGAPI.rst
deleted file mode 100644 (file)
index 2ceb41a..0000000
+++ /dev/null
@@ -1,54 +0,0 @@
-==================================
-Feature: #73050 - Add a CSPRNG API
-==================================
-
-Description
-===========
-
-A new cryptographically secure pseudo-random number generator (CSPRNG) is introduced in TYPO3 core. It takes advantage of the new CSPRNG functions in PHP 7.
-
-
-API overview
-============
-
-The API resides in the class :php:`\TYPO3\CMS\Core\Crypto\Random`. It provides several methods. Here is a brief overview of the interface:
-
-.. code-block:: php
-
-    class Random {
-        /**
-         * Generates cryptographic secure pseudo-random bytes
-         */
-        public function generateRandomBytes($length);
-
-        /**
-         * Generates cryptographic secure pseudo-random integers
-         */
-        public function generateRandomInteger($min, $max);
-
-        /**
-         * Generates cryptographic secure pseudo-random hex string
-         */
-        public function generateRandomHexString($length);
-    }
-
-
-Example
--------
-
-.. code-block:: php
-
-    use \TYPO3\CMS\Core\Crypto\Random;
-    use \TYPO3\CMS\Core\Utility\GeneralUtility;
-
-    // Retrieving random bytes
-    $someRandomString = GeneralUtility::makeInstance(Random::class)->generateRandomBytes(64);
-
-    // Rolling the dice..
-    $tossedValue = GeneralUtility::makeInstance(Random::class)->generateRandomInteger(1, 6);
-
-
-Impact
-======
-
-None, you can start to use the CSPRNG in your code by now.
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-73429-WizardComponentHasBeenAdded.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-73429-WizardComponentHasBeenAdded.rst
deleted file mode 100644 (file)
index 7d0d87c..0000000
+++ /dev/null
@@ -1,115 +0,0 @@
-=================================================
-Feature: #73429 - Wizard component has been added
-=================================================
-
-Description
-===========
-
-A new wizard component has been added. This component may be used for user-guided interactions.
-The RequireJS module can be used by including ``TYPO3/CMS/Backend/Wizard``.
-
-The wizard supports straight forward actions only, junctions are not possible yet.
-
-
-Impact
-======
-
-The wizard component has some public methods:
-#. :code:`addSlide(identifier, title, content, severity, callback)`
-#. :code:`addFinalProcessingSlide(callback)`
-#. :code:`set(key, value)`
-#. :code:`show()`
-#. :code:`dismiss()`
-#. :code:`getComponent()`
-#. :code:`lockNextStep()`
-#. :code:`unlockNextStep()`
-
-addSlide
-~~~~~~~~
-
-Adds a slide to the wizard.
-
-========== =============== ============ ======================================================================================================
-Name       DataType        Mandatory    Description
-========== =============== ============ ======================================================================================================
-identifier string          Yes          The internal identifier of the slide
-title      string          Yes          The title of the slide
-content    string          Yes          The content of the slide
-severity   int                          Represents the severity of a slide. Please see TYPO3.Severity. Default is :code:`TYPO3.Severity.info`.
-callback   function                     Callback method run after the slide appeared. The callback receives two parameters:
-                                        :code:`$slide`: The current slide as a jQuery object
-                                        :code:`settings`: The settings defined via :js:`Wizard.set()`
-========== =============== ============ ======================================================================================================
-
-
-addFinalProcessingSlide
-~~~~~~~~~~~~~~~~~~~~~~~
-
-Adds a slide to the wizard containing a spinner. This should always be the latest slide. This method returns a Promise
-object due to internal handling. This means you have to add a :js:`done()` callback containing :js:`Wizard.show()` and ,
-:js:`Wizard.getComponent()` please see the example below.
-
-========== =============== ============ ======================================================================================================
-Name       DataType        Mandatory    Description
-========== =============== ============ ======================================================================================================
-callback   function                     Callback method run after the slide appeared. If no callback method is given, the wizard dismisses
-                                        without any further action.
-========== =============== ============ ======================================================================================================
-
-Example code:
-
-.. code-block:: js
-
-        Wizard.addFinalProcessingSlide().done(function() {
-            Wizard.show();
-
-            Wizard.getComponent().on('click', '.my-element', function(e) {
-                e.preventDefault();
-                $(this).doSomething();
-            });
-        });
-
-set
-~~~
-
-Adds values to the internal settings stack usable in other slides.
-
-========== =============== ============ ======================================================================================================
-Name       DataType        Mandatory    Description
-========== =============== ============ ======================================================================================================
-key        string          Yes          The key of the setting
-value      string          Yes          The value of the setting
-========== =============== ============ ======================================================================================================
-
-Events
-~~~~~~
-
-The event `wizard-visible` is fired when the wizard rendering has finished.
-
-Example code:
-
-.. code-block:: js
-
-        Wizard.getComponent().on('wizard-visible', function() {
-            Wizard.unlockNextButton();
-        });
-
-
-Wizards can be closed by firing the `wizard-dismiss` event.
-
-Example code:
-
-.. code-block:: js
-
-        Wizard.getComponent().trigger('wizard-dismiss');
-
-
-Wizards fire the `wizard-dismissed` event if the wizard is closed. You can integrate your own listener by using :js:`Wizard.getComponent()`.
-
-Example code:
-
-.. code-block:: js
-
-        Wizard.getComponent().on('wizard-dismissed', function() {
-            // Calculate the answer of life the universe and everything
-        });
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-73720-TriggerEventAfterModalWindowDismissed.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-73720-TriggerEventAfterModalWindowDismissed.rst
deleted file mode 100644 (file)
index 3fb1a48..0000000
+++ /dev/null
@@ -1,24 +0,0 @@
-============================================================
-Feature: #73720 - Trigger event after modal window dismissed
-============================================================
-
-Description
-===========
-
-A new event ``modal-destroyed`` has been added that will be triggered after a modal window closed.
-
-
-Impact
-======
-
-Bind to the event ``modal-destroyed`` to achieve custom actions after the modal dismissed.
-
-Example code:
-
-.. code-block:: javascript
-
-       var $modal = Modal.confirm(); // stub code
-       $modal.on('modal-destroyed', function() {
-               // Reset the selection
-               $someCombobox.val('');
-       });
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-73752-AllowAccessingObjectStorageAsArrayInFluidAndOtherPlaces.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-73752-AllowAccessingObjectStorageAsArrayInFluidAndOtherPlaces.rst
deleted file mode 100644 (file)
index 6c205f1..0000000
+++ /dev/null
@@ -1,23 +0,0 @@
-==================================================================================
-Feature: #73752 - Allow accessing ObjectStorage as array in Fluid and other places
-==================================================================================
-
-Description
-===========
-
-Creates an alias of "toArray()" allowing the method to be called as "getArray()" which in turn allows the method to be
-called transparently from ObjectAccess::getPropertyPath, enabling access in Fluid and other places.
-
-
-Impact
-======
-
-By creating an extremely simple aliasing of "toArray()" on ObjectStorage allowing it to be called as "getArray()" enables:
-
-.. code-block:: php
-
-       ObjectAccess::getPropertyPath($subject, 'objectstorageproperty.array.4') to get the 4th element
-
-.. code-block:: text
-
-       {myObject.objectstorageproperty.array.4} in Fluid (including {myObject.objectstorageproperty.array.{dynamicIndex}} in v8)
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-74038-ReportForCheckingDatabaseCharacterSet.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-74038-ReportForCheckingDatabaseCharacterSet.rst
deleted file mode 100644 (file)
index a61212f..0000000
+++ /dev/null
@@ -1,15 +0,0 @@
-============================================================
-Feature: #74038 - Report for checking database character set
-============================================================
-
-Description
-===========
-
-If a database has e.g. latin1 as default character set, new tables or fields created by TYPO3 will be created
-with this default charset as utf-8 is not enforced.
-A report has been added that checks the default charset and warns administrators if a wrong charset is used.
-
-Impact
-======
-
-If the default database character set is not utf-8, the report warns administrators about a wrong charset.
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-74109-SetTheAlternativeBackendLogoViaExtensionManager.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-74109-SetTheAlternativeBackendLogoViaExtensionManager.rst
deleted file mode 100644 (file)
index 6ce1b16..0000000
+++ /dev/null
@@ -1,17 +0,0 @@
-========================================================================
-Feature: #74109 - Set the alternative Backend Logo via Extension Manager
-========================================================================
-
-Description
-===========
-
-The Backend Logo in the upper left corner can now be configured in the Extension Configuration of EXT:backend
-within the Extension Manager. A relative path to the TYPO3 installation ("PATH_site"), e.g. "fileadmin/myfile.jpg"
-or a path to an extension, e.g. "EXT:my_theme/Resources/Public/Icons/Logo.png" can be configured there.
-
-The configuration option within the Backend extension (EXT:backend) is called ``backendLogo``.
-
-Impact
-======
-
-The previously available ``$GLOBALS[TBE_STYLES][logo]`` option has no effect anymore.
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-74179-PageModuleDragDropCanDoCopiesViaCTRLKeyNow.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-74179-PageModuleDragDropCanDoCopiesViaCTRLKeyNow.rst
deleted file mode 100644 (file)
index 2835974..0000000
+++ /dev/null
@@ -1,8 +0,0 @@
-========================================================================
-Feature: #74179 - Page Module Drag & Drop Can Do Copies Via CTRL Key Now
-========================================================================
-
-Description
-===========
-
-Additionally to the usual drag  and drop in the page module, that was able to move content elements from position A to B, you can do copies via drag & drop now. Just press the CTRL-key while dropping to create a copy of the dragged element at the drop zone position. After dropping is finished the page module will reload to make sure the new element will be generated with all necessary information.
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Feature-74319-CheckDefaultDatabaseCharacterSetDuringInstallationAndProvideUpdateWizardForFixingDefaultCharacterSetOtherThanUtf-8.rst b/typo3/sysext/core/Documentation/Changelog/master/Feature-74319-CheckDefaultDatabaseCharacterSetDuringInstallationAndProvideUpdateWizardForFixingDefaultCharacterSetOtherThanUtf-8.rst
deleted file mode 100644 (file)
index 03bb219..0000000
+++ /dev/null
@@ -1,21 +0,0 @@
-======================================================================================================================================================
-Feature: #74319 - check default database character set during Installation and provide Update wizard for fixing default character set other than utf-8
-======================================================================================================================================================
-
-
-Description
-===========
-
-If you install TYPO3 to an existing database with a default charset other than utf-8, TYPO3 will create tables with the default charset of that database.
-The install tool should check the default charset and notify the user if it is not utf-8.
-
-Furthermore the install tool should check for this issue too and provide an update wizard to fix this (=set the default charset to utf-8 and NOT convert existing tables to utf-8).
-A default charset set other than utf-8 leads to non-utf-8 tables when updating the database via the install tool or installing extensions.
-
-
-Impact
-======
-
-During installation on database select the default charset of the database is checked. If it is not utf-8 the installation will not proceed and the user is notified of the issue.
-
-For existing installations the install tool also provides an environment check and an upgrade wizard which changes the default database character set. The update wizard will NOT convert any existing tables though!
\ No newline at end of file
diff --git a/typo3/sysext/core/Documentation/Changelog/master/Important-70849-MakeSearchLevelsConsistent.rst b/typo3/sysext/core/Documentation/Changelog/master/Important-70849-MakeSearchLevelsConsistent.rst
deleted file mode 100644 (file)
index aebec6f..0000000
+++ /dev/null
@@ -1,22 +0,0 @@
-================================================================================
-Important: #70849 - Make search levels in live search and list search consistent
-================================================================================
-
-Description
-===========
-
-In order to make the searchlevel handling consistent between live and list search a new PageTS option has been added.
-
-.. code-block:: typoscript
-
-       mod.web_list.searchLevel.items {
-               -1 = EXT:lang/locallang_core.xlf:labels.searchLevel.infinite
-               0 = EXT:lang/locallang_core.xlf:labels.searchLevel.0
-               1 = EXT:lang/locallang_core.xlf:labels.searchLevel.1
-               2 = EXT:lang/locallang_core.xlf:labels.searchLevel.2
-               3 = EXT:lang/locallang_core.xlf:labels.searchLevel.3
-               4 = EXT:lang/locallang_core.xlf:labels.searchLevel.4
-       }
-
-This makes it possible to add custom search level entries.
-