- Aug 30, 2024
-
-
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:
Garvin Hicking <gh@faktor-e.de> Reviewed-by:
Stefan Bürk <stefan@buerk.tech> Tested-by:
Simon Praetorius <simon@praetorius.me> Reviewed-by:
core-ci <typo3@b13.com> 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:
Benni Mack <benni@typo3.org> Tested-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:
Mathias Brodala <mbrodala@pagemachine.de> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> 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:
Benjamin Franzke <ben@bnf.dev> Tested-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:
Simon Schaufelberger <simonschaufi+typo3@gmail.com> Reviewed-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:
Jasmina Ließmann <minapokhalo+typo3@gmail.com> 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 Hader <oliver.hader@typo3.org> 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 Bartsch <bo@cedev.de> Reviewed-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:
-
Wouter Wolters authored
In docblock tag "Null_" interface "StaticMethod" is used. However this contract is totally covered by Tag contract. Resolves: #104762 Releases: main Change-Id: Icac4e3ba24269d3ef2e0db15f4d670bab229e2b7 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85810 Reviewed-by:
-
Oliver Bartsch authored
Resolves: #104759 Releases: main Change-Id: I57fdcacc75c3c2c7453ebbc484aef19d1135ae48 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85806 Reviewed-by:
Nikita Hovratov <nikita.h@live.de> Reviewed-by:
-
Torben Hansen authored
The `getProcessedElements` function in `FlexFormValueFormatter` throws an undefined array key exception, when the given dataStructure contains a field with a relation table having a `label_userFunc` and when the given valueStructure does not contain a value for the field. This change adds a fallback to an empty string, when `$valueStructure[$elementKey]['vDEF']` is not set. Resolves: #104760 Releases: main, 12.4 Change-Id: I133028b341d6df10a32f56858f8be8cfe951625a Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85808 Tested-by:
-
Stefan Bürk authored
This change modifies `TcaFolder` to get `ResourceFactory` injected instead of retrieving it using `GeneralUtility`. Resolves: #104752 Releases: main Change-Id: I14e2cd24e08a15e317e185918c7fe4aa10d01401 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85797 Reviewed-by:
-
Christian Kuhn authored
Inline some methods into getContextSpecificViewConfiguration() and adapt tests. Note the calling fillDefaultsByPackageName() will see a deprecation soon, this change is a preparation to make that patch better readable. Resolves: #104761 Releases: main Change-Id: Ibb2bacb2de4fc98488701ada0480220c8d394041 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85807 Reviewed-by:
-
Stefan Bürk authored
Stateful services come with a lot of drawbacks and needs to be avoided. The `ResourceFactory` holds state in form of internal instance cache properties, which cannot be cleared. Clearing these cache states can be a vital task in long running worker processes, migration tasks or similar things. In the current form, class instances retrieved from the Symfony DI container are not set into the internal GeneralUtility instance cache and cannot be removed from it. Even if that would be possible, the state would be hold in the DI container due to the nature of being a shared service. This change modifies the `ResourceFactory` to use the `core.runtime` transient cache instead, which allows clearing the state if needed. Note that removing `SingletonInterface` from `ResourceFactory` is not yet possible and needs some other changes first. Resolves: #104728 Releases: main Change-Id: I6a632722ae3b3e28c0cf53301f9d8f0b2c103c4f Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85775 Reviewed-by:
-
Wouter Wolters authored
In class InterfaceMethodChangedMatcher constants MODIFIER_PUBLIC and MODIFIER_STATIC are used. Both are deprecated. Use Modifiers::PUBLIC and Modifiers::STATIC instead. Resolves: #104757 Releases: main Change-Id: Ief2f6a41ce1a95a980a318539784f8abf48fe61a Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85804 Reviewed-by:
-
- Aug 27, 2024
-
-
Sébastien Delcroix authored
Adjusted indentation syntax which was breaking the rendering of feature #96874 changelog entry of the CKEditor 5 documentation. Removed the duplicated part about "editor.config.stylesSet", too. Resolves: #104751 Releases: main, 12.4 Change-Id: I57e506df6a379e18c0bd63805c51767781e260ad Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85796 Tested-by:
-
Till Hörner authored
Resolves: #104749 Releases: main, 12.4, 11.5 Change-Id: I0285dbeb8cabd4dc338797b6b47d3312ca2b9bb3 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85795 Tested-by:
-
Markus authored
In `getUrl()` only a `\GuzzleHttp\Exception\RequestException` is caught. This piece of code exists since April 20, 2016. At that time `ConnectException` and `RequestException` were not yet separated in Guzzle. But that changed in January 2020 and since then, they both extend `TransferException`. Thus, now `TransferException` is caught, which includes errorhandling for both a `RequestException` + `ConnectException`, see [1]. [1] https://github.com/guzzle/guzzle/blob/7.9.2/UPGRADING.md?plain=1#L22 Releases: main, 12.4 Resolves: #104706 Change-Id: I650e27c226f297300e6d9043fa220517543a3cd2 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85733 Tested-by:
-
Christian Kuhn authored
To reduce mocking and GeneralUtility instance tampering, a couple of error handling related tests are turned into functional tests. Also, a data provider case that misuses an unrelated class is removed. Resolves: #104755 Releases: main Change-Id: I0e33ec87a46d4c948a52388fc388cdd4e6780def Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85801 Tested-by:
-
Christian Kuhn authored
Resolves: #104754 Releases: main Change-Id: Id1164684fcbcf2bc1bdaa2dbbe74f73d2c608fb3 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85800 Tested-by:
-
Stefan Bürk authored
This change upgrades the version of the used `typo3/core-testing-php84` image [1], which uses PHP8.4 beta3 now along a new version of composer (2.7.8). [1] https://git.typo3.org/typo3/CI/testing-infrastructure/-/commit/bd98c246f5f8e5e91ee835212122998ffa5a1298 Resolves: #104748 Releases: main, 12.4, 11.5 Change-Id: I6555332a05e5809e30381c3a6b363a84c0150815 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85794 Tested-by:
-
Christian Kuhn authored
* Refactor LoginController. Code is much better readable now and class is nearly stateless. * Remove heavily mocking LoginController unit tests that don't add value. * Clean up LoginProviderResolver towards a stateless service, adapt tests. * AuthenticationStyleInformation is a stateless service. Resolves: #104745 Related: #104743 Related: #104744 Releases: main Change-Id: I856ac619577d93f0ea7119502bf7de1eca7f30e8 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85790 Reviewed-by:
Andreas Nedbal <andy@pixelde.su> Tested-by:
-
Wouter Wolters authored
Support for PHP 8.4 added. https://phpstan.org/blog/phpstan-1-12-road-to-phpstan-2-0 > composer req --dev phpstan/phpstan:^1.12.0 Releases: main, 12.4 Resolves: #104746 Change-Id: Ib2df8fce54a71d96bc8fc455ce27fc50c1b6e9fc Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85792 Tested-by:
-
Christian Kuhn authored
Some setUp() code is not triggered and thus obsolete. Resolves: #104747 Releases: main Change-Id: I72099d5d09bf36f83c381f3e12415a73e4190e56 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85791 Reviewed-by:
-
Lina Wolf authored
The module "TypoScript Record Overview" also contains site sets since #103439. The module labels are therefore generalized into "TypoScript Overview". Also show which entries are site sets and which are records. Resolves: #104730 Releases: main Change-Id: I83877d0a1ef5efdf6f1a82caedaed542bceb68d9 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85776 Tested-by:
-
Christian Kuhn authored
Logout should run through LogoutController. Avoid this widely unknown code in LoginController since it does not belong there and does not log. Resolves: #104744 Related: #104742 Releases: main Change-Id: Id535d620d4e72daf48ff05da6253de296df9f752 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85789 Reviewed-by:
Andreas Kienast <a.fernandez@scripting-base.de> Tested-by:
-
Lina Wolf authored
When TypoScript is provided by a site set, not a sys_template record and the site has no "website title" it is currently listed without any label in the "TypoScript records overview". However, the "website title" is not a mandatory field. Fall back to the site identifier if there is not website title. The identifier is mandatory and unique. Resolves: #104731 Releases: main Change-Id: I7727fb966443fe55e525bdc6fa6b44a67ecbefc4 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85777 Reviewed-by:
-
Christian Kuhn authored
There is ancient BE login related server side code to detect if cookies can be set. This never kicks in and is removed with the patch. When 'setting cookies' is disallowed in a browser (see instructions for firefox in issue), JS showCookieWarning() detects this and enables an info box. If JS is disabled as well, a default enabled info box "Please enable JavaScript" is shown. We're safe client side and can remove the server side check that triggers a fishy reload for detection. Resolves: #104742 Releases: main Change-Id: Id2585f77f097fd538766053d2b79cc40497737f6 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85787 Tested-by:
-
Benjamin Franzke authored
Executed commands: npm --prefix overrides/ckeditor5 version 43.0.0 npm install --save ./overrides/ckeditor5 $( grep @ckeditor/ package.json | \ grep -v @ckeditor/ckeditor5-dev-utils | \ grep -v @ckeditor/ckeditor5-inspector | \ sed 's/^[^"]*"\([^"]*\)".*/\1@43.0.0/' \ ) npm install --save-dev @ckeditor/ckeditor5-dev-utils@42.0.1 npm run build Releases: main, 12.4 Resolves: #104715 Change-Id: I6b954046451c53a49374459dbf18359fd9b346bc Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85745 Reviewed-by: -
Lina Wolf authored
This patch adds a description on how to utilize site sets from `EXT:fluid_styled_content` and the supported configuration directives, autogenerated from the settings.definitions.yaml file. Resolves: #104596 Releases: main Change-Id: Ie4215c70f24d579be06d086f19deae4c277e633f Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85590 Reviewed-by:
Chris Müller <typo3@brotkrueml.dev> Reviewed-by:
-
Benni Mack authored
What does it do? When creating a record object out of a database row (via the RecordFactory), the Record object now holds enriched values for fields where the content is "known" based on TCA / Schema API. This is especially relevant for records with possible relations, for field types such as "type=group", "type=select" with foreign_table set and "type=inline" as an example. The main purpose for this relation enriching is rendering of the backend page module and content in frontend, but it can be used for any kind of TCA-based record. It also works recursively and with circular dependencies thanks to the RecordIdentityMap. In order to avoid any problems with large amounts of data, an approach of "Lazy+Greedy Fetching" was chosen. How does this approach work under the hood? As an example, we load 10 content elements on a page (1 DB query) so we can render them. Step 1: Lazy Collections / RecordPropertyClosure RecordFactory filters out only the relevant fields and their values from a record's type. Now, the RecordFactory also checks for fields with their meaning and uses a different value for a field. Example: For a type=inline value, there was the number "5" as value (= 5 relations) available, now we know we need the relation records (as a collection) properly sorted resolved there as well. For this to work, the new RecordFieldTransformer creates LazyCollection objects or RecordPropertyClosure objects (for a 1:1/n:1 relation) which means that the DB query is not made (yet) but only called when the value is accessed for the first time ("lazy loading"). Step 2: Getting the related UID/Table Pairs The RecordIdentityMap now knows about the 10 Records from tt_content, as they have been created completely before handing it to the output rendering. There comes the fun part. As soon as the value (with a lazy closure) is accessed for the first time, the RelationResolver checks the RelationHandler to find the table / uids that we should resolve. In our case, we now know that our first content element has 5 relations to a DB table e.g. "tx_mycarousel_item" with UIDs 12,13,14,15,16. Thanks to the RelationHandler, we also have the proper sorting of these items. Step 3: A greedy database query to get the full DB rows So, for the first content element, we want the 5 complete, related DB rows. The RelationResolver now sends this query to the "GreedyDatabaseBackend" which uses a subquery to not only fetch the 5 DB rows, but ALL rows of this DB table that are on the same PID with 1 DB query (using subselects). It however only returns the 5 items, and keeps the other items in a runtime cache. At this point we have made 3 DB queries. Currently, we then do the language + workspace overlays. Step 4: The long way back The RelationResolver now has the full DB rows and sorts them. The RecordFieldTransformer builds Record / Collection objects out of it, checks if an object has been created already (via the IdentityMap) or creates new ones, utilizing again the Lazy approach from step 1 to ensure we only resolve the records when we need them. Responsibilities: - RecordFieldTransformer - knows what to do based on the Field Type - returns objects, never raw DB records - initializes the lazy collections / closure objects - RelationResolver - uses RelationHandler to resolve uids - knows and applies the sorting - GreedyDatabaseBackend - does overlays / enableFields The design decisions behind this approach: - We only build Record objects when they are requested explicitly - We distinguish the cardinality (1:1 / n:1 vs. 1:n) - We do overlays on a very end of the chain Kudos to Nikita Hovratov for creating the first draft of this approach here: https://review.typo3.org/c/Packages/TYPO3.CMS/+/83725 along with comprehensive tests. PS: In the mid-term, the RelationResolver could be based on the sys_refindex and minimize queries. Resolves: #103581 Related: #103783 Related: #104002 Releases: main Change-Id: I73d1f017c5f98115f7ad4ddd2634b7acf66d183c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85046 Tested-by:
-
- Aug 26, 2024
-
-
Lina Wolf authored
This patch adds a description on how to utilize site sets from `EXT:felogin` and lists the supported configuration directives, autogenerated from the settings.definitions.yaml file. Also some wording changes and typo-fixes in the settings definitions file are applied, and fe-login special notices are added. Resolves: #104597 Releases: main Change-Id: I14ccef4c2ac5e6d93a39c8a2d41301dd1ab99a3c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85594 Reviewed-by:
-
Philipp Kuhlmay authored
This sets the correct code-block caption definitions for the YAML and PHP code blocks so they will be rendered correctly. Resolves: #104716 Releases: main, 12.4, 11.5 Change-Id: Ic1ecc908c5e84f0c72180e4402296a78211263b3 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85749 Tested-by:
-
