Commit 3b03ef46 authored by Anja Leichsenring's avatar Anja Leichsenring Committed by Christian Kuhn
Browse files

[TASK] Move Changelog files into 11.0 folder for upcoming release

Resolves: #93104
Releases: master
Change-Id: I06ca0cf5886e5f880aff553c21c7e008f2f49492
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67182

Tested-by: default avatarTYPO3com <noreply@typo3.com>
Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
parent e162e46a
:orphan:
.. include:: Includes.txt
=============
ChangeLog v11
=============
Every change to the TYPO3 Core which might affect your site is documented here.
.. toctree::
:titlesonly:
Changelog/11.0/Index
......@@ -9,30 +9,31 @@ See :issue:`23736`
Description
===========
TYPO3's Frontend Request Process previously needed a parsed TypoScript before doing the language overlay of the currently
visited page, as previous TYPO3 sites without Site Handling
Previous TYPO3 sites without Site Handling
used TypoScript conditions like `[globalVar = GP:L = 1]` to switch
between languages.
between languages. For this, TYPO3's Frontend Request Process needed a parsed TypoScript before
doing the language overlay of the currently visited page.
This made it impossible to use conditions for accessing the translated page record like `[page["nav_title"] == "Bienvenue"]`,
which was a long outstanding conceptual issue that was finally
made possible through Site Handling.
which was a long outstanding conceptual issue that was finally made possible through Site Handling.
For this reason, the translated page is now resolved directly after the actual page and rootline resolving.
Now, the translated page is resolved directly after the actual page and rootline resolving.
Impact
======
The translated page record (based on the fallback handling in the
Site Configuration) is now available in :php:`$TSFE->page` at a much earlier stage of the Frontend process.
Site Configuration) is now available in :php:`$TSFE->page` at a much earlier stage of the Frontend Request process.
This means, TypoScript conditions based on the page record (see example above) might be different.
In addition, the two hooks
In addition, the two hooks
:php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['settingLanguage_preProcess']` and
:php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['settingLanguage_postProcess']` are
called now earlier when no TypoScript is available yet.
:php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['settingLanguage_postProcess']`
are called earlier, no TypoScript is available yet.
Affected Installations
......@@ -51,6 +52,6 @@ initialized.
Also, be sure to review any of the TypoScript conditions (possible
via the `Web->Template` module) if they are related to values only
available in the default language, which seems to be a very case however.
available in the default language, which seems to be a very rare case however.
.. index:: PHP-API, TypoScript, NotScanned, ext:frontend
\ No newline at end of file
.. index:: PHP-API, TypoScript, NotScanned, ext:frontend
.. include:: ../../Includes.txt
========================================
Breaking: #29342 - Improve ValidatorTask
========================================
=========================================================
Breaking: #29342 - Fluid Email Template for ValidatorTask
=========================================================
See :issue:`29342`
Description
===========
In TYPO3 version 10 `ext:linkvalidator` has been improved a lot. The
:php:`\TYPO3\CMS\Linkvalidator\Task\ValidatorTask` - a scheduler task for reporting
broken links via email has been refactored now.
In TYPO3 v10 `ext:linkvalidator` has been improved a lot. The
:php:`\TYPO3\CMS\Linkvalidator\Task\ValidatorTask`, a scheduler task for reporting
broken links via email, has been refactored now.
The old marker templates have been replaced by `FluidEmail`. A Fluid template is now
The old marker template has been replaced by Fluid templates, which are now
used for generating the report email. The marker template has been removed completely
along with corresponding functionality.
......@@ -38,7 +38,7 @@ Impact
======
It is no longer possible to set a custom marker based template file with
`emailTemplateFile`. Instead, the new field `emailTemplateName` can be used to
:php:`emailTemplateFile`. Instead, the new field :php:`emailTemplateName` can be used to
specify a Fluid template file, see Migration section below.
......@@ -47,23 +47,18 @@ Affected Installations
All installations which use:
* the task by providing a custom template file.
* one of the hooks mentioned above.
* the scheduler task and provide a custom template file
* one of the hooks mentioned above
Migration
=========
If you currently don't use a custom template or one of the hooks mentioned above,
you don't need to migrate anything.
Otherwiese you have to provide your custom templates using the new field
`emailTemplateName` in the task configuration and adding your custom template
Provide your custom templates using the new field :php:`emailTemplateName`
in the scheduler task configuration and add your custom template
path to :php:`$GLOBALS['TYPO3_CONF_VARS']['MAIL']['templateRootPaths']`.
Furthermore use the new PSR-14 event
:php:`\TYPO3\CMS\Linkvalidator\Event\ModifyValidatorTaskEmailEvent` to adjust the
:php:`\TYPO3\CMS\Linkvalidator\Result\LinkAnalyzerResult` along with the `FluidEmail`
object.
Use the new PSR-14 event :php:`\TYPO3\CMS\Linkvalidator\Event\ModifyValidatorTaskEmailEvent` to adjust the
:php:`\TYPO3\CMS\Linkvalidator\Result\LinkAnalyzerResult` along with the `FluidEmail` object.
.. index:: Backend, CLI, NotScanned, ext:linkvalidator
......@@ -9,7 +9,7 @@ See :issue:`45512`
Description
===========
It is recommended for `<style>` and `<link>` HTML tags
It is recommended for :html:`<style>` and :html:`<link>` HTML tags
to not use the "type" attribute anymore.
These references state its recommended practice to omit them:
......@@ -23,13 +23,13 @@ HTML elements anymore when rendering HTML.
Impact
======
The attribute `type` is removed from the HTML tags `<style>` and `<link>`
The attribute :html:`type` is removed from the HTML tags :html:`<style>` and :html:`<link>`
by default for TYPO3 Backend and Frontend output.
Affected Installations
======================
All installations of TYPO3 that use `<style>` or `<link>` tags are affected.
All installations of TYPO3 that use :html:`<style>` or :html:`<link>` tags are affected.
The probability this has negative impact on the user experience is low, however.
......
......@@ -9,11 +9,11 @@ See :issue:`79565`
Description
===========
The database field `be_users.usergroup_cached_list` has been
The database field :sql:`be_users.usergroup_cached_list` has been
removed. It was populated by a list of all groups (including
subgroups) the user belongs to, and stored when a user logged in,
but was never updated when an admin added or removed a group
from the users' group list.
subgroups) the user belongs to, and stored when a user logged in.
The field however was never updated when an admin added or removed a group
from the users group list.
Impact
......@@ -33,6 +33,6 @@ with third-party extensions.
Migration
=========
Use the GroupResolver class to fetch all groups of a user directly.
Use the class :php:`GroupResolver` to fetch all groups of a user directly.
.. index:: Backend, PHP-API, NotScanned, ext:core
\ No newline at end of file
.. index:: Backend, PHP-API, NotScanned, ext:core
.. include:: ../../Includes.txt
=======================================================================
Breaking: #89137 - Database fields t3ver_tstamp and t3ver_count dropped
Breaking: #89137 - Database fields t3ver_tstamp and t3ver_count removed
=======================================================================
See :issue:`89137`
......@@ -9,15 +9,16 @@ See :issue:`89137`
Description
===========
The two workspace related database fields :sql:`t3ver_tstamp` and :sql:`t3ver_count` together
with their handling have been dropped from all workspace aware database tables.
The two workspace related database fields :sql:`t3ver_tstamp` and :sql:`t3ver_count`
have been dropped from all workspace aware database tables. Also, all code handling these
fields has been removed from the code base.
Impact
======
The core did not show these fields to the user. It's very unlikely extensions made use of these
fields. Admins upgrading to core v11 can usually assume zero impact for their site functionality.
The core did not show these fields to the user. It's very unlikely extensions made use of them.
Admins upgrading to TYPO3 v11 can usually assume zero impact for their site functionality.
Affected Installations
......
......@@ -9,17 +9,17 @@ See :issue:`90799`
Description
===========
In TYPO3 9.5, the (dependency) injection via `@inject` has been deprecated for
non public properties. The reason was to avoid having the core use the PHP reflection
api to make non public properties writable from outside the class scope. Since there
In TYPO3 v9, the (dependency) injection via :php:`@Inject` has been marked as deprecated for
non-public properties. The reason was to avoid having the core use the PHP reflection
api to make non-public properties writable from outside the class scope. Since there
are other methods for dependency injection (constructor/setter injection), injection
into non public properties has now been removed
into non-public properties has now been removed.
Impact
======
Non public properties with inject annotations will no longer trigger extbase
Non-public properties with :php:`@Inject` annotations will no longer trigger extbase
dependency injection. Those properties will have their default state after object
instantiation.
......@@ -27,7 +27,7 @@ instantiation.
Affected Installations
======================
All installations that use non public properties for extbase dependency injection
All installations that use non-public properties for extbase dependency injection
as seen in this example:
.. code-block:: php
......@@ -46,8 +46,8 @@ Migration
=========
When not using constructor/setter injection instead, switch to inject methods
(recommended for compatibility with symfony depenency injection) or mark the
property public (works with extbase depenency injection only):
(recommended for compatibility with symfony dependency injection) or mark the
property public (works with extbase dependency injection only):
.. code-block:: php
......
......@@ -9,7 +9,7 @@ See :issue:`91473`
Description
===========
The following PHP classes that have been previously deprecated for v10 have been removed:
The following PHP classes that have previously been marked as deprecated for v10 and were now removed:
- :php:`\TYPO3\CMS\Backend\Configuration\TsConfigParser`
- :php:`\TYPO3\CMS\Backend\Controller\File\CreateFolderController`
......@@ -39,7 +39,7 @@ The following PHP classes that have been previously deprecated for v10 have been
- :php:`\TYPO3\CMS\Fluid\ViewHelpers\Widget\AutocompleteViewHelper`
- :php:`\TYPO3\CMS\Fluid\ViewHelpers\Widget\Controller\AutocompleteController`
The following PHP interfaces that have been previously deprecated for v10 have been removed:
The following PHP interfaces that have previously been marked as deprecated for v10 and were now removed:
- :php:`\TYPO3\CMS\Adminpanel\ModuleApi\InitializableInterface`
- :php:`\TYPO3\CMS\Core\Console\RequestHandlerInterface`
......@@ -47,7 +47,7 @@ The following PHP interfaces that have been previously deprecated for v10 have b
- :php:`\TYPO3\CMS\Core\Routing\Aspect\DelegateInterface`
- :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectGetSingleHookInterface`
The following PHP class aliases that have been previously deprecated for v10 have been removed:
The following PHP class aliases that have previously been marked as deprecated for v10 and were now removed:
* :php:`TYPO3\CMS\Frontend\Page\PageRepository`
* :php:`TYPO3\CMS\Frontend\Page\PageRepositoryGetPageHookInterface`
......@@ -56,7 +56,7 @@ The following PHP class aliases that have been previously deprecated for v10 hav
* :php:`TYPO3\CMS\Frontend\Page\PageRepositoryInitHookInterface`
* :php:`TYPO3\CMS\Lowlevel\Utility\ArrayBrowser`
The following PHP class methods that have been previously deprecated for v10 have been removed:
The following PHP class methods that have previously been marked as deprecated for v10 and were now removed:
- :php:`\TYPO3\CMS\Backend\History\RecordHistory->createChangeLog`
- :php:`\TYPO3\CMS\Backend\History\RecordHistory->createMultipleDiff`
......@@ -96,7 +96,7 @@ The following PHP class methods that have been previously deprecated for v10 hav
- :php:`\TYPO3\CMS\Linkvalidator\Repository\BrokenLinkRepository->getNumberOfBrokenLinks`
The following PHP static class methods that have been previously deprecated for v10 have been removed:
The following PHP static class methods that have previously been marked as deprecated for v10 and were now removed:
- :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::getRawPagesTSconfig`
- :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::editOnClick`
......@@ -121,8 +121,6 @@ The following PHP static class methods that have been previously deprecated for
- :php:`\TYPO3\CMS\Extbase\Reflection\ObjectAccess::buildSetterMethodName`
- :php:`\TYPO3\CMS\Extbase\Utility\TypeHandlingUtility::hex2bin`
The following PHP methods have been additionally deprecated and are a no-op now:
The following methods changed signature according to previous deprecations in v10 at the end of the argument list:
- :php:`\TYPO3\CMS\Core\Database\ReferenceIndex->updateIndex` (argument 2 is now either null or ProgressListenerInterface, not boolean anymore)
......@@ -177,10 +175,6 @@ The following ViewHelpers have changed:
- :html:`<f:widget.uri>` ViewHelper argument "useCacheHash" is dropped
- :html:`<f:widget.autocomplete>` ViewHelper is removed
The following scheduler tasks have been removed:
The following user TSconfig options have been dropped:
The following TypoScript options have been dropped:
- Extbase TypoScript option `requireCHashArgumentForActionArguments` for any plugin
......@@ -242,14 +236,10 @@ The following class constants have been dropped:
- :php:`\TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_GetDataArray_PostProcesss`
- :php:`\TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_SortDataArray_PostProcesss`
The following class constants have been set to protected:
The following global options are ignored:
- :php:`$GLOBALS['TYPO3_CONF_VARS']['EXT']['runtimeActivatedPackages']`
The following language files and aliases have been removed:
The following global variables have been removed:
- :php:`$GLOBALS['LOCAL_LANG']`
......@@ -274,8 +264,6 @@ The following hooks have been removed:
- :php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['password_changed']`
- :php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['postProcContent']`
The following hooks don't pass the class reference anymore:
The following signals have been removed:
- :php:`PackageManagement::packagesMayHaveChanged`
......@@ -360,13 +348,10 @@ The following features have been removed:
- Pi-based plugin for "felogin" (CType `login`)
- XML-based (TYPO3-custom XML format) label parsing
The following database tables have been removed:
- :sql:`sys_template.sitetitle`
The following database fields have been removed:
- pages.legacy_overlay_uid
- :sql:`sys_template.sitetitle`
- :sql:`pages.legacy_overlay_uid`
The following Backend route identifiers have been removed:
......@@ -395,8 +380,6 @@ The following JavaScript modules have been removed:
- :js:`jquery.clearable`
- :js:`md5`
The following global instances have been removed:
Impact
======
......
......@@ -9,17 +9,17 @@ See :issue:`91562`
Description
===========
The cObject `TEMPLATE`, used for rendering marker-based templates
The cObject :typoscript:`TEMPLATE`, used for rendering marker-based templates
has been removed along with the PHP class :php:`TYPO3\CMS\Frontend\ContentObject\TemplateContentObject`.
The successor `FLUIDTEMPLATE` is widely used since TYPO3 v7,
The successor :typoscript:`FLUIDTEMPLATE` is widely used since TYPO3 v7,
and acts as a replacement for marker-based templates.
Impact
======
Using TypoScript with `page.10 = TEMPLATE` will result in a PHP
Using TypoScript with :typoscript:`page.10 = TEMPLATE` will result in a PHP
error when rendering the frontend.
Referencing the PHP class will result in a fatal PHP error.
......@@ -28,16 +28,19 @@ Referencing the PHP class will result in a fatal PHP error.
Affected Installations
======================
TYPO3 installation still using `TEMPLATE` cObject in their TypoScript.
TYPO3 installation still using :typoscript:`TEMPLATE` cObject in their TypoScript.
Migration
=========
Install the extension `modern_template_building` from the official
TYPO3 Extension Repository at https://extensions.typo3.org/, which acts as a drop-in replacement, and also ships the cObject `FILE`
which is highly useful for `TEMPLATE` cObjects.
Refactor TypoScript templates to not use the cObject :typoscript:`TEMPLATE` anymore.
In case you can not or want not make the switch to :typoscript:`FLUIDTEMPLATE`, install
the extension `modern_template_building` from the official
TYPO3 Extension Repository at https://extensions.typo3.org/, which acts as a drop-in replacement, and also ships the cObject :typoscript:`FILE`
which is highly useful for :typoscript:`TEMPLATE` cObjects.
The extension is compatible with TYPO3 v9+.
.. index:: TypoScript, FullyScanned, ext:frontend
\ No newline at end of file
.. index:: TypoScript, FullyScanned, ext:frontend
......@@ -9,7 +9,7 @@ See :issue:`91563`
Description
===========
In the past, TYPO3's "TSFE" object allowed to manually add CSS or JavaScript snippets via PHP code via the following method and properties:
In the past, TYPO3's :php:`TSFE` object allowed to manually add CSS or JavaScript snippets via PHP code with the following method and properties:
* :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->setJS()`
* :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->additionalJavaScript`
......@@ -17,13 +17,13 @@ In the past, TYPO3's "TSFE" object allowed to manually add CSS or JavaScript sni
* :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->JSCode`
* :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->inlineJS`
These have been removed due to better APIs like PageRenderer (available since TYPO3 v4.5) and AssetCollector (TYPO3 v10).
These have been removed due to better APIs like :php:`PageRenderer` (available since TYPO3 v4.5) and :php:`AssetCollector` (available since TYPO3 v10).
Impact
======
Accessing the method and properties will have no effect and trigger a PHP notice.
Accessing the method and properties will have no effect and trigger PHP errors.
Affected Installations
......@@ -35,6 +35,6 @@ TYPO3 installations with custom extensions using this functionality directly to
Migration
=========
Use the AssetCollector API in PHP to add JavaScript and CSS code or use files directly.
Use the :php:`AssetCollector` API in PHP to add JavaScript and CSS code or use files directly.
.. index:: PHP-API, FullyScanned, ext:frontend
......@@ -10,8 +10,8 @@ Description
===========
The JavaScript functions :js:`TBE_EDITOR.fieldChanged_fName` and its legacy
alias :js:`TBE_EDITOR_fieldChanged_fName` used to extract the table name, field
name and uid from the incoming field name have been removed.
alias :js:`TBE_EDITOR_fieldChanged_fName`, used to extract the table name, field
name and uid from the incoming field name, have been removed.
Impact
......
......@@ -9,7 +9,7 @@ See :issue:`91606`
Description
===========
FormEngine supported to add or subtract a date or time range (depends on the
FormEngine supported to add or subtract a date or time range (depending on the
field type) by appending e.g. `+5` or `-42` to the field values. These kind of
operations have been removed as they are rather unknown and clumsy to use.
......
......@@ -9,16 +9,19 @@ See :issue:`91782`
Description
===========
TYPO3 Core shipped with a feature called "lockToDomain" for Frontend users and backend users which made the user login only valid if the exact given HTTP_HOST matches the filled domain.
TYPO3 Core shipped with a feature called "lockToDomain" for frontend and backend users which made the user login only valid if
the exact given HTTP_HOST matches the filled domain.
A similar functionality, but with the same name for groups existed, which only added the group to a specific user during a session, if the user was accessing a TYPO3 site under a specific domain.
A similar functionality with the same name for groups existed, which only added the group to a specific user during a session,
if the user was accessing a TYPO3 site under a specific domain.
Both features have been removed.
Impact
======
Frontend users or backend users that have this option set previously, will now be able to login independent of the defined HTTP_HOST header sent with the login page.
Frontend users or backend users that have this option set previously, will now be able to login independent of the defined HTTP_HOST
header sent with the login page.
Regardless of any setting of the "lockToDomain" setting of a specific group, all groups added
to a user are now applied during login of a user, both for frontend and backend.
......@@ -27,31 +30,32 @@ to a user are now applied during login of a user, both for frontend and backend.
Affected Installations
======================
TYPO3 Installations using this feature in their database records. When in doubt, this can be identified by running SQL SELECT statements to identify users actively using this feature.
TYPO3 Installations using this feature in their database records are affected. Following SQL SELECT statements help to identify records
with a value for the features, which indicates those users and groups will now be able to log in without the domain restriction.
Frontend Users:
.. code-block:: sql
SELECT uid, pid, username FROM fe_users WHERE lockToDomain != '' AND lockToDomain IS NOT NULL;
SELECT uid, pid, username FROM fe_users WHERE lockToDomain != '' AND lockToDomain IS NOT NULL;
Backend Users:
.. code-block:: sql
SELECT uid, pid, username FROM be_users WHERE lockToDomain != '' AND lockToDomain IS NOT NULL;"
SELECT uid, pid, username FROM be_users WHERE lockToDomain != '' AND lockToDomain IS NOT NULL;
Frontend Groups:
.. code-block:: sql
SELECT uid, pid, username FROM fe_groups WHERE lockToDomain != '' AND lockToDomain IS NOT NULL;
SELECT uid, pid, username FROM fe_groups WHERE lockToDomain != '' AND lockToDomain IS NOT NULL;
Backend Groups:
.. code-block:: sql
SELECT uid, pid, username FROM be_groups WHERE lockToDomain != '' AND lockToDomain IS NOT NULL;
SELECT uid, pid, username FROM be_groups WHERE lockToDomain != '' AND lockToDomain IS NOT NULL;
Migration
......
......@@ -10,7 +10,7 @@ Description
===========
The TCA field :php:`['tableName']['ctrl']['transOrigDiffSourceField']` - often set to
php:`l18n_diffsource` - stores the state of the source language record a translated
:php:`l18n_diffsource` - stores the state of the source language record a translated
record has been created from. This is used if content in the source language
of a record has been changed to hint editors for a potentially needed update
of the translated record.
......
......@@ -9,7 +9,7 @@ See :issue:`91909`
Description
===========
The generic :sql:`sys_collection` database table and its MM table which
The generic :sql:`sys_collection` database table and its MM table :sql:`sys_collection_entries`, which
holds information of connected records to a "Record Collection" have
been removed from TYPO3 Core.
......@@ -33,7 +33,7 @@ Impact
It is not possible to modify / edit :sql:`sys_collection` records anymore in the TYPO3 Backend.
The database tables are not defined anymore, so is the TCA definition.
The database tables are not defined anymore, neither is the TCA definition.
Accessing the PHP API class will result in fatal PHP errors.
......@@ -41,7 +41,7 @@ Accessing the PHP API class will result in fatal PHP errors.
Affected Installations
======================
Any TYPO3 installation using the database tables :sql:`sys_collection`
Any TYPO3 installation using the database tables belonging to the :sql:`sys_collection` feature
which is very unlikely.
......
......@@ -15,30 +15,28 @@ groups to users visiting the TYPO3 Frontend from specific IP addresses / network
This is especially handy to show content only in Intranet/Extranet
sites where internal members see restricted content automatically.
However, showing content based on certain contexts, are usually solved with a much more flexible way through third-party extensions
However, showing content based on certain contexts is usually solved with a much more flexible way through third-party extensions
such as EXT:contexts. Third-party extensions allow even for automatic login based on IP-addresses, which should be used instead.
Impact
======
The mentioned option is automatically removed from LocalConfiguration.php
on upgrade, and never evaluated anymore.
The mentioned option is automatically removed from :file:`LocalConfiguration.php`
on upgrade, and not evaluated anymore.
Affected Installations
======================