- Sep 05, 2024
-
-
Oliver Bartsch authored
The "script" typeicon definition is removed since no such CType exists. Resolves: #104830 Releases: main Change-Id: I6d733a3d87a916e616407bd9f7681ebf8bd03184 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85897 Tested-by:
Oliver Hader <oliver.hader@typo3.org> Reviewed-by:
Benni Mack <benni@typo3.org> Tested-by:
core-ci <typo3@b13.com> Reviewed-by:
-
Philipp Kuhlmay authored
The WidgetRegistration.rst had a wrong indentation inside the example. Resolves: #104829 Releases: main Change-Id: Ia4e4e02bba65d036363dfea3fb391c16b1fd1749 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85896 Tested-by:
Chris Müller <typo3@brotkrueml.dev> Tested-by:
Garvin Hicking <gh@faktor-e.de> Tested-by:
-
Oliver Bartsch authored
The extbase data and column mapping is now properly using the TCA schema API. While streamlining the code some divergences regarding relation handling have been observed (e.g. use of "maxitems" and "renderType" options). Those will be tackled separately, since streamlining this might be breaking. Resolves: #104808 Releases: main Change-Id: I5aedf761372a4c14da76619a85f931a411b1dcb9 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85811 Tested-by:
Stefan Bürk <stefan@buerk.tech> Reviewed-by:
Oliver Bartsch <bo@cedev.de> Reviewed-by:
-
Nikita Hovratov authored
This change adds system fields - as defined in the ctrl section - of tt_content to the showitem field list automatically. This is either done based on palettes that already exist or adding the fields individually to the corresponding tabs. Tabs that are therefore added automatically are: * General tab at the beginning * Language tab including language fields * Access tab including hidden+access fields * Description tab including descriptionColumn In case the showitem of such type defines the "Extended" tab, it is added at the end. We do this for tt_content because we want a unified way of how FormEngine renders the fields. Resolves: #104814 Releases: main Change-Id: I69965fbc74ae2192151ad2617c1a88cf1eb2a987 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85859 Tested-by:
Nikita Hovratov <nikita.h@live.de> Tested-by:
-
Chris Müller authored
The given migration examples were not really practical, as an integrator does not return an array, but use either the API for adding a new content element/plugin, or manipulate the TCA array directly via `Configuration/TCA/Overrides/tt_content.php` for adding `saveAndClose` or `defaultValues`. To ease the work for integrators when migrating to the new options, the examples have been improved. Additionally, captions for the files have been added to ease grasping the context of the examples. Resolves: #104806 Related: #102834 Releases: main Change-Id: Idc840c611751be79dec475d372c9a2f29d23f32f Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85860 Tested-by:
-
Simon Praetorius authored
`fillFromConfigurationArray()` has been deprecated with Fluid v2.15. Instead, we use the new ViewFactory to create a Fluid view. Resolves: #104822 Releases: main Change-Id: I6b034452b27c8c66f72880f1608285053fcf6bf7 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85861 Tested-by:
Markus Klein <markus.klein@typo3.org> Reviewed-by:
Simon Praetorius <simon@praetorius.me> Tested-by:
-
- Sep 04, 2024
-
-
Garvin Hicking authored
This is an effort to document the steps that were made in issue #104786 to allow developers and probably integrators to migrate affected ViewHelpers easier. The goal is to lower unneeded fears of possibly complex migrations, because the steps can actually be performed mostly even with search+replace. Resolves: #104824 Related: #104799 Related: #104789 Related: #104786 Releases: main Change-Id: I06bd649c2ff9a4a84c31dfec9d9bcc7c6f2b81f8 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85893 Tested-by:
-
Markus Klein authored
Add more typehints and introduce helper methods to make the code more readable. Resolves: #104800 Releases: main Change-Id: I32c9e4a612f59df1f507f1f09b89fa9df772ea21 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85854 Reviewed-by:
Guido Schmechel <guido.schmechel@brandung.de> Tested-by:
Simon Schaufelberger <simonschaufi+typo3@gmail.com> Reviewed-by:
-
Till Hörner authored
A new CLI command `typo3 upgrade:mark:undone` has been introduced that allows to mark a previously executed upgrade wizard as undone so it can be run again. This makes the existing functionality from the install tool also available on CLI. Resolves: #104655 Releases: main Change-Id: I0d4601e3e81b447793586ddfc31e10bd40a87e64 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85672 Tested-by:
-
Simon Praetorius authored
With Fluid v4, renderStatic() and the associated traits are deprecated. ViewHelpers should use render() as their primary rendering method from now on. [1] Consequently we switch all ViewHelpers in the Core from renderStatic() to render(). This has been done in this patch. The following steps have been performed: 1. Use custom rector rule to perform changes (Patchset 1) > git clone git@github.com:s2b/fluid-rector.git > cd fluid-rector/ > composer install > vendor/bin/rector process ../typo3/ 2. Apply cgl fixes (Patchset 2) > Build/Scripts/runTests.sh -s cglGit 3. Manually migrate phpstan annotations (Patchset 3, partially reverted in Patchset 5) If `$arguments` is annotated in the ViewHelper class, that annotation is removed (either right in Patchset 3 or later in Patchset 5). 4. Manually migrate ViewHelpers that are not covered by rector rule (Patchset 4) [1] https://github.com/TYPO3/Fluid/commit/97aa45a6ed0fa3959cfa7d790077a4a5a9cef53f Resolves: #104786 Releases: main Change-Id: I503c3ba34d5926dd1e5818cd4114f0356bc68d89 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85834 Reviewed-by:
-
serbelanalog authored
This patch shows an example for the frontend login how to get a redirect when an unauthorized visitor tries to access a restricted page. In this case, a 403 ErrorHandler can perform a redirect with special parameters, that a properly configured felogin plugin can utilize to redirect back to. Resolves: #104694 Related: #101252 Releases: main, 12.4, 11.5 Change-Id: Ia2c6723621304b8b3de366590c1be905572b00d1 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85817 Reviewed-by:
Georg Ringer <georg.ringer@gmail.com> Tested-by:
-
Lina Wolf authored
This fixes the rendering warnings due to duplicate anchors and provides more structure in general. Also utilize API docs referencing for FQCNs. Resolves: #104712 Releases: main, 12.4, 11.5 Change-Id: I4e088dacec80a44d7c6e24ebb07582cbe84f72a2 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85742 Tested-by:
-
Torben Hansen authored
When TYPO3 is configured to create links to access protected pages using `typolinkLinkAccessRestrictedPages = NONE` (which is default), a 403 response is returned, if the current frontend request does not fulfill configured access permissions. This change introduces a new Site errorHandler, which can be used to handle 403 responses for access restricted pages and which redirects the user to a configured page and adds a configurable GET parameter (`return_url` or `redirect_url`) containing the original URL. The configurable GET parameter can be used by 3rd party extensions to redirect the user back to the original URL after a successful login. The TYPO3 extensions ext:felogin and ext:oidc both support the configurable redirect parameter introduced in the new Site errorHandler feature. Resolves: #101252 Releases: main Signed-off-by:
Torben Hansen <derhansen@gmail.com> Change-Id: I06d8e384c5519975efdc8803c98c0a92a56a7653 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/81945 Tested-by:
-
Mathias Brodala authored
With #100307 the authentication system got streamlined and prepared to pass the request and added on dispatched PSR-14 events. To mitigate breaking change nullable method parameter signature has been used along with keeping the fallback handling retrieving the global request or creating a valid request from globales within the `EmailLoginNotification` event listener. The code has been additionally adjusted for issues #100128 and #99864 in case of MFA authentication but missed to pass the request correctly to the added intermediate method. This change passes the request down to the event dispatching method which contains the application type request argument. To mitigate issues in systems using xclasses or test setups the fallback handling in `EmailLoginNotification` is modified to set the BE application type in case a request is created from globals. Both solution parts ensures to have a proper application type set and that `f:translate` viewhelper can be used in system mail templates. Resolves: #104809 Related: #100128 Related: #99864 Related: #100307 Releases: main, 12.4 Change-Id: Ib23a035bfed38c7dc03db111e42f6e98b12e3a4b Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85862 Tested-by:
Mathias Brodala <mbrodala@pagemachine.de> Tested-by:
-
Garvin Hicking authored
The module "EditModule" was removed with #87498, but the documentation reference remained. Instead of using this module as an example, instead "CacheModule" is referenced, since it addresses similar demonstration purposes. Backports are needed for proper documentation rendering. Resolves: #104802 Related: #87498 Releases: main, 12.4, 11.5 Change-Id: Iab25eec9aec9765f1c71f439c00ca34975d7e8a1 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85858 Reviewed-by:
-
Stefan Bürk authored
This change raises the phpstan package to ensure a stable check across version which is required due to changed detection behavior (bugfixes). Used command(s): > composer require --dev "phpstan/phpstan":"^1.12.1" > Build/Scripts/runTests.sh -s phpstanGenerateBaseline Resolves: #104813 Releases: main, 12.4 Change-Id: Ia196033a9340d3ce87691eec1da67d6169312962 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85865 Tested-by:
-
Oliver Bartsch authored
Adds missing search level selection to the search bar in the link browser for records. Resolves: #104683 Releases: main, 12.4 Change-Id: I71faf22a336b688e1d6f048c76a35bf0e117dc3c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85715 Tested-by:
Jochen Roth <rothjochen@gmail.com> Tested-by:
-
- Sep 03, 2024
-
-
Simon Praetorius authored
This release contains important pre-patches for the upgrade to Fluid v4 in the next step. Apart from soft deprecations of code that will log deprecation level errors with Fluid v4, it backports a feature from Fluid v4 to Fluid v2 to deliver a smoother migration path from Fluid v2 to v4 in 3rd party code. The necessary changes to TYPO3's ViewHelpers will be applied in a follow-up patch. Similarly to the previous update to 2.14.0, this patch adds RST files that describe both new features and deprecations that were introduced in this version. Noteworthy changes: * The functionality of `CompileWithContentArgumentAndRenderStatic` has been integrated into `AbstractViewHelper` and can thus be used with non-static ViewHelpers from now on. * `renderStatic()` and both associated traits `CompileWithContentArgumentAndRenderStatic` and `CompileWithRenderStatic` are deprecated * Methods deprecated with the introduction of the ViewFactoryInterface in #104773 have been deprecated in Fluid as well * `true`, `false` and `null` can no longer be used as variable names, as these will become proper language keywords in Fluid v4 Executed composer commands: > composer req typo3fluid/fluid > composer req -d typo3/sysext/adminpanel --no-update typo3fluid/fluid > composer req -d typo3/sysext/core --no-update typo3fluid/fluid > composer req -d typo3/sysext/fluid --no-update typo3fluid/fluid > composer req -d typo3/sysext/redirects --no-update typo3fluid/fluid Resolves: #104789 Related: #104463 Related: #104773 Releases: main Change-Id: I32a465e327cf84975c45e86580c54d060d688cd6 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85837 Tested-by:
-
- Sep 02, 2024
-
-
Garvin Hicking authored
With #103034 EXT:styleguide received a dependency on EXT:seo. This could lead to a situation for classic installations (non-composer mode) where via `PackageStates.php` the loading order was changed in a way that loaded EXT:dashboard before EXT:seo. This would lead to widgets defined in EXT:seo not getting displayed in the dashboard, because the registration would be performed too late. The easy fix for this is to adjust the file `ext_emconf.php` of EXT:seo to provide a 'suggest' key for EXT:dashboard. The expected PackageStates default in the functional tests are adapted to match that proper order. In case EXT:seo is enabled, this 'suggest' entry ensures that EXT:dashboard is loaded before EXT:seo, so that everything else falls into place. Please note that for composer installations this suggestion was already provided. For classic installations, [1] states: For non-Composer installation ("Classic Mode") the `ext_emconf.php` file is the source of truth for required dependencies and the loading order of active extensions. NOTE: To fix a possible ordering problem in existing installations, rebuilding `PackageStates.php` is needed. This can be done by enabling and disabling EXT:dashboard for example, through the Extension Manager. [1] https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/11.4/Important-95647-ComposerInstallationsAndExtensionUsage.html Resolves: #104717 Related: #103034 Related: #95647 Releases: main, 12.4 Change-Id: I13547b0ecf6bcb60abf2e3674d273413fb6f9a6c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85750 Reviewed-by:Benjamin Franzke <ben@bnf.dev> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
-
Oliver Hader authored
Prior to this change, empty sources to be assigned to an existing Content-Security-Policy directive have been ignored. Resolves: #104727 Releases: main, 12.4 Change-Id: I788c32a1772d929b2b974058b0afb746d936718c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85812 Reviewed-by:
-
Benjamin Franzke authored
We allow all node 22 in package.json, therefore nvmrc shouldn't pin to 22.0, but allow for local updates, without modifying this file for every minor release. Releases: main, 12.4 Resolves: #104792 Change-Id: I3a2dad2a5915ba0b2c8097b2bcc52903b7576b6b Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85840 Tested-by:
Benjamin Kott <benjamin.kott@outlook.com> Reviewed-by:
Marvin Buchmann <marvin.buchmann@typo3.com> Tested-by:
-
- Sep 01, 2024
-
-
Torben Hansen authored
The Fluid template file used in HtmlViewHelperTest functional tests contains a namespace declaration for ext:styleguide ViewHelpers, which however is not used in the test. This patch removes the superfluous namespace declaration. Resolves: #104791 Releases: main Change-Id: I36612c7d2637b264623e2a6de6f159fa44a231e1 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85839 Tested-by:
Oliver Klee <typo3-coding@oliverklee.de> Reviewed-by:
-
- Aug 31, 2024
-
-
Simon Praetorius authored
A ViewHelper shouldn't be called directly in a test case because its behavior is highly dependent on Fluid. Resolves: #104787 Releases: main Change-Id: Ib0e98d15231940cca31ff854ba76d21b2b719f8b Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85835 Reviewed-by:
-
- Aug 30, 2024
-
-
Jasmina Ließmann authored
Resolves: #104779 Releases: main Change-Id: If64ade32e87152dc0abe6a5b31ec2190e7dfeb46 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85825 Tested-by:
Jasmina Ließmann <minapokhalo+typo3@gmail.com> Reviewed-by:
-
Nikita Hovratov authored
Nowadays, it is not needed anymore to manually call IconRegistry to register icons. Since TYPO3 v11 we have the Configuration/Icons.php file, which should be enough for most use cases. This deprecation gives extension authors incentive to clean their ext_localconf.php files. Some background: This has become problematic with Content Blocks, as it uses service provider extension method to dynamically register icons. However, when other extensions instantiate IconRegistry in ext_localconf.php the WHOLE Content Blocks compiling is triggered at an early stage of bootstrapping, when TCA is not even available yet. This does not work and forces us to use a less clean method by listening to the BootstrapComplete event. Resolves: #104778 Related: #94692 Releases: main Change-Id: I8ee6d80e8979f506cd076236c577302e323af77a Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85662 Reviewed-by:
-
Simon Praetorius authored
Some type hints in TYPO3's TemplatePaths implementation need to be adjusted due to changes in the parent class. Also, `ensureAbsolutePath()` now only handles `string` as input, as the parent class is the only position the method is called and only strings are valid in that context. Resolves: #104783 Releases: main Change-Id: I89fddd085a2a5fde11df769964eb9d129587b569 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85830 Tested-by:
-
Simon Praetorius authored
Because the API has been introduced with Fluid v2, but hasn't been used by TYPO3 < 13.3, a few extra checks are necessary. Resolves: #104777 Releases: main Change-Id: If4bb29dc9b6b5b0e87ec73307a2a0bca285c4318 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85824 Reviewed-by:
-
Torben Hansen authored
With the deprecation of extbase `HashService`, the new core `HashService` was injected to extbase `HashService` using constructor DI. Instantiation of extbase `HashService` however does not work, because the service is defined by a service provider and the required constructor argument is missing. This change makes the extbase `HashService` injectable by DI again by removing it from the service provider definition and by defining it as public using `Autoconfigure` attribute. Resolves: #104780 Related: #102763 Releases: main Change-Id: Ife766b2306eff9ef263ba42c78dd58b1d1add27f Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85827 Tested-by:
-
Christian Kuhn authored
After a long list of preparation and side patches, this change introduces a central ext:core ViewFactoryInterface plus a default implementation for fluid, and rolls it out. We established a sub section of a generic view for backend modules with ext:backend BackendViewFactory in TYPO3 v12 already. This worked out well. The patch picks this up with a global factory interface for all other use cases that need to deal with views. This ultimately allows instances to change any view rendered by any component by configuring the instance to inject a different ViewFactoryInterface implementation to some controller and let it return an ext:core ViewInterface that uses some different view implemenation like Twig or whatever floats your boat. This is also very helpful for headless implementations to transparently substitute casual html rendering with for instance a json result. The patch decouples fluid much better and obsoletes the custom fluid view implementations ext:fluid StandaloneView, ext:fluid TemplateView and their abstract ext:fluid AbstractTemplateView. The previous ViewResolverInterface of extbase is obsoleted as well. The following architectural decisions have been taken: * ext:core ViewFactoryInterface has the single create() method that takes a ViewFactoryData data object to create an ext:core ViewInterface based on it. * ext:core ViewFactoryInterface should be *injected* whenever possible to allow instances reconfiguring the injection. Core has only a couple of places where this is not possible yet due to technical debt. An example is #104724. * The default injection of ViewFactoryInterface is ext:core FluidViewFactory. This returns an instance of the already established FluidViewAdapter, which acts as a facade to fluid standalone TemplateView. FluidViewAdapter implements all the specialities from the now deprecated custom ext:fluid view classes, so switching to this implementation within core is not considered breaking. Most of those compatibility methods are declared deprecated, though. Some are kept non-deprecated, due to technical debt in some consumers. * ext:core ViewFactoryData is a straight data object that is supposed to be set up by view consumers. It is about handing over the template paths entry points to the factory, requesting a preferred format if desired, and handing over PSR-7 request if possible. * The request is actively hand over in ViewFactoryData whenever possible within core usages, since it may help custom ViewFactoryInterface implementations to take decisions based on it: "If that's a ext:news controller action and if request type is json, then create my json view, otherwise fall back to default fluid view using FluidViewFactory". * The signature of ext:core ViewFactoryData is still kinda tailored towards fluid with the almighty template/layout/partial tuple, but it allows the core to go ahead in this area with TYPO3 v14, to potentially establish a better solution regarding template entry points in general. * Best use of the ViewFactoryData paths entry points tuple are the "extension template entry points", namely arrays of "EXT:myExt/Resources/Private/Templates", "EXT:myExt/Resources/Private/Layouts" and "EXT:myExt/Resources/Private/Partials". Only ext:form violates this once, which should be ruled out. * Single view rendering is best called using render('path/within/templateRootPath'): This has been established with BackendViewFactory for backend modules already, and gives the core a good place to kick in automatic path overlay handling later. Only extbase and TEMPLATEVIEW violate this at the moment, and we will see on how to continue on this. * In ViewFactoryData, "templatePathAndFilename" is the ugly kid in the block, we'll want to get rid of this when a general path lookup and overlay solution is established. The patch essentially adds the ViewFactoryInterface API, adds the default FluidViewFactory implementation, and changes all places that instantiated custom fluid view towards the new API. Notable specialities: * ext:adminpanel suffers from an architectual flaw that cripples DI on sub modules. GU::makeInstance(ViewFactoryInterface::class) solves this for now, but a solution should be handled with #104724 to allow injection of ViewFactoryInterface. * ext:backend LoginController follows a weird logic for extensions that take over login rendering to have own login fields. This needs a bigger overhaul that is out of scope of this patch. Since the existing API hard coded type hints for ext:fluid StandaloneView, there is currently no other way than mitigating this by introducing a new API method and triggering deprecations for extension that don't follow. * The patch reveals architecural flaws when creating emails via the FluidEmail construct where 'composition over inheritance' went wrong. This needs a redesign, the implementation is currently bound to fluid and throws an exception if the view is not an instance of FluidViewAdapter * Similar with FLUIDTEMPLATE content object: This implementation is heavily tailored towards fluid. This is ok'ish: When for instance a page rendering for 'headless' is called, those FLUIDTEMPLATE TypoScript definitions need to be changed to something else using TypoScript. The implementation now throws an exception if the view factory did not return a FluidViewAdapter view. * New v13 PAGEVIEW content object is changed to *not* relax on upper/lowercase template filenames for now: While we *do* want fluid to handle file and path casings more relaxed, this single use case is not the way to go. This needs to be solved on a more general level that requires more refactoring, find, and lookup magic on a lower level. To stay consistent with current fluid strategy, we for now remove the "ignore casing" feature of this content object, but it will hopefully see a revamp in v14. * extbase is (guess what?) problematic. The patch switches from ext:extbase ViewResolverInterface to ext:core ViewFactoryInterface and keeps using ViewResolverInterface as deprecated fallback. The extbase abstract ActionController "defaultViewObjectName" API is ugly, is a bit more restricted now, and will have to fall at some point. In v14, single actions should probably create a view explicitely when they need some, using a helper method provided by the abstract, or similar. The automagic view configuration is of course kept for now, but becomes more and more questionable. Resolves: #104773 Related: #101559 Related: #104724 Related: #103504 Releases: main Change-Id: Ic4603b55da1504a5f20b23468850a1a518684967 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85735 Reviewed-by:Anja Leichsenring <aleichsenring@ab-softlab.de> Tested-by:
-
Daniel Siepmann authored
Users might open URLs to backend modules. Those are checked for existence and permissions. But the permission check used the route identifier as module identifier. This is now fixed by resolving the route identifier to module identifier which is then used for permission checks. Resolves: #103938 Releases: main, 12.4 Change-Id: Ia2e7948a6073ec45b6b049b5d7040a52a5a0687e Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/84432 Reviewed-by:
-
- Aug 29, 2024
-
-
Garvin Hicking authored
The CKEditor default YAML configuration for the Full and Default presets contained code like: ``` - { name: 'Orange title H2', element: 'h2', classes: [], styles: { color: 'orange', background: 'blue' } } - { name: 'Orange title H3', element: 'h3', classes: [], styles: { color: 'orange', background: 'blue' } } - { name: 'Quote / Citation', element: 'blockquote', classes: [], } - { name: 'Code block', element: 'code', classes: [], } - { name: 'Yellow marker', element: 'span', classes: [], styles: { background-color: 'yellow' } } ``` and ``` - { name: "Lead", element: "p", classes: ['lead'] } - { name: "Small", element: "small", classes: [] } - { name: "Muted", element: "span", classes: ['text-muted'] } ``` CKEditor 5 expects the "classes" attribute to contain an array of strings (or just a string) and not an empty array. Otherwise choosing such a style will have no effect in the CKEditor instance. The CKEditor5Migrator class has been enhanced to convert these empty or absent arrays to a `['']` definition on the fly. This allows integrators to continue using their hard-earned CKEditor YAML configurations without further change. The default YAML presets have been changed to omit the classes attribute, as that's what the intention of the configuration is. While this is a proprietary TYPO3 modification, we need this because of limited CKEditor5 functionality regarding classes handling. Also, the no longer valid "styles:" definitions have been removed. Resolves: #103979 Resolves: #103499 Releases: main, 12.4 Change-Id: Iad6f1a25c071ac70b51db2a3344b7c3bcd9f9687 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/84679 Reviewed-by: -
Christian Kuhn authored
ext:form RendererInterface->setFormRuntime() now declares to return void. Strictly speaking this would be a breaking change, but it is not in practice, since extensions typically do not implement the interface directly, but extend AbstractElementRenderer, which follows this interface change. Also, existing extensions could easily declare :void (if they don't do so already), and be v13 and <v13 compatible without problems. Resolves: #104768 Releases: main Change-Id: I6d012946f84212c42235346fb8abae1651a37440 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85820 Reviewed-by:
-
Christian Kuhn authored
The MFA tests have an indirect dependency to FE/BE state of request. This is dealt with in other tests already, but a few are missing. Add proper setup. Resolves: #104771 Releases: main Change-Id: I9561cd810c90423692d941c40a3e5a9351889396 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85823 Tested-by:
-
Christian Kuhn authored
Instead of declaring ActionController->defaultViewObjectName to some value, __construct() sets it. This in line with the recommended solution of #102632: It relaxes liskov covariance and contravariance issues with PHP properties. Core usages now follow to be a good example for extensions. The patch applies minor constructor/DI cleanups along the way. Resolves: #104770 Related: #102632 Releases: main Change-Id: Ib013d1f52796d5e849b1e26d2173691ed7a6b310 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85822 Tested-by:
-
Christian Kuhn authored
Hard coded fluid code within the framework (except in fluid view helper tests) is not a good thing: It makes substituting the view with something else impossible. The patch extracts a setTemplateSource() to a file. This is a pre-patch to a general view factory implementation. Resolves: #104769 Releases: main Change-Id: Ifb95e274a276b15c882694735ccda4cdcb2130d9 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85821 Reviewed-by:
-
- Aug 28, 2024
-
-
Christian Kuhn authored
Add a series of type hints that are safe to set. Resolves: #104766 Releases: main Change-Id: I2143ff8b71109d0439bebf35a96514c1c176c832 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85818 Tested-by:
Wouter Wolters <typo3@wouterwolters.nl> Reviewed-by:
-
Christian Kuhn authored
TemplatePaths->fillDefaultsByPackageName() is located at the wrong place by having this magic within ext:fluid: It is the last piece of ext:fluid core (non-VH) classes that mixes extbase logic into fluid. The method is only triggered actively by extbase, and indirectly via parent __construct() in standalone fluid if the class is constructed with a string, which is not used by the core. The patch refactors the single consumer in extbase ActionController, which leads to simplified fluid path setup in that class. Two obsolete heavy mocking tests that don't add value bite the dust along the way. Even though ext:fluid TemplatePaths is marked @internal, the method is not removed directly but deprecated since it is used by quite a few extensions in practice, and it does not harm much to just let it log deprecation note in v13. Resolves: #104764 Releases: main Change-Id: Ia2fbcb38a6ef76f6aad41fcda927e3f32447ca9d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85813 Reviewed-by:
-
Oliver Hader authored
Related: #101580 Releases: main, 12.4 Change-Id: Idb58280ea86aace60087dc31a98634c9dd7432fd Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85814 Tested-by:
-
Oliver Bartsch authored
Array access of `uid` and `pid` has been enabled, therefore offsetExist() needs to return TRUE for those fields, too. Resolves: #104758 Releases: main Change-Id: I5d2b0ba67e91daa258702431cbbcdcc2427bf68b Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85805 Tested-by:
-
Oliver Hader authored
+ new feature flag `security.frontend.reportContentSecurityPolicy`, to be used next to `security.frontend.enforceContentSecurityPolicy`, resulting in `Content-Security-Policy-Report-Only` and/or `Content-Security-Policy` HTTP headers + new `enforce` and `report` segments in `csp.yaml` site config + possibility to disable CSP for a particular site by either setting `active: false` in the `csp.yaml` site config + allows having the HTTP headers `Content-Security-Policy` and `Content-Security-Policy-Report-Only` side-by-side in the frontend Resolves: #101580 Resolves: #104549 Releases: main, 12.4 Change-Id: I8c1a8305702629eac1bfedddbecbc19b452fd500 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85632 Tested-by:
-
