TYPO3 v15 dev-main snapshot ()
This commit is contained in:
+69
@@ -0,0 +1,69 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-90728:
|
||||
|
||||
=================================================================
|
||||
Feature: #90728 - Add FluidEmail option to EXT:form EmailFinisher
|
||||
=================================================================
|
||||
|
||||
See :issue:`90728`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
After the introduction of FluidEmail in v10 the option to send mails in a
|
||||
standardized way is now also added to the EmailFinisher of the system extension
|
||||
EXT:from.
|
||||
|
||||
To use FluidEmail a new option `useFluidEmail` is added to both the EmailToReceiver
|
||||
and EmailToSender finisher. It defaults to :php:`FALSE` so extension authors are
|
||||
able to smoothly test and upgrade their forms. Furthermore a new option `title`
|
||||
is available which can be used to add an E-Mail title to the default FluidEmail
|
||||
template. This option is capable of rendering form element variables using the
|
||||
known bracket syntax and can be overwritten in the FlexForm configuration of the
|
||||
form plugin.
|
||||
|
||||
To customize the templates being used, the following options can be set:
|
||||
|
||||
* `templateName`: The template name (for both HTML and plaintext) without the extension
|
||||
* `templateRootPaths`: The paths to the templates
|
||||
* `partialRootPaths`: The paths to the partials
|
||||
* `layoutRootPaths`: The paths to the layouts
|
||||
|
||||
For FluidEmail, the field `templatePathAndFilename` is not evaluated anymore.
|
||||
|
||||
A finisher configuration could look like this:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
identifier: contact
|
||||
type: Form
|
||||
prototypeName: standard
|
||||
finishers:
|
||||
-
|
||||
identifier: EmailToSender
|
||||
options:
|
||||
subject: 'Your Message: {message}'
|
||||
title: 'Hello {name}, your confirmation'
|
||||
templateName: ContactForm
|
||||
templateRootPaths:
|
||||
100: 'EXT:sitepackage/Resources/Private/Templates/Email/'
|
||||
partialRootPaths:
|
||||
100: 'EXT:sitepackage/Resources/Private/Partials/Email/'
|
||||
addHtmlPart: true
|
||||
useFluidEmail: true
|
||||
|
||||
Please note that the old template name syntax `{@format}.html` does not work for
|
||||
FluidEmail as each format needs a different template with the corresponding file
|
||||
extension. In the example above the following files must exist in the specified
|
||||
template path:
|
||||
|
||||
* `ContactForm.html`
|
||||
* `ContactForm.txt`
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
It's now possible to use FluidEmail for sending mails in EXT:form.
|
||||
|
||||
.. index:: Fluid, Frontend, ext:form
|
||||
+82
@@ -0,0 +1,82 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-91132:
|
||||
|
||||
==================================================================
|
||||
Feature: #91132 - Introduce User Settings JavaScript Modules Event
|
||||
==================================================================
|
||||
|
||||
See :issue:`91132`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
JavaScript events in custom User Settings Configuration options shall
|
||||
not be placed as inline JavaScript anymore, but utilize a dedicated
|
||||
JavaScript module to handle custom events
|
||||
(see :doc:`Important-91132-AvoidJavaScriptInUserSettingsConfigurationOptions`)
|
||||
|
||||
This new PSR-14 event is introduced:
|
||||
|
||||
* :php:`\TYPO3\CMS\SetupEvent\AddJavaScriptModulesEvent`
|
||||
|
||||
These public methods are exposed:
|
||||
|
||||
* :php:`public function addModule(string $moduleName): void`
|
||||
* :php:`public function getModules(): array`
|
||||
|
||||
:php:`$moduleName` refers to the JavaScript module to be loaded with RequireJS
|
||||
(e.g. `TYPO3/CMS/MyExtension/CustomUserSettingsModule`).
|
||||
|
||||
|
||||
Example
|
||||
=======
|
||||
|
||||
A listener using mentioned PSR-14 event could look like the following.
|
||||
|
||||
.. rst-class:: bignums
|
||||
|
||||
1. Register listener
|
||||
|
||||
:file:`typo3conf/my-extension/Configuration/Services.yaml`
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
services:
|
||||
MyVendor\MyExtension\EventListener\CustomUserSettingsListener:
|
||||
tags:
|
||||
- name: event.listener
|
||||
identifier: 'myExtension/CustomUserSettingsListener'
|
||||
event: TYPO3\CMS\SetupEvent\AddJavaScriptModulesEvent
|
||||
|
||||
|
||||
2. Implement Listener to load JavaScript module `TYPO3/CMS/MyExtension/CustomUserSettingsModule`
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
namespace MyVendor\MyExtension\EventListener;
|
||||
|
||||
use TYPO3\CMS\SetupEvent\AddJavaScriptModulesEvent;
|
||||
|
||||
class CustomUserSettingsListener
|
||||
{
|
||||
// name of JavaScript module to be loaded
|
||||
private const MODULE_NAME = 'TYPO3/CMS/MyExtension/CustomUserSettingsModule';
|
||||
|
||||
public function __invoke(AddJavaScriptModulesEvent $event): void
|
||||
{
|
||||
$javaScriptModuleName = 'TYPO3/CMS/MyExtension/CustomUserSettings';
|
||||
if (in_array(self::MODULE_NAME, $event->getModules(), true)) {
|
||||
return;
|
||||
}
|
||||
$event->addModule(self::MODULE_NAME);
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
Related
|
||||
=======
|
||||
|
||||
- :doc:`Important-91132-AvoidJavaScriptInUserSettingsConfigurationOptions`
|
||||
|
||||
.. index:: PHP-API, ext:core
|
||||
@@ -0,0 +1,34 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _important-73227:
|
||||
|
||||
=====================================================
|
||||
Important: #73227 - TSconfig option altIcons restored
|
||||
=====================================================
|
||||
|
||||
See :issue:`73227`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The TSconfig option :typoscript:`altIcons`, introduced in :issue:`35891`,
|
||||
allowed to add / override icons for TCA select items. This option was then
|
||||
accidentally removed without further notice, while reworking the FormEngine.
|
||||
|
||||
Therefore and because it's sometimes necessary to use different icons for
|
||||
already defined select items - depending on the current page or site context -
|
||||
the option is restored.
|
||||
|
||||
The usage is as following:
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
TCEFORM.pages.doktype.altIcons {
|
||||
1 = custom-icon-identifier
|
||||
2 = EXT:my_ext/path/to/icon.svg
|
||||
}
|
||||
|
||||
For more information you can also have a look at the initial
|
||||
:doc:`changelog <../7.1/Feature-35891-AddTCAItemsWithIconsViaPageTSConfig>`.
|
||||
|
||||
.. index:: Backend, TSConfig, ext:backend
|
||||
@@ -0,0 +1,26 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _important-88824-1668719172:
|
||||
|
||||
=====================================================
|
||||
Important: #88824 - Add cache for error page handling
|
||||
=====================================================
|
||||
|
||||
See :issue:`88824`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
In order to prevent possible DoS attacks when the page-based error handler
|
||||
is used, the content of the 404 error page is now cached in the TYPO3
|
||||
page cache. Any dynamic content on the error page (e.g. content created
|
||||
by TypoScript or uncached plugins) will therefore also be cached.
|
||||
|
||||
If the 404 error page contains dynamic content, TYPO3 administrators must
|
||||
ensure that no sensitive data (e.g. username of logged in frontend user)
|
||||
will be shown on the error page.
|
||||
|
||||
If dynamic content is required on the 404 error page, it is recommended
|
||||
to implement a custom PHP based error handler.
|
||||
|
||||
.. index:: Backend, ext:backend
|
||||
+31
@@ -0,0 +1,31 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _important-91070:
|
||||
|
||||
=====================================================================================
|
||||
Important: #91070 - SMTP transport option 'transport_smtp_encrypt' changed to boolean
|
||||
=====================================================================================
|
||||
|
||||
See :issue:`91070`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
With https://forge.typo3.org/issues/90295 the allowed value for
|
||||
:php:`$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport_smtp_encrypt']` has been
|
||||
changed to a boolean value.
|
||||
|
||||
symfony/mailer does no longer allow to specify the `STARTTLS` usage, as it will
|
||||
be used by default (if the server provides the needed support).
|
||||
|
||||
Therefore, the SMTP encryption configuration setting
|
||||
:php:`$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport_smtp_encrypt']` is
|
||||
automatically updated by the install tool's silent configuration upgrade.
|
||||
|
||||
The configuration value `(string)tls` is removed to reflect that symfony/mailer
|
||||
expects `(bool)false` for `STARTTLS`. Other values like `(string)ssl` are
|
||||
converted too `(bool)true`.
|
||||
|
||||
No migration is needed at all, as no deprecation is thrown.
|
||||
|
||||
.. index:: LocalConfiguration, ext:core
|
||||
+89
@@ -0,0 +1,89 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _important-91117:
|
||||
|
||||
====================================================================================
|
||||
Important: #91117 - Use GlobalEventHandler and ActionDispatcher instead of inline JS
|
||||
====================================================================================
|
||||
|
||||
See :issue:`91117`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
In order to reduce the amount of inline JavaScript (with the goal to pave the
|
||||
way towards stronger Content-Security-Policy assignments) lots of inline JavaScript
|
||||
code parts have been substituted by a declarative syntax - basically using HTML
|
||||
:html:`data-*` attributes.
|
||||
|
||||
The following list collects an overview of common JavaScript snippets and their
|
||||
corresponding substitute using modules :js:`TYPO3/CMS/Backend/GlobalEventHandler`
|
||||
and :js:`TYPO3/CMS/Backend/ActionDispatcher`.
|
||||
|
||||
|
||||
`TYPO3/CMS/Backend/GlobalEventHandler`
|
||||
--------------------------------------
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
<select onchange="window.location.href=this.options[this.selectedIndex].value;">'
|
||||
<!-- ... changed to ... -->
|
||||
<select data-global-event="change" data-action-navigate="$value">'
|
||||
|
||||
Navigates to URL once selected drop-down was changed
|
||||
(`$value` refers to selected value)
|
||||
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
<select value="0" name="depth"
|
||||
onchange="window.location.href='https://example.org/__VAL__'.replace(/__VAL__/, this.options[this.selectedIndex].value);">
|
||||
<!-- ... changed to ... -->
|
||||
<select value="0" name="depth" data-global-event="change"
|
||||
data-action-navigate="$data=~s/$value/" data-navigate-value="https://example.org/${value}">
|
||||
|
||||
Navigates to URL once selected drop-down was changed, including selected value
|
||||
(`$data` refers to value of :html:`data-navigate-value`, `$value` to selected value,
|
||||
`$data=~s/$value/` replaces literal `${value}` with selected value in `:html:`data-navigate-value`)
|
||||
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
<input type="checkbox" name="setting" onclick="window.location.href='/?setting='+(this.checked ? 1 : 0)">
|
||||
<!-- ... changed to ... -->
|
||||
<input type="checkbox" name="setting" value="1" data-empty-value="0"
|
||||
data-global-event="change" data-action-navigate="$data=~s/$value/">
|
||||
|
||||
Checkboxes used to send a particular value when being unchecked can be achieved by using
|
||||
:html:`data-empty-value="0"` - in case this attribute is omitted, an empty string `''` is sent.
|
||||
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
<input type="checkbox" onclick="document.getElementById('formIdentifier').submit();">
|
||||
<!-- ... changed to ... -->
|
||||
<input type="checkbox" data-global-event="change" data-action-submit="$form">
|
||||
<!-- ... or (using CSS selector) ... -->
|
||||
<input type="checkbox" data-global-event="change" data-action-submit="#formIdentifier">
|
||||
|
||||
Submits a form once a value has been changed
|
||||
(`$form` refers to paren form element, using CSS selectors like `#formIdentifier`
|
||||
is possible as well)
|
||||
|
||||
|
||||
`TYPO3/CMS/Backend/ActionDispatcher`
|
||||
------------------------------------
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
<a href="#" onclick="top.TYPO3.InfoWindow.showItem('tt_content', 123); return false;">
|
||||
<!-- ... changed to ... -->
|
||||
data-dispatch-action="TYPO3.InfoWindow.showItem" data-dispatch-args-list="be_users,123">
|
||||
<!-- ... or (using JSON arguments) ... -->
|
||||
data-dispatch-action="TYPO3.InfoWindow.showItem" data-dispatch-args="["tt_content",123]">
|
||||
|
||||
Invokes :js:`TYPO3.InfoWindow.showItem` module function to display details for a given
|
||||
record (of database table `tt_content`, having `uid=123` in the example above)
|
||||
|
||||
|
||||
.. index:: Backend, JavaScript, ext:backend
|
||||
+86
@@ -0,0 +1,86 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _important-91132:
|
||||
|
||||
===========================================================================
|
||||
Important: #91132 - Avoid JavaScript in User Settings Configuration options
|
||||
===========================================================================
|
||||
|
||||
See :issue:`91132`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
User Settings Configuration options for buttons `onClick` and `onClickLabels`
|
||||
(used to generate inline JavaScript `onclick` event) and `confirmData.jsCodeAfterOk`
|
||||
(used to execute a JavaScript callback in modal confirmations) should be omitted.
|
||||
|
||||
New options `clickData.eventName` and `conformationData.eventName` should be used
|
||||
containing an individual event name that has to be handled individually using a
|
||||
static JavaScript module.
|
||||
|
||||
This step is advised to reduce the amount of inline JavaScript code towards
|
||||
better support for Content-Security-Policy headers.
|
||||
|
||||
Applications having custom changes in :php:`$GLOBALS['TYPO3_USER_SETTINGS']`
|
||||
and using mentioned options `onClick*` or `confirmData.jsCodeAfterOk`.
|
||||
|
||||
The following example show a potential migration path to avoid inline JavaScript.
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$GLOBALS['TYPO3_USER_SETTINGS'] = [
|
||||
'columns' => [
|
||||
'customButton' => [
|
||||
'type' => 'button',
|
||||
'onClick' => 'alert("clicked the button")',
|
||||
'confirm' => true,
|
||||
'confirmData' => [
|
||||
'message' => 'Please confirm...',
|
||||
'jsCodeAfterOk' => 'alert("confirmed the modal dialog")',
|
||||
]
|
||||
],
|
||||
// ...
|
||||
|
||||
The above configuration can be replace by the following.
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$GLOBALS['TYPO3_USER_SETTINGS'] = [
|
||||
'columns' => [
|
||||
'customButton' => [
|
||||
'type' => 'button',
|
||||
'clickData' => [
|
||||
'eventName' => 'setup:customButton:clicked',
|
||||
],
|
||||
'confirm' => true,
|
||||
'confirmData' => [
|
||||
'message' => 'Please confirm...',
|
||||
'eventName' => 'setup:customButton:confirmed',
|
||||
]
|
||||
],
|
||||
// ...
|
||||
|
||||
Events declared in corresponding `eventName` options have to be handled by
|
||||
a custom static JavaScript module. Following snippets show the relevant parts:
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
document.querySelectorAll('[data-event-name]')
|
||||
.forEach((element: HTMLElement) => {
|
||||
element.addEventListener('setup:customButton:clicked', (evt: Event) => {
|
||||
alert('clicked the button');
|
||||
});
|
||||
});
|
||||
document.querySelectorAll('[data-event-name]')
|
||||
.forEach((element: HTMLElement) => {
|
||||
element.addEventListener('setup:customButton:confirmed', (evt: Event) => {
|
||||
evt.detail.result && alert('confirmed the modal dialog');
|
||||
});
|
||||
});
|
||||
|
||||
PSR-14 event :php:`\TYPO3\CMS\Setup\Event\AddJavaScriptModulesEvent` can be used
|
||||
to inject a JavaScript module to handle those custom JavaScript events.
|
||||
|
||||
|
||||
.. index:: Backend, NotScanned, ext:setup
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _important-92020-1668719328:
|
||||
|
||||
===============================================================================
|
||||
Important: #92020 - New API entry point available at https://get.typo3.org/api/
|
||||
===============================================================================
|
||||
|
||||
See :issue:`92020`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The core version service now uses the new entry point of the REST API
|
||||
available via https://get.typo3.org/api.
|
||||
|
||||
The old entry point is still available but should not be longer used.
|
||||
|
||||
For more information see `https://get.typo3.org/api/doc <https://get.typo3.org/api/doc>`_.
|
||||
|
||||
.. index:: ext:install
|
||||
@@ -0,0 +1,45 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _important-92100:
|
||||
|
||||
=========================================================
|
||||
Important: #92100 - YAML imports follow declaration order
|
||||
=========================================================
|
||||
|
||||
See :issue:`92100`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Since #78917 various places of TYPO3 can be configured using YAML. It's
|
||||
also possible to use `imports` to split larger configurations into logical
|
||||
subparts. The `imports` functionality previously imported the configured
|
||||
files in the reverse order in which they were configured in the importing
|
||||
file. Since it's sometimes important, e.g. when using `imports` in site
|
||||
configurations, the import can now be configured to follow the declaration
|
||||
order. The files are then imported in the exact same order as they are
|
||||
configured in the importing file. Therefore, a new feature toggle
|
||||
`yamlImportsFollowDeclarationOrder` is introduced. It defaults to
|
||||
`false` for existing installations and to `true` for new installations.
|
||||
This means, if you currently rely on the reverse order, nothing changes
|
||||
in your existing installation.
|
||||
|
||||
Example:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
imports:
|
||||
- { resource: "EXT:site/Configuration/SomeFile.yaml" }
|
||||
- { resource: "EXT:site/Configuration/AnotherFile.yaml" }
|
||||
|
||||
With `yamlImportsFollowDeclarationOrder` set to `true`:
|
||||
|
||||
1. :file:`EXT:site/Configuration/SomeFile.yaml`
|
||||
2. :file:`EXT:site/Configuration/AnotherFile.yaml`
|
||||
|
||||
With `yamlImportsFollowDeclarationOrder` set to `false`:
|
||||
|
||||
1. :file:`EXT:site/Configuration/AnotherFile.yaml`
|
||||
2. :file:`EXT:site/Configuration/SomeFile.yaml`
|
||||
|
||||
.. index:: Backend, ext:core
|
||||
+24
@@ -0,0 +1,24 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _important-92336:
|
||||
|
||||
============================================================================
|
||||
Important: #92336 - Discarding records in workspace module hard deletes them
|
||||
============================================================================
|
||||
|
||||
See :issue:`92336`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The discard functionality in the workspace module allows to "throw away"
|
||||
changes that have been done by editors in a workspace.
|
||||
|
||||
On database side, discard previously created a mixture of hard deleted (dropped)
|
||||
rows and soft deleted (field :sql:`deleted` set to :sql:`1`) rows.
|
||||
|
||||
This has been streamlined: Discarding records now always hard deletes rows from
|
||||
the database. Those records can't be "undeleted" using the recycler extension
|
||||
anymore, which only worked in very simple and limited cases before.
|
||||
|
||||
.. index:: Backend, Database, ext:workspaces
|
||||
@@ -0,0 +1,24 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _important-92356:
|
||||
|
||||
========================================================
|
||||
Important: #92356 - DataHandler performance improvements
|
||||
========================================================
|
||||
|
||||
See :issue:`92356`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The core :php:`DataHandler` is the central backend heart of the system to
|
||||
persist state changes in the database whenever editors change elements.
|
||||
|
||||
Some changes have been applied to reduce the database query load performed
|
||||
by the :php:`DataHandler` and its related classes. Latest changes especially
|
||||
dropped a number of useless queries and php operations when relations are handled.
|
||||
Depending on the handled structure, the :php:`DataHandler` executes up to 30% less
|
||||
queries than before. More improvements continue to happen and will be ported
|
||||
to v10 if possible.
|
||||
|
||||
.. index:: Backend, Database, ext:core
|
||||
+99
@@ -0,0 +1,99 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _important-92655:
|
||||
|
||||
=======================================================================
|
||||
Important: #92655 - Make request timeout configurable for linkvalidator
|
||||
=======================================================================
|
||||
|
||||
See :issue:`92655`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The external link checking now uses a default (total) timeout of 20 seconds.
|
||||
Previously, a timeout was not set, which resulted in the default from
|
||||
Global Configuration :php:`$GLOBALS['TYPO3_CONF_VARS']['HTTP']['timeout']`
|
||||
being used, which was 0 by default. 0 means no timeout.
|
||||
|
||||
In some edge cases, this caused the link checking to hang indefinitely,
|
||||
which also lead to a scheduler task hanging indefinitely.
|
||||
|
||||
The timeout now defaults to 20 seconds (which is twice the time that is set
|
||||
as connect_timeout in the core Global Configuration).
|
||||
|
||||
The timeout can be changed in Page TSconfig:
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
mod.linkvalidator.linktypesConfig.external.timeout = 10
|
||||
|
||||
You can also unset it, which will result in the Global Configuration
|
||||
:php:`$GLOBALS['TYPO3_CONF_VARS']['HTTP']['timeout']` being used:
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
mod.linkvalidator.linktypesConfig.external.timeout >
|
||||
|
||||
.. important::
|
||||
|
||||
It is not recommended to use 0.
|
||||
|
||||
Background information
|
||||
======================
|
||||
|
||||
The Linkvalidator :php:`ExternalLinktype` class uses the core
|
||||
:php:`RequestFactory` (which uses Guzzle under the hood).
|
||||
:php:`RequestFactory::request` expects a set of options where
|
||||
the timeout can be passed along.
|
||||
|
||||
If it is not, the core :php:`$GLOBALS['TYPO3_CONF_VARS']['HTTP']['timeout']`
|
||||
is used.
|
||||
|
||||
If a timeout for querying an external link is not set, the request may linger
|
||||
indefinitely and will not terminate. See the related issues for steps to
|
||||
reproduce this.
|
||||
|
||||
How does HTTP request timeout generally work?
|
||||
---------------------------------------------
|
||||
|
||||
Depending on the library used and the tool, you can usually set:
|
||||
|
||||
* connect timeout
|
||||
* read timeout
|
||||
* general timeout
|
||||
|
||||
Libraries and utilities often have these options separately, including - for
|
||||
example - the curl command line tool or Guzzle.
|
||||
|
||||
TYPO3 uses Guzzle under the hood.
|
||||
|
||||
Core Global Configuration
|
||||
-------------------------
|
||||
|
||||
These are currently the defaults in the core:
|
||||
|
||||
* :php:`$GLOBALS['TYPO3_CONF_VARS']['HTTP']['connect_timeout'] = 10;`
|
||||
* :php:`$GLOBALS['TYPO3_CONF_VARS']['HTTP']['timeout'] = 0;`
|
||||
|
||||
This sets the corresponding timeouts in Guzzle.
|
||||
|
||||
Guzzle request options
|
||||
----------------------
|
||||
|
||||
These are currently the default timeouts in Guzzle (but connect_timeout
|
||||
and timeout will be overridden by the core):
|
||||
|
||||
* connect_timeout: 0
|
||||
* read_timeout: Defaults to the value of the default_socket_timeout PHP ini
|
||||
setting
|
||||
* timeout: 0
|
||||
|
||||
More information
|
||||
================
|
||||
|
||||
* `Guzzle Request Options <https://docs.guzzlephp.org/en/stable/request-options.html>`__
|
||||
* see :file:`typo3/sysext/core/Configuration/DefaultConfiguration.php in core`
|
||||
* see :php:`GuzzleClientFactory` and :php:`RequestFactory` in the core
|
||||
|
||||
.. index:: Backend, ext:linkvalidator
|
||||
+39
@@ -0,0 +1,39 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _important-92659:
|
||||
|
||||
========================================================================
|
||||
Important: #92659 - Change TCA configuration of imagewidth & imageheight
|
||||
========================================================================
|
||||
|
||||
See :issue:`92659`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The TCA configuration for `tt_content` fields `imagewidth` and `imageheight` has
|
||||
been simplified. Therefore, the following options have been removed from these
|
||||
fields:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'max' => 4,
|
||||
'range' => [
|
||||
'upper' => 1999
|
||||
]
|
||||
|
||||
TYPO3 itself shouldn't limit the inputs of an editor by using a number which
|
||||
was assumed to be large, 10 years ago.
|
||||
|
||||
If you rely on these options, please provide it in your site package by defining
|
||||
it in :file:`Configuration/TCA/Overrides/tt_content.php`:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$GLOBALS['TCA']['tt_content']['columns']['imagewidth']['config']['max'] = 4;
|
||||
$GLOBALS['TCA']['tt_content']['columns']['imagewidth']['config']['range']['upper'] = 1999;
|
||||
|
||||
$GLOBALS['TCA']['tt_content']['columns']['imageheight']['config']['max'] = 4;
|
||||
$GLOBALS['TCA']['tt_content']['columns']['imageheight']['config']['range']['upper'] = 1999;
|
||||
|
||||
.. index:: Backend, TCA, ext:frontend
|
||||
@@ -0,0 +1,75 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _important-93331:
|
||||
|
||||
=======================================================
|
||||
Important: #93331 - Description of SelectCheckBox items
|
||||
=======================================================
|
||||
|
||||
See :issue:`93331`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Due to the introduction of grouping and sorting for TCA columns of type
|
||||
`select` in #91008, the position of the items description, also referred
|
||||
as "Help text" has changed in the corresponding TCA configuration. This
|
||||
previously led to misbehaviour when using `renderType=selectCheckBox`
|
||||
since the old position was still checked by this FormEngine element.
|
||||
|
||||
Adding descriptions is now working again and it will be used when configured
|
||||
at the correct position:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'items' => [
|
||||
...,
|
||||
[
|
||||
'the label',
|
||||
'the value',
|
||||
'iconIdentifier',
|
||||
'groupIdentifier',
|
||||
// The item description must be added as the fifth argument
|
||||
'item description'
|
||||
],
|
||||
]
|
||||
|
||||
It's furthermore still possible to define an array with the `title` and
|
||||
`description` keys:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'items' => [
|
||||
...,
|
||||
[
|
||||
'the label',
|
||||
'the value',
|
||||
'iconIdentifier',
|
||||
'groupIdentifier',
|
||||
// The item description must be added as the fifth argument
|
||||
[
|
||||
'title' => 'Help title',
|
||||
'description' => 'Help description'
|
||||
]
|
||||
]
|
||||
]
|
||||
|
||||
In case you are using :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['customPermOptions']`
|
||||
for defining custom permission options, nothing changes. The description has
|
||||
still to be placed at the third position in each items configuration.
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$GLOBALS['TYPO3_CONF_VARS']['BE']['customPermOptions'] => [
|
||||
'my_custom_field' => [
|
||||
'items' => [
|
||||
'someKey' => [
|
||||
'the label',
|
||||
'anIconIdentifier',
|
||||
'item description',
|
||||
]
|
||||
]
|
||||
]
|
||||
]
|
||||
|
||||
.. index:: Backend, TCA
|
||||
+41
@@ -0,0 +1,41 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _important-93854:
|
||||
|
||||
=================================================================
|
||||
Important: #93854 - Add disabled option for allowed aspect ratios
|
||||
=================================================================
|
||||
|
||||
See :issue:`93854`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Like for crop variants it is now possible to add the option to disable aspect ratios by adding a "disabled" key to the array.
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$GLOBALS['TCA']['tt_content']['types']['textmedia']['columnsOverrides']
|
||||
['assets']['config']['overrideChildTca']['columns']['crop']['config'] = [
|
||||
'cropVariants' => [
|
||||
'default' => [
|
||||
'allowedAspectRatios' => [
|
||||
'4:3' => [
|
||||
'disabled' => true,
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
];
|
||||
|
||||
This works for each field, that defines crop variants for any
|
||||
:sql:`sys_file_reference` usage.
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
This will optionally let you disable aspect ratios for a specific field or
|
||||
:sql:`CType`, which is sometimes necessary because the ratio will not fit in
|
||||
the frontend.
|
||||
|
||||
.. index:: Backend, TCA, ext:backend
|
||||
+34
@@ -0,0 +1,34 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _important-93931:
|
||||
|
||||
=================================================================
|
||||
Important: #93931 - Validation of Extensions' composer.json files
|
||||
=================================================================
|
||||
|
||||
See :issue:`93931`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Future TYPO3 versions will require extensions to have a valid
|
||||
:file:`composer.json` file as a replacement for :file:`ext_emconf.php`.
|
||||
This description file is used to define dependencies and the
|
||||
loading order of extensions within TYPO3.
|
||||
|
||||
In order to support site administrators by creating valid
|
||||
:file:`composer.json` files for their extensions, the Extension manager
|
||||
now lists all affected extensions with details about the necessary
|
||||
adaptations. Site administrators can also use the new proposal
|
||||
functionality, which suggests a possible and valid :file:`composer.json`
|
||||
file for those extensions by accessing TYPO3.org (TER). TYPO3.org
|
||||
is used to resolve dependencies to extensions, available in the TER.
|
||||
|
||||
You can also check your current installation for such extensions
|
||||
in the reports module.
|
||||
|
||||
Further information on the transition phase and examples
|
||||
of valid :file:`composer.json` files for TYPO3 Extensions can be found on
|
||||
https://extensions.typo3.org/help/composer-support
|
||||
|
||||
.. index:: Backend, ext:extensionmanager
|
||||
+53
@@ -0,0 +1,53 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _important-94951-1655368664:
|
||||
|
||||
===================================================================
|
||||
Important: #94951 - Restrict export functionality to allowed users
|
||||
===================================================================
|
||||
|
||||
See :issue:`94951`
|
||||
|
||||
.. important::
|
||||
This change was introduced as part of the
|
||||
`TYPO3 11.5.11 and 10.4.29 security release <https://typo3.org/security/advisory/typo3-core-sa-2022-001>`__.
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The export functionality has the following security drawbacks:
|
||||
|
||||
* Export for editors is not limited on field level
|
||||
* The :guilabel:`Save to filename` functionality saves to a shared folder,
|
||||
which other editors with different access rights may have access to.
|
||||
|
||||
Both issues are not easy to resolve and also the target
|
||||
audience for the Import/Export functionality are mainly
|
||||
TYPO3 admins.
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
The export functionality is restricted
|
||||
to TYPO3 admin users and to users, who explicitly have
|
||||
access through the new user TSConfig setting
|
||||
:typoscript:`options.impexp.enableExportForNonAdminUser`.
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
Installations with EXT:impexp installed where non-admin users need to use the
|
||||
export functionality.
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
If non-admin users should be able to use the export tool, set the
|
||||
following user TSconfig:
|
||||
|
||||
.. code-block:: typoscript
|
||||
:caption: EXT:my_sitepackage/Configuration/TSconfig/allusers.tsconfig
|
||||
|
||||
options.impexp.enableExportForNonAdminUser = 1
|
||||
|
||||
.. index:: Backend, TSConfig, NotScanned, ext:impexp
|
||||
@@ -0,0 +1,41 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _important-95297-1674809371:
|
||||
|
||||
========================================================
|
||||
Important: #95297 - Strict cHash validation feature flag
|
||||
========================================================
|
||||
|
||||
See :issue:`95297`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Since TYPO3 v9 and the PSR-15 Middleware concept, cHash validation was moved
|
||||
outside of plugins and rendering code inside a validation middleware to check if
|
||||
a given "cHash" acts as a signature of other query parameters in order to use a
|
||||
cached version of a frontend page.
|
||||
|
||||
However, the check only provided information about an invalid "cHash" in the
|
||||
query parameters. When no "cHash" was given, the only option was to add a
|
||||
"required list" (global TYPO3 configuration option
|
||||
`requireCacheHashPresenceParameters`), but not based on the final
|
||||
`excludedParameters` for cache hash calculation of given query parameters.
|
||||
|
||||
For this reason, a new global TYPO3 configuration option
|
||||
:php:`$GLOBALS['TYPO3_CONF_VARS']['FE']['cacheHash']['enforceValidation']`
|
||||
has been added.
|
||||
|
||||
When enabled, the same validation for calculating a "cHash" value is used as
|
||||
when a valid or invalid "cHash" parameter is given to a request, even when no
|
||||
"cHash" is given.
|
||||
|
||||
The new option is disabled for existing installations, but enabled for new
|
||||
installations. It is also highly recommended to enable this option in
|
||||
your existing installations.
|
||||
|
||||
In future TYPO3 versions, this functionality will be enabled for all TYPO3
|
||||
installations, while the configuration option
|
||||
`requireCacheHashPresenceParameters` will be removed.
|
||||
|
||||
.. index:: Frontend, LocalConfiguration, ext:frontend
|
||||
@@ -0,0 +1,48 @@
|
||||
:template: changelogOverview.html
|
||||
.. include:: /Includes.rst.txt
|
||||
.. _changelog-10-4-x:
|
||||
|
||||
==============
|
||||
10.4.x Changes
|
||||
==============
|
||||
|
||||
**Table of contents**
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
:depth: 1
|
||||
|
||||
|
||||
Breaking Changes
|
||||
================
|
||||
|
||||
None since TYPO3 v10.4.0 LTS release.
|
||||
|
||||
.. attention::
|
||||
|
||||
Breaking changes are not planned after the TYPO3 v10.4.0 LTS release.
|
||||
|
||||
Features
|
||||
========
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:titlesonly:
|
||||
:glob:
|
||||
|
||||
Feature-*
|
||||
|
||||
Deprecation
|
||||
===========
|
||||
|
||||
None
|
||||
|
||||
Important
|
||||
=========
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:titlesonly:
|
||||
:glob:
|
||||
|
||||
Important-*
|
||||
Reference in New Issue
Block a user