TYPO3 v15 dev-main snapshot ()
This commit is contained in:
+129
@@ -0,0 +1,129 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-108086-1763028403:
|
||||
|
||||
=========================================================================
|
||||
Deprecation: #108086 - Raise deprecation error on using deprecated labels
|
||||
=========================================================================
|
||||
|
||||
See :issue:`108086`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Until now, localization labels marked as deprecated, for example by using the
|
||||
:xml:`x-unused-since` attribute in XLIFF 1.2 or the :xml:`subState="deprecated"`
|
||||
attribute in XLIFF 2.0, did not trigger a runtime warning. As a result,
|
||||
integrators and developers had no automatic way to detect deprecated labels
|
||||
that were still in use.
|
||||
|
||||
With this change, TYPO3 now triggers an :php:`E_USER_DEPRECATED` error when a
|
||||
deprecated label is first written to the localization cache.
|
||||
|
||||
Impacted formats
|
||||
================
|
||||
|
||||
XLIFF 1.2
|
||||
----------
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<trans-unit id="deprecated_label" x-unused-since="4.5">
|
||||
<source>This label is deprecated</source>
|
||||
</trans-unit>
|
||||
|
||||
XLIFF 2.0
|
||||
----------
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<unit id="label5">
|
||||
<segment subState="deprecated">
|
||||
<source>This is label #5 (deprecated in English)</source>
|
||||
</segment>
|
||||
</unit>
|
||||
|
||||
Custom loaders
|
||||
--------------
|
||||
|
||||
When a label identifier ends with `.x-unused`, TYPO3 raises a deprecation
|
||||
warning if the label is referenced, regardless of whether the reference includes
|
||||
the `.x-unused` suffix.
|
||||
|
||||
Custom loaders can use this behaviour to also provide mechanisms to deprecate
|
||||
labels.
|
||||
|
||||
Fallback behaviour
|
||||
==================
|
||||
|
||||
* If a label is deprecated in the fallback language but is overridden in the
|
||||
current locale without a deprecation marker, no deprecation warning is raised.
|
||||
* If a label is deprecated only in the current locale, TYPO3 falls back to the
|
||||
default language and does not raise a deprecation warning.
|
||||
|
||||
A deprecation warning is triggered the first time a deprecated label is written
|
||||
to cache. Subsequent resolutions of the same label use the cached entry and do
|
||||
not trigger additional warnings until the cache is cleared.
|
||||
|
||||
The following usages emit a deprecation warning when a deprecated label is
|
||||
resolved.
|
||||
|
||||
LanguageService
|
||||
---------------
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$this->languageService->sL('EXT:core/Resources/Private/Language/locallang.xlf:someDeprecation');
|
||||
$this->languageService->sL('core.messages:someDeprecation');
|
||||
|
||||
Fluid ViewHelper
|
||||
----------------
|
||||
|
||||
Usage of the `f:translate` ViewHelper in both Extbase and non-Extbase contexts:
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
<f:translate key="some_deprecation" domain="core.messages" />
|
||||
|
||||
<f:translate key="core.messages:some_deprecation" />
|
||||
|
||||
<f:translate key="EXT:core/Resources/Private/Language/locallang.xlf:some_deprecation" />
|
||||
|
||||
The Extension Scanner does not detect the usage of deprecated localization
|
||||
labels. Developers must rely on runtime deprecation logs to identify these
|
||||
occurrences.
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Integrators and developers may encounter new deprecation warnings during runtime
|
||||
or in the deprecation log when deprecated localization labels are used. The
|
||||
warnings help identify and replace outdated labels before they are removed in a
|
||||
future TYPO3 version.
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
All TYPO3 installations that use localization labels marked as deprecated are
|
||||
affected. This includes custom extensions, site packages, or integrations that
|
||||
still reference deprecated labels from system or extension language files.
|
||||
|
||||
When a custom extension or project defines a label whose identifier ends with
|
||||
`.x-unused`, that label is considered deprecated regardless of the loader
|
||||
used. Such usage is technically possible but generally unlikely.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
1. Review the deprecation log for warnings related to localization labels. Note
|
||||
that deprecations are only written the first time a label is used after
|
||||
deleting the cache.
|
||||
2. Replace usages of deprecated labels with non-deprecated ones where possible.
|
||||
3. If required, override deprecated labels in a custom locale without a
|
||||
deprecation marker.
|
||||
4. Remove or update labels marked with `x-unused-since` in XLIFF 1.2 or with
|
||||
`subState="deprecated"` in XLIFF 2.0 when they are no longer needed.
|
||||
5. Avoid defining labels with identifiers ending in `.x-unused`.
|
||||
|
||||
.. index:: ext:core, NotScanned
|
||||
@@ -0,0 +1,58 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-108524-1766073657:
|
||||
|
||||
==========================================================
|
||||
Deprecation: #108524 - Fluid namespaces in TYPO3_CONF_VARS
|
||||
==========================================================
|
||||
|
||||
See :issue:`108524`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Registering global namespaces for Fluid templates in `TYPO3_CONF_VARS` has
|
||||
been deprecated.
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Defined namespaces in :php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['fluid']['namespaces']`
|
||||
will no longer be registered in TYPO3 v15.
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
Installations and extensions that use
|
||||
:php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['fluid']['namespaces']`
|
||||
to define additional global namespaces or extend existing global namespaces.
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Standard use cases, such as registering a new global namespace or extending
|
||||
an existing one, can be migrated to the dedicated `Configuration/Fluid/Namespaces.php`
|
||||
configuration file.
|
||||
|
||||
Before:
|
||||
|
||||
.. code-block:: php
|
||||
:caption: EXT:my_extension/ext_localconf.php
|
||||
|
||||
$GLOBALS['TYPO3_CONF_VARS']['SYS']['fluid']['namespaces']['myext'][] = 'MyVendor\\MyExtension\\ViewHelpers';
|
||||
|
||||
After:
|
||||
|
||||
.. code-block:: php
|
||||
:caption: EXT:my_extension/Configuration/Fluid/Namespaces.php
|
||||
|
||||
<?php
|
||||
|
||||
return [
|
||||
'myext' => ['MyVendor\\MyExtension\\ViewHelpers'],
|
||||
];
|
||||
|
||||
See :ref:`Feature: #108524 - Configuration file to register global Fluid namespaces <feature-108524-1766073747>`
|
||||
for more details and examples.
|
||||
|
||||
.. index:: Fluid, LocalConfiguration, FullyScanned, ext:fluid
|
||||
+38
@@ -0,0 +1,38 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-108667-1768743166:
|
||||
|
||||
=================================================================
|
||||
Deprecation: #108667 - Deprecate CommandNameAlreadyInUseException
|
||||
=================================================================
|
||||
|
||||
See :issue:`108667`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The exception :php:`TYPO3\CMS\Core\Console\CommandNameAlreadyInUseException`
|
||||
is unused within TYPO3 Core and has been deprecated.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Creating a new instance of :php:`TYPO3\CMS\Core\Console\CommandNameAlreadyInUseException`
|
||||
will trigger a PHP deprecation message.
|
||||
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
TYPO3 installations with custom extensions using this exception.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
As the exception is unused in TYPO3 Core, there is no direct replacement.
|
||||
Extensions relying on this exception should implement their own exception
|
||||
if needed.
|
||||
|
||||
.. index:: PHP-API, FullyScanned, ext:core
|
||||
@@ -0,0 +1,39 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-107756-1763294102:
|
||||
|
||||
=====================================
|
||||
Feature: #107756 - Add QR Code module
|
||||
=====================================
|
||||
|
||||
See :issue:`107756`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
A new :guilabel:`Link Management > QR Codes` backend module has been introduced,
|
||||
grouped alongside the existing :guilabel:`Link Management > Redirects` module.
|
||||
|
||||
The QR Codes module provides editors with an efficient way to generate reusable
|
||||
QR codes for various purposes, such as printing them on promotional materials,
|
||||
booth displays, or marketing collateral.
|
||||
|
||||
Each generated QR code contains a permanent, unique URL that never changes,
|
||||
ensuring printed materials remain valid indefinitely. While the QR code URL
|
||||
itself stays constant, the destination it redirects to can be updated at any
|
||||
time, providing flexibility to adapt campaigns or redirect visitors to current
|
||||
content without requiring reprints.
|
||||
|
||||
The module includes a convenient button to generate QR codes on demand, offering
|
||||
multiple download options including different formats (PNG, SVG) and customizable
|
||||
sizes to suit various use cases and printing requirements.
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
The new QR Code module enables users to create scannable QR codes that redirect
|
||||
to any specified URL. This feature is particularly valuable for marketing campaigns,
|
||||
events, and printed materials where maintaining flexibility in the destination URL
|
||||
is essential while preserving the QR code itself.
|
||||
|
||||
.. index:: Backend, ext:redirects
|
||||
@@ -0,0 +1,131 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-107837-1732800000:
|
||||
|
||||
===============================================
|
||||
Feature: #107837 - Route enhancers in site sets
|
||||
===============================================
|
||||
|
||||
See :issue:`107837`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Site sets can now define route enhancers in a dedicated :file:`route-enhancers.yaml`
|
||||
file. This allows extensions to provide route enhancers as part of their site set
|
||||
configuration, which are automatically merged into the site configuration when
|
||||
the set is used as a dependency.
|
||||
|
||||
The route enhancers from site sets are applied as presets. This means that
|
||||
site-level route enhancer configuration takes precedence and can override
|
||||
set-defined enhancers.
|
||||
|
||||
Usage
|
||||
=====
|
||||
|
||||
Create a :file:`route-enhancers.yaml` file in your site set directory alongside
|
||||
the :file:`config.yaml`:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
EXT:my_extension/Configuration/Sets/MySet/
|
||||
├── config.yaml
|
||||
└── route-enhancers.yaml
|
||||
|
||||
The file must contain a `routeEnhancers` key with the route enhancer definitions:
|
||||
|
||||
.. code-block:: yaml
|
||||
:caption: EXT:my_extension/Configuration/Sets/MySet/route-enhancers.yaml
|
||||
|
||||
routeEnhancers:
|
||||
MyEnhancer:
|
||||
type: Simple
|
||||
routePath: '/my-path/{param}'
|
||||
aspects:
|
||||
param:
|
||||
type: StaticValueMapper
|
||||
map:
|
||||
value1: '1'
|
||||
value2: '2'
|
||||
|
||||
The route enhancers file supports YAML imports, allowing you to split
|
||||
configuration across multiple files:
|
||||
|
||||
.. code-block:: yaml
|
||||
:caption: EXT:my_extension/Configuration/Sets/MySet/route-enhancers.yaml
|
||||
|
||||
imports:
|
||||
- { resource: 'route-enhancers/*.yaml', glob: true }
|
||||
|
||||
routeEnhancers:
|
||||
# Additional enhancers can be defined here
|
||||
|
||||
Merging behavior
|
||||
================
|
||||
|
||||
Route enhancers from site sets are merged in dependency order. When a site
|
||||
uses multiple sets, enhancers from earlier dependencies are loaded first,
|
||||
and later sets can override them.
|
||||
|
||||
Site-level route enhancer configuration always takes precedence over
|
||||
set-defined enhancers. This allows sites to customize or override
|
||||
preset configurations from sets.
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
Given a site set with:
|
||||
|
||||
.. code-block:: yaml
|
||||
:caption: EXT:my_extension/Configuration/Sets/MySet/route-enhancers.yaml
|
||||
|
||||
routeEnhancers:
|
||||
PageType:
|
||||
type: PageType
|
||||
default: '0'
|
||||
map:
|
||||
feed.xml: '100'
|
||||
|
||||
And a site configuration with:
|
||||
|
||||
.. code-block:: yaml
|
||||
:caption: config/sites/my-site/config.yaml
|
||||
|
||||
dependencies:
|
||||
- my_extension/my-set
|
||||
|
||||
routeEnhancers:
|
||||
PageType:
|
||||
type: PageType
|
||||
default: '100'
|
||||
map:
|
||||
rss.xml: '200'
|
||||
|
||||
The resulting configuration will be:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
routeEnhancers:
|
||||
PageType:
|
||||
type: PageType
|
||||
default: '100'
|
||||
map:
|
||||
feed.xml: '100'
|
||||
rss.xml: '200'
|
||||
|
||||
Scalar values from the site configuration override set-defined values,
|
||||
while new keys are appended.
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Extensions can now ship route enhancers as part of their site sets, providing
|
||||
a streamlined way to configure routing for extension functionality. This is
|
||||
particularly useful for extensions that require specific URL patterns, such
|
||||
as sitemap extensions or API endpoints.
|
||||
|
||||
Invalid route enhancer configurations are handled gracefully: sets with
|
||||
invalid :file:`route-enhancers.yaml` files are skipped and logged, similar
|
||||
to other set validation errors.
|
||||
|
||||
.. index:: Frontend, YAML, ext:core
|
||||
+36
@@ -0,0 +1,36 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-107837-1732800001:
|
||||
|
||||
=============================================================
|
||||
Feature: #107837 - Sitemap route enhancers provided via site set
|
||||
=============================================================
|
||||
|
||||
See :issue:`107837`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The SEO extension now ships its sitemap route enhancers as part of
|
||||
the `typo3/seo-sitemap` site set. When this set is used as a dependency,
|
||||
the route enhancers for XML sitemaps are automatically configured.
|
||||
|
||||
This enables clean URLs for sitemaps out of the box:
|
||||
|
||||
- `/sitemap.xml` - Main sitemap index
|
||||
- `/sitemap-type/pages` - Pages sitemap
|
||||
|
||||
Previously, these route enhancers had to be manually configured in each
|
||||
site's `config.yaml`.
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Sites using the `typo3/seo-sitemap` set no longer need to manually
|
||||
configure sitemap route enhancers. The clean URLs are available
|
||||
automatically.
|
||||
|
||||
Sites can still override or extend the route enhancers in their
|
||||
site configuration if needed.
|
||||
|
||||
.. index:: Frontend, YAML, ext:seo
|
||||
@@ -0,0 +1,109 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-107961-1762076523:
|
||||
|
||||
=======================================================
|
||||
Feature: #107961 - Search translated pages in page tree
|
||||
=======================================================
|
||||
|
||||
See :issue:`107961`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The page tree filter has been extended with the ability to search for pages
|
||||
through their translated content. This enhancement makes it significantly easier
|
||||
to find pages in multilingual TYPO3 installations, particularly when editors
|
||||
work primarily with translated content.
|
||||
|
||||
The page tree filter now supports two translation search methods:
|
||||
|
||||
1. **Search by translated page title**: When a search phrase matches a translated page
|
||||
title or nav_title, the corresponding default language page will be found and
|
||||
displayed in the page tree.
|
||||
|
||||
2. **Search by translation UID**: When searching for a numeric page UID that belongs
|
||||
to a translated page, the parent default language page will be found and displayed.
|
||||
|
||||
Both search methods work seamlessly alongside the existing search capabilities
|
||||
(searching by page title, nav_title, or default language UID).
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
Translation search is enabled by default and can be controlled in two ways:
|
||||
|
||||
User TSconfig
|
||||
-------------
|
||||
|
||||
Administrators can control the availability of translation search via User TSconfig:
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
# Disable searching in translated pages for specific users/groups
|
||||
options.pageTree.searchInTranslatedPages = 0
|
||||
|
||||
User Preference
|
||||
---------------
|
||||
|
||||
Individual backend users can toggle this setting using the page tree toolbar menu.
|
||||
The preference is stored in the backend user's configuration, allowing each user
|
||||
to customize their search behavior.
|
||||
|
||||
Visual Feedback
|
||||
===============
|
||||
|
||||
When a page is found through a translation match, a colored label is automatically
|
||||
added to provide clear visual feedback:
|
||||
|
||||
**Single translation match**
|
||||
Displays "Found in translation: [Language Name]"
|
||||
|
||||
Example: When searching for "Produkte", a page found via its German translation
|
||||
shows "Found in translation: German"
|
||||
|
||||
**Multiple translation matches**
|
||||
Displays "Found in multiple translations"
|
||||
|
||||
Example: When searching for "Home", a page with matching French and German
|
||||
translations shows "Found in multiple translations"
|
||||
|
||||
**Direct matches**
|
||||
Pages matching the search phrase directly (L=0) show "Search result"
|
||||
|
||||
Example: When searching for "Products", the English page titled "Products"
|
||||
shows "Search result"
|
||||
|
||||
**Combined matches**
|
||||
When a page matches both directly and through a translation, both labels
|
||||
are displayed.
|
||||
|
||||
Example: Searching for "Home" finds a page titled "Home" with a German
|
||||
translation "Startseite Home" - the page shows both labels.
|
||||
|
||||
|
||||
.. note::
|
||||
|
||||
Search term highlighting works only for direct matches. For performance
|
||||
reasons, it is activated only if the search yields fewer than 100 results,
|
||||
and it requires the user to enter at least two characters or a number.
|
||||
|
||||
Flexibility for developers
|
||||
==========================
|
||||
|
||||
Developers can still use the PSR-14 event
|
||||
:php:`\TYPO3\CMS\Backend\Controller\Event\AfterPageTreeItemsPreparedEvent`
|
||||
to add custom labels or modify the prepared tree items before they are rendered.
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Editors working in multilingual TYPO3 installations can now efficiently search
|
||||
for pages using translated titles or translation UIDs. The visual labels provide
|
||||
immediate feedback about how search results were matched, improving the user
|
||||
experience when navigating complex page trees.
|
||||
|
||||
The feature respects user permissions (language restrictions from user groups)
|
||||
and workspace context, ensuring that only accessible translations are searched.
|
||||
|
||||
.. index:: Backend, ext:backend
|
||||
+48
@@ -0,0 +1,48 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-108344-1764239726:
|
||||
|
||||
===================================================================================
|
||||
Feature: #108344 - Allow number of decimals in :typoscript:`stdWrap.bytes` function
|
||||
===================================================================================
|
||||
|
||||
See :issue:`108344`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The TypoScript function :typoscript:`stdWrap.bytes` now accepts an additional
|
||||
configuration parameter :typoscript:`decimals`. It allows to explicitly define
|
||||
the number of decimals in the resulting number representation. By default, the
|
||||
number of decimals is derived from the formatted size.
|
||||
|
||||
In addition, the consumed PHP function
|
||||
:php:`TYPO3\CMS\Core\Utility\GeneralUtility::formatSize` is extended as well.
|
||||
The additional parameter :php:`$decimals` is added and defaults to :php:`null`,
|
||||
which results in the same behavior as for the TypoScript function
|
||||
:typoscript:`stdWrap.bytes`.
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
.. code-block:: typoscript
|
||||
:emphasize-lines: 5
|
||||
|
||||
lib.fileSize = TEXT
|
||||
lib.fileSize {
|
||||
value = 123456
|
||||
bytes = 1
|
||||
bytes.decimals = 1
|
||||
}
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
By allowing to configure the number of decimals in :typoscript:`stdWrap.bytes`,
|
||||
integrators can now better adapt the output of the formatted size returned by
|
||||
the TypoScript function. This was previously not possible by default and needed
|
||||
some workarounds in TypoScript.
|
||||
|
||||
|
||||
.. index:: TypoScript, ext:frontend
|
||||
@@ -0,0 +1,70 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-108431-1765302185:
|
||||
|
||||
====================================================================
|
||||
Feature: #108431 - Add TCA datetime format=datetimesec option
|
||||
====================================================================
|
||||
|
||||
See :issue:`108431`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The TCA configuration config option `type=datetime` can now specify
|
||||
the `format=datetimesec` format to offer a date/time picker for entering
|
||||
a date (*day, month, year*) with a specific time (*hour, minute, second*).
|
||||
|
||||
Previously, only a datepicker for *hour* and *minute* was available,
|
||||
even though the utilized component (Flatpickr) supports entering seconds.
|
||||
|
||||
This format can either be specified for `dbType=datetime` (native SQL datetime
|
||||
columns based on a timestamp that always includes seconds) or
|
||||
for the `integer`-based storage without a `dbType` option (UNIX timestamp).
|
||||
|
||||
Example TCA configuration:
|
||||
|
||||
.. code-block:: php
|
||||
:caption: EXT:my_extension/Configuration/TCA/tx_domain_model_myelement.php
|
||||
|
||||
<?php
|
||||
|
||||
return [
|
||||
// ...
|
||||
'columns' => [
|
||||
'meteor_impact' => [
|
||||
'label' => 'Time of estimated impact',
|
||||
'config' => [
|
||||
'type' => 'datetime',
|
||||
'format' => 'datetimesec',
|
||||
'dbType' => 'datetime', // can also be omitted for integer-based storage
|
||||
'nullable' => true, // can also be false
|
||||
],
|
||||
],
|
||||
],
|
||||
// ...
|
||||
];
|
||||
|
||||
.. hint::
|
||||
|
||||
The format `datetimesec` is only allowed for:
|
||||
|
||||
* empty :php:`['config']['dbType']` (defaults to integer-based storage type)
|
||||
* :php:`['config']['dbType'] = 'datetime'` (native date and time storage type)
|
||||
|
||||
Other types (`date`, `time`, `timesec`) do not support both components
|
||||
and would yield unconsistent data.
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Editors and integrators can now specify dates including seconds
|
||||
in database record fields, if the fields are configured with the
|
||||
new TCA config format `datetimesec`.
|
||||
|
||||
This can be set for any TCA field that already internally receives a
|
||||
UNIX timestamp value.
|
||||
|
||||
*-- For the editor who has everything, but seconds.*
|
||||
|
||||
.. index:: Backend, NotScanned, ext:core
|
||||
+54
@@ -0,0 +1,54 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-108462-1765368045:
|
||||
|
||||
========================================================================
|
||||
Feature: #108462 - Add PSR-14 Event AfterPageContentPreviewRenderedEvent
|
||||
========================================================================
|
||||
|
||||
See :issue:`108462`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The class :php:`\TYPO3\CMS\Backend\View\BackendLayout\Grid\GridColumnItem` is
|
||||
the central entity to generate various previews of content elements.
|
||||
|
||||
Developers can either use the event :php:`\TYPO3\CMS\Backend\View\Event\PageContentPreviewRenderingEvent`
|
||||
to generate a preview or implementing :php:`\TYPO3\CMS\Backend\Preview\PreviewRendererInterface`.
|
||||
|
||||
The new PSR-14 event :php:`\TYPO3\CMS\Backend\View\Event\AfterPageContentPreviewRenderedEvent`
|
||||
can now be used to enrich the output generated by one of those.
|
||||
|
||||
Example
|
||||
=======
|
||||
|
||||
An example event listener could look like this:
|
||||
|
||||
.. code-block:: php
|
||||
:caption: Example event listener class
|
||||
|
||||
namespace MyVendor\MyExtension\EventListener;
|
||||
|
||||
use TYPO3\CMS\Backend\View\Event\AfterPageContentPreviewRenderedEvent;
|
||||
use TYPO3\CMS\Core\Attribute\AsEventListener;
|
||||
|
||||
#[AsEventListener('my-extension')]
|
||||
final class AfterPageContentPreviewRenderedEventListener
|
||||
{
|
||||
public function __invoke(AfterPageContentPreviewRenderedEvent $event): void
|
||||
{
|
||||
$content = 'before<hr />'. $event->getPreviewContent() . '<hr />after';
|
||||
$event->setPreviewContent($content);
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
As integrator it is sometimes handy to enrich the previews of other
|
||||
content elements and plugins to display additional fields.
|
||||
|
||||
|
||||
.. index:: Backend, PHP-API, ext:backend
|
||||
+37
@@ -0,0 +1,37 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-108463-1765370503:
|
||||
|
||||
=======================================================================================
|
||||
Feature: #108463 - User-specific configuration of date-timepicker's first day of a week
|
||||
=======================================================================================
|
||||
|
||||
See :issue:`108463`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Previously, the date-time picker used the selected locale of a backend user.
|
||||
|
||||
However, certain locale configurations might rather be a user preference.
|
||||
For example, users may prefer an english backend but want to use a weekday
|
||||
start on "Monday" instead of "Sunday" due to their cultural habits.
|
||||
|
||||
Thus, the "first day of a week" has been decoupled from the locale selection
|
||||
and can be configured on a per-user setting. By default, it still inherits
|
||||
the locale's default setting, if not changed (for example, english=sunday
|
||||
and german=monday).
|
||||
|
||||
Inside the user settings and tab panel :guilabel:`Backend appearance`, a new dropdown
|
||||
:guilabel:`First day of week in calendar popups` appears.
|
||||
|
||||
The setting is stored in both the persisted :sql:`be_users.uc` preference blob,
|
||||
as well as on the JavaScript-persistence side.
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Editors can now choose the first day of a week as a user preference, independent
|
||||
from locale selection.
|
||||
|
||||
.. index:: Backend, NotScanned, ext:core
|
||||
@@ -0,0 +1,222 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-108508-1765987901:
|
||||
|
||||
===============================================
|
||||
Feature: #108508 - Fluid components integration
|
||||
===============================================
|
||||
|
||||
See :issue:`108508`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Fluid 4.3 introduced the concept of components to Fluid (see
|
||||
`Components <https://docs.typo3.org/permalink/fluid:components>`_). Since then, it
|
||||
was already possible to use components in TYPO3 projects by creating a custom
|
||||
:php:`ComponentCollection` class that essentially connects a folder of template files
|
||||
to a Fluid ViewHelper namespace. Using that class it was also possible to use an
|
||||
alternative folder structure for a component collection and to allow passing
|
||||
arbitrary arguments to components within that collection.
|
||||
|
||||
Now it is possible to define component collections purely with configuration.
|
||||
For the most common use cases, it is no longer necessary to create a custom
|
||||
PHP class, which makes it much easier for integrators to setup components in
|
||||
TYPO3 projects.
|
||||
|
||||
Registering component collections
|
||||
---------------------------------
|
||||
|
||||
The new extension-level configuration file
|
||||
:file:`Configuration/Fluid/ComponentCollections.php` is introduced, which allows
|
||||
extensions to register one or multiple new component collections. It is also possible
|
||||
to extend existing collections registered by other extensions (such as adding template
|
||||
paths to override components defined by another extension).
|
||||
|
||||
Basic example:
|
||||
|
||||
.. code-block:: php
|
||||
:caption: EXT:my_extension/Configuration/Fluid/ComponentCollections.php
|
||||
|
||||
<?php
|
||||
|
||||
return [
|
||||
'MyVendor\\MyExtension\\Components' => [
|
||||
'templatePaths' => [
|
||||
10 => 'EXT:my_extension/Resources/Private/Components',
|
||||
],
|
||||
],
|
||||
];
|
||||
|
||||
Components in that collection can then be used in any Fluid template:
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
<html
|
||||
xmlns:my="http://typo3.org/ns/MyVendor/MyExtension/Components"
|
||||
data-namespace-typo3-fluid="true"
|
||||
>
|
||||
|
||||
<my:organism.header.navigation />
|
||||
|
||||
By default, component collections use a folder structure that requires a
|
||||
separate folder per component. This is handy if you want to put other
|
||||
files right next to your component template, such as the matching CSS
|
||||
or JS file, or even a custom language file. Using the example above,
|
||||
:html:`<my:organism.header.navigation />` would point to
|
||||
:file:`EXT:my_extension/Resources/Private/Components/Organism/Header/Navigation/Navigation.fluid.html`.
|
||||
|
||||
If not otherwise specified, components use a strict API, meaning that all
|
||||
arguments that are passed to a component need to be defined with
|
||||
:html:`<f:argument>` in the component template.
|
||||
|
||||
Both defaults can be adjusted per collection by providing configuration options:
|
||||
|
||||
* `templateNamePattern` allows you to use a different folder structure, available
|
||||
variables are `{path}` and `{name}`. For :html:`<my:organism.header.navigation>`,
|
||||
`{path}` would be `Organism/Header` and `{name}` would be `Navigation`.
|
||||
* setting `additionalArgumentsAllowed` to `true` allows passing undefined arguments
|
||||
to components.
|
||||
|
||||
Advanced example:
|
||||
|
||||
.. code-block:: php
|
||||
:caption: EXT:my_extension/Configuration/Fluid/ComponentCollections.php
|
||||
|
||||
<?php
|
||||
|
||||
return [
|
||||
'MyVendor\\MyExtension\\Components' => [
|
||||
'templatePaths' => [
|
||||
10 => 'EXT:my_extension/Resources/Private/Components',
|
||||
],
|
||||
'templateNamePattern' => '{path}/{name}',
|
||||
'additionalArgumentsAllowed' => true,
|
||||
],
|
||||
];
|
||||
|
||||
Using this example :html:`<my:organism.header.navigation />` would point to
|
||||
:file:`EXT:my_extension/Resources/Private/Components/Organism/Header/Navigation.fluid.html`
|
||||
(note the missing :file:`Navigation` folder).
|
||||
|
||||
It is possible to influence certain aspects of Fluid components using PSR-14 events,
|
||||
see :ref:`PSR-14 events for Fluid components <feature-108508-1765987847>`
|
||||
|
||||
Creating components
|
||||
-------------------
|
||||
|
||||
A typical component looks just like a normal Fluid template, except that it defines
|
||||
all of its arguments with the
|
||||
`Argument ViewHelper <f:argument> <https://docs.typo3.org/permalink/t3viewhelper:typo3fluid-fluid-argument>`_.
|
||||
Also, the `Slot ViewHelper <f:slot> <https://docs.typo3.org/permalink/t3viewhelper:typo3fluid-fluid-slot>`_
|
||||
can be used to receive HTML content.
|
||||
|
||||
Example:
|
||||
|
||||
.. code-block:: html
|
||||
:caption: EXT:my_extension/Resources/Private/Components/Molecule/TeaserCard/TeaserCard.fluid.html
|
||||
|
||||
<html
|
||||
xmlns:my="http://typo3.org/ns/MyVendor/MyExtension/Components"
|
||||
data-namespace-typo3-fluid="true"
|
||||
>
|
||||
|
||||
<f:argument name="title" type="string" />
|
||||
<f:argument name="link" type="string" />
|
||||
<f:argument name="icon" type="string" optional="{true}" />
|
||||
|
||||
<a href="{link}" class="teaserCard">
|
||||
<f:if condition="{icon}">
|
||||
<my:atom.icon identifier="{icon}">
|
||||
</f:if>
|
||||
<div class="teaserCard__title">{title}</div>
|
||||
<div class="teaserCard__content"><f:slot /></div>
|
||||
</a>
|
||||
|
||||
The example also demonstrates that components can (and should) use other components, in this
|
||||
case :html:`<my:atom.icon>`.
|
||||
Depending on the use case, it might also make sense to pass the output of one component
|
||||
to another component via a slot:
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
<html
|
||||
xmlns:my="http://typo3.org/ns/MyVendor/MyExtension/Components"
|
||||
data-namespace-typo3-fluid="true"
|
||||
>
|
||||
|
||||
<my:molecule.teaserCard
|
||||
title="TYPO3"
|
||||
link="https://typo3.org/"
|
||||
icon="typo3"
|
||||
>
|
||||
<my:atom.text>{content}</my:atom.text>
|
||||
</my:molecule.teaserCard>
|
||||
|
||||
You can learn more about components in
|
||||
`Defining Components <https://docs.typo3.org/permalink/fluid:components-definition>`_. Note
|
||||
that this is part of the documentation of Fluid Standalone, which means that it doesn't mention
|
||||
TYPO3 specifics.
|
||||
|
||||
Migration and co-existence with class-based collections
|
||||
-------------------------------------------------------
|
||||
|
||||
Configuration-based and class-based component collections can be used side by side.
|
||||
For more advanced use cases, it might still be best to ship a custom class to define
|
||||
a component collection. However, most use cases can easily be migrated to the
|
||||
configuration-based approach, since they usually just consist of boilerplate code
|
||||
around the configuration options.
|
||||
|
||||
Since the new approach is not available in TYPO3 13, it is possible to ship both
|
||||
variants to provide backwards-compatibility: If a specific component collection is
|
||||
defined both via class and via configuration, in TYPO3 13 the class will be used,
|
||||
while in TYPO3 14 the configuration will be used and the class will be ignored completely.
|
||||
|
||||
Extending component collections from other extensions
|
||||
-----------------------------------------------------
|
||||
|
||||
It is possible to extend the configuration of other extensions using the
|
||||
introduced configuration file. This allows integrators to merge their own set of
|
||||
components into an existing component collection:
|
||||
|
||||
.. code-block:: php
|
||||
:caption: EXT:vendor_extension/Configuration/Fluid/ComponentCollections.php
|
||||
|
||||
<?php
|
||||
|
||||
return [
|
||||
'SomeVendor\\VendorExtension\\Components' => [
|
||||
'templatePaths' => [
|
||||
10 => 'EXT:vendor_extension/Resources/Private/Components',
|
||||
],
|
||||
],
|
||||
];
|
||||
|
||||
.. code-block:: php
|
||||
:caption: EXT:my_extension/Configuration/Fluid/ComponentCollections.php
|
||||
|
||||
<?php
|
||||
|
||||
return [
|
||||
'SomeVendor\\VendorExtension\\Components' => [
|
||||
'templatePaths' => [
|
||||
1765990741 => 'EXT:my_extension/Resources/Private/Extensions/VendorExtension/Components',
|
||||
],
|
||||
],
|
||||
];
|
||||
|
||||
For template paths, the familiar rule applies: They will be sorted by their
|
||||
keys and will be processed in reverse order. In this example, if `my_extension`
|
||||
defines a component that already exists in `vendor_extension`, it will override
|
||||
the original component in `vendor_extension`.
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Fluid component collections no longer need to be defined by creating a custom
|
||||
class, but can now be registered purely by configuration. Existing class-based
|
||||
collections will continue to work. If a collection namespace is registered both
|
||||
by a class and by configuration, the configuration overrules the class and any
|
||||
custom code in the class is ignored.
|
||||
|
||||
.. index:: Fluid, ext:fluid
|
||||
@@ -0,0 +1,171 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-108508-1765987847:
|
||||
|
||||
=====================================================
|
||||
Feature: #108508 - PSR-14 events for Fluid components
|
||||
=====================================================
|
||||
|
||||
See :issue:`108508`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Three PSR-14 events have been added to influence the processing and rendering
|
||||
of Fluid components that are registered using the new configuration file
|
||||
(see :ref:`Fluid components integration <feature-108508-1765987901>`).
|
||||
|
||||
ModifyComponentDefinitionEvent
|
||||
------------------------------
|
||||
|
||||
The :php-short:`\TYPO3\CMS\Fluid\Event\ModifyComponentDefinitionEvent` can be
|
||||
used to modify the definition of a component before it's written to the cache.
|
||||
Component definitions must not have any dependencies on runtime information, as
|
||||
they might be used for static analysis or IDE auto-completion. Due
|
||||
to the component definitions cache, this is already enforced, as the registered
|
||||
events are only executed once and not on every request.
|
||||
|
||||
Example:
|
||||
|
||||
.. code-block:: php
|
||||
:caption: EXT:my_extension/Classes/EventListener/ModifyComponentDefinitionListener.php
|
||||
|
||||
<?php
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
namespace MyVendor\MyExtension\EventListener;
|
||||
|
||||
use TYPO3\CMS\Core\Attribute\AsEventListener;
|
||||
use TYPO3\CMS\Fluid\Event\ModifyComponentDefinitionEvent;
|
||||
use TYPO3Fluid\Fluid\Core\Component\ComponentDefinition;
|
||||
use TYPO3Fluid\Fluid\Core\ViewHelper\ArgumentDefinition;
|
||||
|
||||
#[AsEventListener]
|
||||
final readonly class ModifyComponentDefinitionListener
|
||||
{
|
||||
public function __invoke(ModifyComponentDefinitionEvent $event): void
|
||||
{
|
||||
// Add required argument to one specific component
|
||||
if (
|
||||
$event->getNamespace() === 'MyVendor\\MyExtension\\Components' &&
|
||||
$event->getComponentDefinition()->getName() === 'myComponent'
|
||||
) {
|
||||
$originalDefinition = $event->getComponentDefinition();
|
||||
$event->setComponentDefinition(new ComponentDefinition(
|
||||
$originalDefinition->getName(),
|
||||
[
|
||||
...$originalDefinition->getArgumentDefinitions(),
|
||||
'myArgument' => new ArgumentDefinition('myArgument', 'string', '', true),
|
||||
],
|
||||
$originalDefinition->additionalArgumentsAllowed(),
|
||||
$originalDefinition->getAvailableSlots(),
|
||||
));
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
ProvideStaticVariablesToComponentEvent
|
||||
--------------------------------------
|
||||
|
||||
The :php-short:`\TYPO3\CMS\Fluid\Event\ProvideStaticVariablesToComponentEvent` can
|
||||
be used to inject additional static variables into component templates. As with the
|
||||
:php-short:`\TYPO3\CMS\Fluid\Event\ModifyComponentDefinitionEvent`, these variables
|
||||
must not have any dependencies on runtime information, as they might be used for
|
||||
static analysis or IDE auto-completion. The
|
||||
:php-short:`\TYPO3\CMS\Fluid\Event\RenderComponentEvent` can be used to add variables
|
||||
with runtime dependencies.
|
||||
|
||||
Valid use cases for this event might be:
|
||||
|
||||
* providing static (!) design tokens (colors, icons, ...) to all components in a collection
|
||||
* generating prefix strings based on the component's name
|
||||
|
||||
Example:
|
||||
|
||||
.. code-block:: php
|
||||
:caption: EXT:my_extension/Classes/EventListener/ProvideStaticVariablesToComponentListener.php
|
||||
|
||||
<?php
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
namespace MyVendor\MyExtension\EventListener;
|
||||
|
||||
use TYPO3\CMS\Core\Attribute\AsEventListener;
|
||||
use TYPO3\CMS\Fluid\Event\ProvideStaticVariablesToComponentEvent;
|
||||
|
||||
#[AsEventListener]
|
||||
final readonly class ProvideStaticVariablesToComponentListener
|
||||
{
|
||||
public function __invoke(ProvideStaticVariablesToComponentEvent $event): void
|
||||
{
|
||||
// Provide design tokens to all components in a collection
|
||||
if ($event->getComponentCollection()->getNamespace() === 'MyVendor\\MyExtension\\Components') {
|
||||
$event->setStaticVariables([
|
||||
...$event->getStaticVariables(),
|
||||
'designTokens' => [
|
||||
'color1' => '#abcdef',
|
||||
'color2' => '#123456',
|
||||
],
|
||||
]);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
RenderComponentEvent
|
||||
--------------------
|
||||
|
||||
The :php-short:`\TYPO3\CMS\Fluid\Event\RenderComponentEvent` can be used to alter or
|
||||
replace the rendering of Fluid components. There are three possible use cases:
|
||||
|
||||
1. fully take over the rendering of components by filling the :php:`$renderedContent` with
|
||||
:php:`$event->setRenderedContent()`. The first event that does this skips all following
|
||||
event listeners.
|
||||
2. provide additional arguments (= variables in the component template) or slots to
|
||||
the component with :php:`$event->setArguments()`/:php:`$event->setSlots()`.
|
||||
3. execute additional code that doesn't influence the component rendering directly, e. g.
|
||||
adding certain frontend assets to the page automatically.
|
||||
|
||||
Example:
|
||||
|
||||
.. code-block:: php
|
||||
:caption: EXT:my_extension/Classes/EventListener/RenderComponentListener.php
|
||||
|
||||
<?php
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
namespace MyVendor\MyExtension\EventListener;
|
||||
|
||||
use TYPO3\CMS\Core\Attribute\AsEventListener;
|
||||
use TYPO3\CMS\Core\Page\AssetCollector;
|
||||
use TYPO3\CMS\Fluid\Event\RenderComponentEvent;
|
||||
|
||||
#[AsEventListener]
|
||||
final readonly class RenderComponentListener
|
||||
{
|
||||
public function __construct(private AssetCollector $assetCollector) {}
|
||||
|
||||
public function __invoke(RenderComponentEvent $event): void
|
||||
{
|
||||
// Add bundled components CSS if a component is used on the page
|
||||
if ($event->getComponentCollection()->getNamespace() === 'MyVendor\\MyExtension\\Components') {
|
||||
$this->assetCollector->addStyleSheet(
|
||||
'componentsBundle',
|
||||
'EXT:my_extension/Resources/Public/ComponentsBundle.css'
|
||||
);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Three new PSR-14 events can be used to influence the processing and rendering
|
||||
of Fluid components.
|
||||
|
||||
.. index:: Fluid, ext:fluid
|
||||
+167
@@ -0,0 +1,167 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-108524-1766073747:
|
||||
|
||||
=========================================================================
|
||||
Feature: #108524 - Configuration file to register global Fluid namespaces
|
||||
=========================================================================
|
||||
|
||||
See :issue:`108524`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The extension-level configuration file `Configuration/Fluid/Namespaces.php`
|
||||
is introduced, which enables a structured way to register and extend global
|
||||
Fluid namespaces. This replaces the old configuration in
|
||||
:php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['fluid']['namespaces']`, see
|
||||
:ref:`deprecation <deprecation-108524-1766073657>`.
|
||||
|
||||
Example:
|
||||
|
||||
.. code-block:: php
|
||||
:caption: EXT:my_extension/Configuration/Fluid/Namespaces.php
|
||||
|
||||
<?php
|
||||
|
||||
return [
|
||||
'myext' => ['MyVendor\\MyExtension\\ViewHelpers'],
|
||||
'mycmp' => ['MyVendor\\MyExtension\\Components'],
|
||||
];
|
||||
|
||||
Overriding existing ViewHelpers
|
||||
-------------------------------
|
||||
|
||||
TYPO3 reads and merges `Configuration/Fluid/Namespaces.php` files from all
|
||||
loaded extensions in the usual loading order, which can be manipulated by
|
||||
declaring dependencies in `composer.json` and possibly `ext_emconf.php`. If an
|
||||
extension registers a namespace that has already been registered by another
|
||||
extension, these namespaces will be merged by Fluid. This allows extensions
|
||||
to override ViewHelpers of another extension selectively.
|
||||
|
||||
Example (extension2 depends on extension1):
|
||||
|
||||
.. code-block:: php
|
||||
:caption: EXT:my_extension1/Configuration/Fluid/Namespaces.php
|
||||
|
||||
<?php
|
||||
|
||||
return [
|
||||
'myext' => ['MyVendor\\MyExtension1\\ViewHelpers'],
|
||||
];
|
||||
|
||||
.. code-block:: php
|
||||
:caption: EXT:my_extension2/Configuration/Fluid/Namespaces.php
|
||||
|
||||
<?php
|
||||
|
||||
return [
|
||||
'myext' => ['MyVendor\\MyExtension2\\ViewHelpers'],
|
||||
];
|
||||
|
||||
Resulting namespace definition:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
[
|
||||
'myext' => [
|
||||
'MyVendor\\MyExtension1\\ViewHelpers',
|
||||
'MyVendor\\MyExtension2\\ViewHelpers',
|
||||
],
|
||||
];
|
||||
|
||||
Namespaces are processed in reverse order, which means that
|
||||
:html:`<myext:demo />` would first check for
|
||||
`EXT:my_extension2/Classes/ViewHelpers/DemoViewHelper.php`, and would
|
||||
fall back to `EXT:my_extension1/Classes/ViewHelpers/DemoViewHelper.php`.
|
||||
|
||||
PSR-14 event to modify namespaces
|
||||
---------------------------------
|
||||
|
||||
The new :php-short:`\TYPO3\CMS\Fluid\Event\ModifyNamespacesEvent` is
|
||||
introduced, which allows modification of the whole namespaces array
|
||||
before it is being passed to Fluid. This allows for example to:
|
||||
|
||||
* completely redefine an existing namespace (instead of extending it)
|
||||
* add namespaces conditionally
|
||||
* modify order of merged namespaces
|
||||
|
||||
Example:
|
||||
|
||||
.. code-block:: php
|
||||
:caption: EXT:my_extension/Classes/EventListener/ModifyNamespacesListener.php
|
||||
|
||||
<?php
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
namespace MyVendor\MyExtension\EventListener;
|
||||
|
||||
use TYPO3\CMS\Core\Attribute\AsEventListener;
|
||||
use TYPO3\CMS\Fluid\Event\ModifyNamespacesEvent;
|
||||
|
||||
#[AsEventListener]
|
||||
final readonly class ModifyNamespacesListener
|
||||
{
|
||||
public function __invoke(ModifyNamespacesEvent $event): void
|
||||
{
|
||||
$namespaces = $event->getNamespaces();
|
||||
// Replace existing "theme" namespace completely
|
||||
$namespaces['theme'] = ['MyVendor\\MyExtension\\ViewHelpers'];
|
||||
$event->setNamespaces($namespaces);
|
||||
}
|
||||
}
|
||||
|
||||
Note that namespaces might still be imported locally from within a
|
||||
template file, which is unaffected by this event.
|
||||
|
||||
Backwards-compatible namespaces in extensions
|
||||
---------------------------------------------
|
||||
|
||||
There are several ways to provide backwards-compatible global namespaces
|
||||
in extensions, depending on the concrete use case:
|
||||
|
||||
* preferred: Define namespace in `TYPO3_CONF_VARS` (with version check) and
|
||||
in new `Namespaces.php`. This means that in TYPO3 v14 installations the new
|
||||
`Namespaces.php` can already be used to extend the namespace.
|
||||
* alternative: Define namespace both in `TYPO3_CONF_VARS` (without version
|
||||
check) and in new `Namespaces.php`. This means however that the namespace
|
||||
can only be extended with `TYPO3_CONF_VARS`, not with the new `Namespaces.php`.
|
||||
* keep `TYPO3_CONF_VARS` until support for < v14 is dropped by the extension.
|
||||
This can only be extended with `TYPO3_CONF_VARS` as well.
|
||||
* implement own merging logic in :php:`ModifyNamespacesEvent` if necessary.
|
||||
|
||||
Example for preferred option:
|
||||
|
||||
.. code-block:: php
|
||||
:caption: EXT:my_extension/Configuration/Fluid/Namespaces.php
|
||||
|
||||
<?php
|
||||
|
||||
return [
|
||||
'myext' => ['MyVendor\\MyExtension\\ViewHelpers'],
|
||||
];
|
||||
|
||||
.. code-block:: php
|
||||
:caption: EXT:my_extension/ext_localconf.php
|
||||
|
||||
<?php
|
||||
|
||||
if ((new \TYPO3\CMS\Core\Information\Typo3Version())->getMajorVersion() < 14) {
|
||||
$GLOBALS['TYPO3_CONF_VARS']['SYS']['fluid']['namespaces']['myext'][] = 'MyVendor\\MyExtension\\ViewHelpers';
|
||||
}
|
||||
|
||||
To sum up:
|
||||
|
||||
* `Namespaces.php` can only extend namespaces defined in `Namespaces.php`.
|
||||
* `TYPO3_CONF_VARS` can extend both `TYPO3_CONF_VARS` and `Namespaces.php`.
|
||||
* :php:`ModifyNamespacesEvent` can modify everything.
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Extensions can now register global Fluid namespaces in a dedicated
|
||||
configuration file `Configuration/Fluid/Namespaces.php`. The old
|
||||
`TYPO3_CONF_VARS` registration can be used for backwards compatibility.
|
||||
|
||||
.. index:: Fluid, ext:fluid
|
||||
@@ -0,0 +1,109 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-108539-1768554158:
|
||||
|
||||
===================================================
|
||||
Feature: #108539 - Introduce default theme "Camino"
|
||||
===================================================
|
||||
|
||||
See :issue:`108539`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
A new default theme has been added. Its main purpose
|
||||
is to build new sites more rapidly in TYPO3 v14.
|
||||
|
||||
The name **Camino** (spanish "the way") was chosen as v14 development
|
||||
series, marking the first steps on the way to a glorious future for
|
||||
TYPO3.
|
||||
|
||||
It serves to show that a new site in TYPO3 can be set up within
|
||||
minutes, being customizable (at least in a limited way), without
|
||||
having to rely on any external library, and to avoid ANY error
|
||||
message for newcomers to TYPO3.
|
||||
|
||||
Camino will be packaged for new installations by default
|
||||
and can be activated for new sites alongside existing sites.
|
||||
|
||||
The theme shows off basic page structures as well as
|
||||
some default content elements - completely without any
|
||||
third-party dependencies nor requiring the "Fluid styled content"
|
||||
extension.
|
||||
|
||||
The rough structure of the theme:
|
||||
|
||||
* Four different color schemes can be selected in the site settings
|
||||
|
||||
* The main menu structure and footer structure can be configured
|
||||
on the root page inside the backend layout / colPos positions
|
||||
|
||||
* Common content elements for a Hero area and regular content
|
||||
is available
|
||||
|
||||
* Minimal configuration is handled in TypoScript
|
||||
|
||||
The theme is not meant to evolve within TYPO3, as it will
|
||||
be moved to TER/Packagist/GitHub in a separate repository
|
||||
in v15.0. In v15.x a new theme will be added with more
|
||||
modern features, and it will utilize features that will
|
||||
be added during v15.x development.
|
||||
|
||||
The theme is 100% optional and encapsulated - existing setups
|
||||
will have no interference.
|
||||
|
||||
The theme will be fine-tuned before the TYPO3 v14 LTS release,
|
||||
specific documentation for its features will be provided in
|
||||
the theme's documentation.
|
||||
|
||||
Installation
|
||||
------------
|
||||
|
||||
For now, the theme is the same as a regular TYPO3 extension.
|
||||
|
||||
On fresh classic-mode installations, the theme will be enabled
|
||||
by default. A new site and a first page will be created, which
|
||||
can be used to insert content.
|
||||
|
||||
On Composer-mode installations, the package `typo3/theme-camino`
|
||||
needs to be required, and a fresh installation will also create
|
||||
the site and a first page.
|
||||
|
||||
For existing installations, the theme must be enabled first
|
||||
(depending on the TYPO3 setup) either via extension manager,
|
||||
or by requiring the Composer package.
|
||||
|
||||
Once the "extension" is activated, the steps to enable
|
||||
the Camino frontend are:
|
||||
|
||||
* Create a new root page in the :guilabel:`Content > Layout`
|
||||
page tree. Be sure to edit the created page properties and enable
|
||||
:guilabel:`Behavior > Use as Root Page` .
|
||||
* This will automatically create a new Site. Check :guilabel:`Sites > Setup`
|
||||
to see the created Site. Edit that Site's properties. In
|
||||
:guilabel:`General > Sets for this Site` ensure that the `Theme: Camino`
|
||||
Site set is added as a dependency.
|
||||
* (Depending on the TYPO3 setup, TYPO3 caches might need to be cleared)
|
||||
* Then edit the created root page properties via :guilabel:`Content > Layout` again,
|
||||
and pick `Camino: Start page` from the tab
|
||||
:guilabel:`Appearance > Backend Layout (this page only)`.
|
||||
* Now the Camino theme will be applied to the site. Content can be added
|
||||
in the specific columns, and sub-pages can be created (ensure to set
|
||||
the backend layout of subpages to the appropriate Camino backend layout,
|
||||
either :guilabel:`Camino: Content page (full-width)` or
|
||||
:guilabel:`Camino: Content page (with sidebar)`.
|
||||
* A custom logo can be set in root page properties :guilabel:`Appearance`, just
|
||||
above the backend layout picker.
|
||||
* In :guilabel:`Sites > Setup`, the Site set configuration can be accessed
|
||||
to adjust the color scheme and further options.
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
A default frontend theme is now available. It can be easily
|
||||
activated in the TYPO3 installation process, or also be enabled
|
||||
afterwards.
|
||||
|
||||
It is dependency-free and provides and utilizes site sets.
|
||||
|
||||
.. index:: Frontend, NotScanned, ext:theme_camino
|
||||
+26
@@ -0,0 +1,26 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-108558-1766399298:
|
||||
|
||||
==================================================================
|
||||
Feature: #108558 - Add original file name to SanitizeFileNameEvent
|
||||
==================================================================
|
||||
|
||||
See :issue:`108558`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The PSR-14 event :php:`\TYPO3\CMS\Core\Resource\Event\SanitizeFileNameEvent`
|
||||
does now also provide the original file name. Event listeners can use the
|
||||
original file name to perform custom string replacements (e.g. space to
|
||||
hyphen instead of underscore) for the sanitized file name.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
It is now possible to retrieve the original file name in the PSR-14 event
|
||||
:php:`\TYPO3\CMS\Core\Resource\Event\SanitizeFileNameEvent`.
|
||||
|
||||
.. index:: PHP-API, ext:core
|
||||
+109
@@ -0,0 +1,109 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-108623-1768315053:
|
||||
|
||||
================================================================
|
||||
Feature: #108623 - Allow content element restrictions per colPos
|
||||
================================================================
|
||||
|
||||
See :issue:`108623`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
:ref:`Backend layouts<t3coreapi:be-layout>` have been extended with options to allow only
|
||||
configured types of content elements (referencing :sql:`tt_content.CType` with names like "text",
|
||||
"textmedia", "felogin_pi1" and so on) in backend layout columns (:sql:`colPos`): The two
|
||||
keys :typoscript:`allowedContentTypes` and :typoscript:`disallowedContentTypes` add allow and
|
||||
deny lists on column level. These settings can be set with Page TSConfig based backend layouts,
|
||||
Database based backend layouts do not allow configuring this value at the moment, but this will
|
||||
be added soon.
|
||||
|
||||
Example for a backend layout with two rows and two columns configured using Page TSConfig:
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
mod.web_layout.BackendLayouts {
|
||||
exampleKey {
|
||||
title = Example
|
||||
config {
|
||||
backend_layout {
|
||||
colCount = 1
|
||||
rowCount = 2
|
||||
rows {
|
||||
1 {
|
||||
columns {
|
||||
1 {
|
||||
identifier = main
|
||||
name = Main content
|
||||
colPos = 0
|
||||
allowedContentTypes = header, textmedia
|
||||
}
|
||||
2 {
|
||||
identifier = right
|
||||
name = Panel right
|
||||
colPos = 1
|
||||
allowedContentTypes = my_custom_cta
|
||||
}
|
||||
}
|
||||
}
|
||||
2 {
|
||||
columns {
|
||||
1 {
|
||||
identifier = footer
|
||||
name = Footer
|
||||
colpos = 2
|
||||
colspan = 2
|
||||
disallowedContentTypes = header
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
The implementation adapts the "New content element wizard" to show only allowed (or not disallowed)
|
||||
content elements types when adding a content element to a column. When editing records, the select
|
||||
boxes "Type" and Column position" are reduced to not allow invalid values based on the configuration.
|
||||
Similar logic is applied when moving and copying content elements.
|
||||
|
||||
The feature has been created with extension `content_defender<https://extensions.typo3.org/extension/content_defender>`__
|
||||
in mind. This extension by Nicole Hummel has been around for many years and found huge adoption rates
|
||||
within the community. In comparison to content_defender, the core configuration is slightly simplified
|
||||
and the core implementation does not provide the additional content_defender feature to restrict the number
|
||||
of elements per column (:typoscript:`maxitems`).
|
||||
|
||||
The core implementation supports the content_defender syntax using the arrays :typoscript:`allowed.CType` and
|
||||
:typoscript:`disallowed.CType`. With the example below, :typoscript:`allowed.CType` is internally mapped to
|
||||
:typoscript:`allowedContentTypes`. When both :typoscript:`allowed.CType` and :typoscript:`allowedContentTypes`
|
||||
are given, :typoscript:`allowed.CType` is ignored.
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
mod.web_layout.BackendLayouts {
|
||||
exampleKey {
|
||||
config {
|
||||
backend_layout {
|
||||
rows {
|
||||
1 {
|
||||
columns {
|
||||
1 {
|
||||
allowed {
|
||||
CType = header, textmedia
|
||||
[...]
|
||||
|
||||
Codewise, the PSR-14 event :php:`ManipulateBackendLayoutColPosConfigurationForPageEvent` has been added. It allows manipulation
|
||||
of the calculated column configuration. It is marked :php:`@internal` and thus needs to be used with care since it may
|
||||
change in the future without further note: The event is not dispatched as systematically as it should be, but refactoring
|
||||
the surrounding code can probably not be provided with TYPO3 v14 anymore. Extensions like ext:container however
|
||||
must be able to adapt column configuration with TYPO3 v14 already. The decisions was to provide an event, but to mark
|
||||
it internal for the time being, declaring it as "use at your own risk" if you know what you are doing and within extensions
|
||||
that set up proper automatic testing to find issues if the core changes internals.
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Backend layout columns can now restrict, which content element types are allowed or disallowed inside of it.
|
||||
|
||||
|
||||
.. index:: Backend, TSConfig, ext:backend
|
||||
+74
@@ -0,0 +1,74 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-108627-1736780000:
|
||||
|
||||
=====================================================================
|
||||
Feature: #108627 - Allow adding inline language domains to JavaScript
|
||||
=====================================================================
|
||||
|
||||
See :issue:`108627`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The new method :php:`PageRenderer->addInlineLanguageDomain()` allows loading
|
||||
all labels from a language domain and making them available in JavaScript
|
||||
via the :js:`TYPO3.lang` object.
|
||||
|
||||
The domain name follows the format `extension.domain` (e.g. `core.common`,
|
||||
`core.modules.media`).
|
||||
The language file is resolved automatically by the LanguageService, resolving
|
||||
to files like :file:`EXT:core/Resources/Private/Language/locallang_common.xlf`
|
||||
and :file:`EXT:core/Resources/Private/Language/Modules/media.xlf`.
|
||||
|
||||
See :ref:`translation domain syntax <feature-93334-translation-domain-format>`
|
||||
for more details.
|
||||
|
||||
Labels are automatically prefixed with the domain name and accessible as
|
||||
:js:`TYPO3.lang['domain:key']`, e.g. :js:`TYPO3.lang['core.common:notAvailableAbbreviation']`.
|
||||
|
||||
Example
|
||||
=======
|
||||
|
||||
.. code-block:: php
|
||||
:caption: EXT:my_extension/Classes/Controller/MyController.php
|
||||
|
||||
use TYPO3\CMS\Core\Page\PageRenderer;
|
||||
|
||||
final class MyController
|
||||
{
|
||||
public function __construct(
|
||||
private readonly PageRenderer $pageRenderer,
|
||||
) {}
|
||||
|
||||
public function myAction(): void
|
||||
{
|
||||
// Load all labels from the 'myextension.frontend' domain
|
||||
$this->pageRenderer->addInlineLanguageDomain('myextension.frontend');
|
||||
}
|
||||
}
|
||||
|
||||
The labels are then available in JavaScript:
|
||||
|
||||
.. code-block:: javascript
|
||||
:caption: EXT:my_extension/Resources/Public/JavaScript/my-script.js
|
||||
|
||||
// Access a label from the domain
|
||||
const label = TYPO3.lang['myextension.frontend:button.submit'];
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Previously, it was possible to load entire language files using
|
||||
:php:`addInlineLanguageLabelFile()` (which is still available), but labels
|
||||
were added without any prefix.
|
||||
This could lead to naming conflicts when multiple extensions used the same
|
||||
label keys, potentially overriding each other's translations.
|
||||
|
||||
With the new domain-based approach, all labels are automatically prefixed
|
||||
with the domain name (e.g. `myextension.frontend:label.key`). This provides
|
||||
a unified, namespaced access pattern that eliminates the risk of collisions
|
||||
between labels from different extensions or language files.
|
||||
|
||||
|
||||
.. index:: JavaScript, PHP-API, ext:core
|
||||
+59
@@ -0,0 +1,59 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-108663-1737166800:
|
||||
|
||||
====================================================================
|
||||
Feature: #108663 - Adjust visibility of form elements in Form Editor
|
||||
====================================================================
|
||||
|
||||
See :issue:`108663`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The Form Editor now provides the ability to configure the visibility of form
|
||||
elements. This allows form administrators to control which form elements are
|
||||
displayed or hidden in the form, providing better control over the form structure
|
||||
and user experience.
|
||||
|
||||
Usage
|
||||
-----
|
||||
|
||||
When editing a form element in the Form Editor, a new "Visibility" option is
|
||||
available in the element's configuration panel. This option allows you to:
|
||||
|
||||
* Show the element (default behavior)
|
||||
* Hide the element
|
||||
|
||||
The visibility setting is stored in the form definition and is evaluated when
|
||||
the form is rendered on the frontend.
|
||||
|
||||
Example for Integrators
|
||||
------------------------
|
||||
|
||||
If you want to extend your own form elements with the visibility feature, you
|
||||
need to add the following configuration to the element definition:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
prototypes:
|
||||
standard:
|
||||
formElementsDefinition:
|
||||
CustomElement:
|
||||
formEditor:
|
||||
editors:
|
||||
# Choose a key / position according to your own needs
|
||||
240:
|
||||
identifier: enabled
|
||||
templateName: Inspector-CheckboxEditor
|
||||
label: formEditor.elements.FormElement.editor.enabled.label
|
||||
propertyPath: renderingOptions.enabled
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
This feature improves the usability of the Form Editor and makes it more accessible
|
||||
to non-technical users who need to manage form visibility.
|
||||
|
||||
.. index:: Backend, ext:form
|
||||
|
||||
+31
@@ -0,0 +1,31 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-108694-1737323400:
|
||||
|
||||
==========================================================================
|
||||
Feature: #108694 - Context menu items to edit site configuration for pages
|
||||
==========================================================================
|
||||
|
||||
See :issue:`108694`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Two new context menu items have been added for pages that are site roots:
|
||||
|
||||
* **Edit Site**: Opens the site configuration editor for the site associated
|
||||
with the page.
|
||||
* **Edit Site Settings**: Opens the site settings editor for the site.
|
||||
|
||||
These items appear directly after the "Edit" item in the context menu and are
|
||||
only visible to admin users on pages that have a site configuration.
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Admin users can now quickly access the site configuration and site settings
|
||||
directly from the context menu when right-clicking on a site root page. This
|
||||
improves the workflow for managing sites without needing to navigate to the
|
||||
Site Management module first.
|
||||
|
||||
.. index:: Backend, ext:backend
|
||||
+72
@@ -0,0 +1,72 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-107088-1753085420:
|
||||
|
||||
=======================================================================
|
||||
Feature: #107088 - Allow to utilize password validators in Install Tool
|
||||
=======================================================================
|
||||
|
||||
See :issue:`107088`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The TYPO3 Install Tool password can now utilize validators as defined
|
||||
via the :php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['passwordPolicies']['installTool']['validators']`
|
||||
array. By default, this re-uses the `default` validator
|
||||
:php:`\TYPO3\CMS\Core\PasswordPolicy\Validator\CorePasswordValidator` with the configuration:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'SYS' => [
|
||||
'passwordPolicies' => [
|
||||
'installTool' => [
|
||||
'validators' => [
|
||||
\TYPO3\CMS\Core\PasswordPolicy\Validator\CorePasswordValidator::class => [
|
||||
'options' => [
|
||||
'minimumLength' => 8,
|
||||
'upperCaseCharacterRequired' => true,
|
||||
'lowerCaseCharacterRequired' => true,
|
||||
'digitCharacterRequired' => true,
|
||||
'specialCharacterRequired' => true,
|
||||
],
|
||||
'excludeActions' => [],
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
|
||||
This will require 8 characters minimum (as it was before) and now also require
|
||||
at least one upper-case, one lower-case, one digit and one special character.
|
||||
|
||||
The validator is utilized in both scenarios when setting the Install Tool password
|
||||
via CLI (`bin/typo3 install:password:set`) as well as the Install Tool GUI via
|
||||
:guilabel:`Admin Tools > Settings > Change Install Tool Password` in the TYPO3 backend.
|
||||
|
||||
If a password is auto-generated via the mentioned CLI command, by default it uses
|
||||
8 characters. The password-length for adapted validator configurations can then be
|
||||
specified with the new `--password-length=XXX` argument.
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Maintainers now need to set secure Install Tool passwords and can configure
|
||||
validation rules.
|
||||
|
||||
Existing Install Tool passwords are not affected, making this a non-breaking feature.
|
||||
However, these should be revisited by maintainers and maybe set to a more secure
|
||||
password.
|
||||
|
||||
To disable password policies (not recommended!), the configuration option
|
||||
:php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['passwordPolicies']['installTool']['validators']`
|
||||
can be set to an empty array (or null).
|
||||
|
||||
.. hint::
|
||||
|
||||
Please note, you can only override this configuration directive through the
|
||||
`additional.php` configuration file, otherwise an empty array or null value
|
||||
will trigger merging the `DefaultConfiguration` over the defined settings,
|
||||
and re-adding default validators to your setup.
|
||||
|
||||
.. index:: CLI, ext:core, ext:install
|
||||
@@ -0,0 +1,80 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _important-107971-1730384000:
|
||||
|
||||
==========================================================
|
||||
Important: #107971 - XLF files now use 2-space indentation
|
||||
==========================================================
|
||||
|
||||
See :issue:`107971`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
TYPO3 Core XLF (XLIFF) translation files now consistently use 2-space
|
||||
indentation instead of tabs. This aligns with the formatting used by Crowdin
|
||||
and by PHP's :php:`\DOMDocument`. The :file:`.editorconfig` file has been updated
|
||||
accordingly.
|
||||
|
||||
In addition to indentation, all XLF files have been normalized using a unified
|
||||
XML formatter. This ensures consistent XML declaration, attribute ordering, and
|
||||
whitespace structure across all XLF files in the Core.
|
||||
|
||||
Checking and normalizing XLF formatting
|
||||
=======================================
|
||||
|
||||
A new script has been introduced to check and normalize XLF formatting.
|
||||
|
||||
Checking formatting via `runTests.sh`
|
||||
-------------------------------------
|
||||
|
||||
To check whether XLF files have correct formatting (dry-run, no modifications):
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
./Build/Scripts/runTests.sh -s normalizeXliff -n
|
||||
|
||||
This command scans all XLF files in :file:`typo3/sysext/` and reports files that
|
||||
would be changed.
|
||||
|
||||
Normalizing XLF files via `runTests.sh`
|
||||
---------------------------------------
|
||||
|
||||
To normalize all XLF files in-place:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
./Build/Scripts/runTests.sh -s normalizeXliff
|
||||
|
||||
This command applies consistent indentation and XML normalization to all XLF
|
||||
files in :file:`typo3/sysext/`.
|
||||
|
||||
Using the standalone script
|
||||
---------------------------
|
||||
|
||||
The script can also be run directly. Requires PHP 8.2+ with DOM and intl
|
||||
extensions enabled.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# Show help
|
||||
./Build/Scripts/xliffNormalizer.php --help
|
||||
|
||||
# Check files only (dry-run)
|
||||
./Build/Scripts/xliffNormalizer.php --root typo3/sysext --dry-run
|
||||
|
||||
# Normalize files in place
|
||||
./Build/Scripts/xliffNormalizer.php --root typo3/sysext
|
||||
|
||||
# Check a custom directory
|
||||
./Build/Scripts/xliffNormalizer.php --root path/to/xlf/files --dry-run
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Extension developers should update their XLF files to use 2-space indentation
|
||||
and expect normalized XML formatting.
|
||||
The provided script can also be used within extensions to keep XLF files
|
||||
consistent with TYPO3 Core standards.
|
||||
|
||||
.. index:: Backend, Localization, XLF
|
||||
@@ -0,0 +1,55 @@
|
||||
:template: changelogOverview.html
|
||||
|
||||
.. include:: /Includes.rst.txt
|
||||
.. _changelog-14-1:
|
||||
|
||||
============
|
||||
14.1 Changes
|
||||
============
|
||||
|
||||
**Table of contents**
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
:depth: 1
|
||||
|
||||
Breaking Changes
|
||||
================
|
||||
|
||||
None since TYPO3 v14.0 release.
|
||||
|
||||
.. attention::
|
||||
|
||||
After TYPO3 v14.0, only new functionality with a solid migration path
|
||||
can be added on top, with aiming for as little as possible breaking changes
|
||||
after the initial v14.0 release on the way to LTS.
|
||||
|
||||
Features
|
||||
========
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:titlesonly:
|
||||
:glob:
|
||||
|
||||
Feature-*
|
||||
|
||||
Deprecation
|
||||
===========
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:titlesonly:
|
||||
:glob:
|
||||
|
||||
Deprecation-*
|
||||
|
||||
Important
|
||||
=========
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:titlesonly:
|
||||
:glob:
|
||||
|
||||
Important-*
|
||||
Reference in New Issue
Block a user