- Sep 15, 2024
-
-
Elias Häußler authored
The TSFE->cacheExpires property was removed in #102422. This patch removes an existing property access and replaces it with its successor in PrepareTypoScriptFrontendRendering middleware. Resolves: #104975 Related: #102422 Releases: main Change-Id: I106209ac5aa896abdd7838f6922cbb20f8411106 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/86105 Reviewed-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Tested-by:
Stefan Bürk <stefan@buerk.tech> Tested-by:
core-ci <typo3@b13.com> Reviewed-by:
-
Benni Mack authored
Instead of config.sendCacheHeaders which might have your users see the same content for a long time, it is recommended to use config.sendCacheHeadersForSharedCaches = auto instead, because this now sends the following HTTP Header: Cache-Control: max-age=0, s-maxage=12345 where as s-maxage is the number of seconds how long the proxy / CDN is allowed to cache, while the browser/client should never cache this. This way, the proxy can decide on how long to cache things. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control Resolves: #104914 Releases: main Change-Id: If121df42b22dd0027a8fd17e5bc434c4e67e612a Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/86007 Reviewed-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Benjamin Franzke <ben@bnf.dev> Tested-by:
-
- Sep 14, 2024
-
-
Sascha Nowak authored
A new API has been introduced to collect cache tags and their lifetime during frontend rendering. This API is used in the core to collect cache tags from page cache and content object cache. The API is implemented as a new PSR-7 request attribute `frontend.cache.collector` to remove the dependency from TSFE. Every cache tag has a lifetime. The minimum lifetime is calculated from all given cache tags. API users don't have to deal with it individually. The default lifetime for a cache tag is 86400 seconds (24 hours). The current TSFE api is deprecated in favor of the new API as the current API implementation does not allow to set a lifetime and extension authors have to workaround it. The TSFE api will be removed with the next major version. The frontend employs the following strategy: A relatively early middleware adds an empty new cacheDataCollector instance as attribute to request. Extensions rendering code based on database records can then add cache tags to this attribute. The FE rendering adds the final cache content, the middleware then compiles the final cache entries and triggers their persistence. There is an additional event `AddCacheTagEvent` the middleware listens to. It allows adding cache tags at places where the request is not available. This is a tribute to technical debt that can not be avoided at the moment. That event is however marked `@internal` and may vanish later. Resolves: #102422 Releases: main Change-Id: Ice7b3b8aba7c4df3e48d3895d6388f5641fdad63 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/81801 Tested-by:
Torben Hansen <derhansen@gmail.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Guido Schmechel <guido.schmechel@brandung.de> Tested-by:
Sascha Nowak <typo3@saschanowak.me> Reviewed-by:
-
- Sep 11, 2024
-
-
Oliver Bartsch authored
The RecordInterface is extended to require implementations to implement the `getRawRecord()` and `getSystemProperties()` methods as well as the PSR-11 `ContainerInterface`. This allows to change RecordFactory's `createRecord()` method to return the interface instead of the `Record` object. This will come in handy e.g. for the already existing `Page` object, which can now be used without extending `Record`. By using the `ContainerInterface` we allow access to the record and its properties via the has() and get() methods, which is supported since Fluid 4.0: https://github.com/TYPO3/Fluid/issues/1001. Resolves: #104859 Releases: main Change-Id: Ib8d20dc4eea343bf1c2160dbab6d4301930792ee Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85925 Reviewed-by:
Oliver Bartsch <bo@cedev.de> Tested-by:
-
- Sep 10, 2024
-
-
Thomas Hohn authored
If the 'contentSecurityPolicies' value is not filled properly in the site configuration, the call to $site->getConfiguration()['contentSecurityPolicies'] will fail. The access should we guarded with a null coalescing operator. Resolves: #104873 Releases: main, 12.4 Change-Id: Ie49a25d8ca9a194629c4a389b17b299091d44031 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85977 Reviewed-by:
Garvin Hicking <gh@faktor-e.de> Tested-by:
-
Oliver Bartsch authored
Move TypolinkParameter to EXT:core and therefore remove a dependency from EXT:core to EXT:frontend. Resolves: #104869 Related: #104615 Releases: main Change-Id: I7474d31a722a4e27438461b8812e25299f0a72cb Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85937 Tested-by:
Jochen Roth <rothjochen@gmail.com> Reviewed-by:
Nikita Hovratov <nikita.h@live.de> Reviewed-by:
-
- Aug 30, 2024
-
-
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 implemen...
-
- Aug 28, 2024
-
-
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:
Oliver Hader <oliver.hader@typo3.org> Tested-by:
-
- Aug 27, 2024
-
-
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 20, 2024
-
-
Oliver Bartsch authored
Resolves: #104639 Releases: main, 12.4, 11.5 Change-Id: I74a0cd9e856283d26a382582cc5d6b8e99887cd4 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85694 Tested-by:
Andreas Kienast <a.fernandez@scripting-base.de> Tested-by:
Oliver Klee <typo3-coding@oliverklee.de>
-
Oliver Bartsch authored
Resolves: #104665 Related: #103783 Releases: main Change-Id: I60bb7561f25a0c25068064890ee5deb474c183e4 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85681 Reviewed-by:
-
- Aug 15, 2024
-
-
Oliver Hader authored
Aims to combine disabling site-specific CSP with report-only mode later. This reverts commit acf70306. Reverts: #104549 Resolves: #104633 Releases: main, 12.4 Change-Id: I651f60d7b5cc24133801412c8f09b1efba98d3f4 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85646 Reviewed-by:
-
- Aug 14, 2024
-
-
Oliver Bartsch authored
This adds a new value object, containing the resolved parameters of a typolink. The object will be used as enriched value for TCA type "link" properties in the Record object. The enrichment will be added with #103581. Since this value is then passed to the view instead of the plain typolink string, the TypoLink ViewHelpers do also support the new object. Resolves: #104615 Related: #103581 Releases: main Change-Id: Ifbac6d44ed05d5d793b951b38229891d6b219eb4 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85619 Reviewed-by:
-
Oliver Hader authored
This change allows to disable CSP headers for a particular site configured in `sites/<my-site>/csp.yaml` by using the assignment `enable: false`. Resolves: #104549 Releases: main, 12.4 Change-Id: I9e17b5658610e5d47915a5e45ca6a33a870e8d76 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85591 Reviewed-by:
Georg Ringer <georg.ringer@gmail.com> Tested-by:
-
- Aug 06, 2024
-
-
Christian Kuhn authored
Resolves: #104557 Releases: main, 12.4, 11.5 Change-Id: I1bea6d74fc444007c8787e0a642c86b35a7ccb90 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85534 Tested-by:
Wolfgang Wagner <wwagner@wwagner.net> Reviewed-by:
-
- Jul 29, 2024
-
-
Thomas Hohn authored
In the RestoreRegisterContentObject::render method a call to array_pop is performed. The result is assigned to the variable $frontendController->register which has type array. However array_pop can return null, this patch add's a null coalesce operator to ensure that correct type. Resolves: #104495 Releases: main, 12.4, 11.5 Change-Id: I46efce10e4322ff3cd39b5a0eeafd1f768644e38 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85404 Reviewed-by:
-
- Jul 25, 2024
-
-
Christian Kuhn authored
FluidTemplateContentObject has some magic to adapt the given request *if* the request is an extbase request already. This code is relatively obviously obsolete: Only extbase bootstrap creates extbase requests (and actually, the code *below* the lines changed by this patch in FluidTemplateContentObject, those will see a separate deprecation or removal patch, soon). So, when FluidTemplateContentObject is called for whatever reason with an extbase request, it has been created by a proper extbase bootstrap call, wich created a "correct" extbase request already. There is no need to tamper with this in FluidTemplateContentObject again. Note this wasn't the case with earlier TYPO3 versions where extbase requests were created within StandaloneView, a misuse we got rid off in v12. The patch removes these extbase request manipulations from FluidTemplateContentObject. Resolves: #104473 Related: #104472 Related: #104471 Related: #98377 Releases: main Change-Id: Id4fc202f140fe270e35259251ed052752c2c6ed0 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85348 Tested-by:
Simon Praetorius <simon@praetorius.me> Reviewed-by:
-
- Jul 23, 2024
-
-
Georg Ringer authored
Provide a new type of static routes `assets` to expose assets shipped by extensions. Resolves: #101472 Releases: main Change-Id: I46d5b8af795b1037c6a3e2554454df6a6e7174ea Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85268 Reviewed-by:
-
- Jul 18, 2024
-
-
Oliver Bartsch authored
TextPreviewRenderer and TextpicPreviewRenderer extend the StandardContentPreviewRenderer while not implementing any custom functionality and are therefore now removed. Resolves: #104417 Releases: main Change-Id: Ia99c3751405f038dbdc57b531650d7657e4a83fc Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85283 Reviewed-by:
-
- Jul 15, 2024
-
-
Oliver Bartsch authored
Resolves: #104385 Related: #104367 Releases: main Change-Id: I3584b57fb021bc8e90d945250a00ad2968afafad Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85250 Tested-by:
-
- Jul 12, 2024
-
-
Benni Mack authored
When loading Record objects, and we use Relations in one of the next patches, the main issue will be that we might run in recursions when fetching relations. This can be resolved by re-using created Record objects by utilizing the Identity Map pattern (https://en.wikipedia.org/wiki/Identity_map_pattern) which keeps track (context-wise) of the loaded records. In a way to unify this logic, the "RecordRememeberer" for Page Module has now been removed as this is the exact purpose of the Identity Map. The next step is to actually utilize the Record API in the Page module replacing arrays there completely. Resolves: #104367 Related: #103783 Releases: main Change-Id: Idd56a49c421fd722ed35eedded365420a7479bea Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85047 Reviewed-by:
-
- Jul 11, 2024
-
-
Simon Schaufelberger authored
Add test coverage for GeneralUtility::getFilesInDir with sorting by mtime. Resolves: #103817 Releases: main Change-Id: I298f63fef0369cf2fefd0876628ca55a152947c9 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/84190 Reviewed-by:
-
- Jul 09, 2024
-
-
Daniel Siepmann authored
The menu generation must not reuse the page record from the current page but must use the data from the linked page. This got already fixed for #101883. But that fix didn't take into account that ->createLink() might throw an exception. This is now considered and the state is properly re- initialized also on exceptions. Resolves: #104335 Related: #103582 Related: #101883 Releases: main, 12.4 Change-Id: Ib4c1f1fba68a83dca32a9ffd7ee14c31cf60bab5 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85175 Tested-by:
-
- Jun 28, 2024
-
-
Stefan Bürk authored
With PHP 8.4 marking method parameter implicitly nullable is deprecated and will emit a `E_DEPRECATED` warning. One recommended way to resolve this, is making it explicitly nullable using the `?` nullable operator or adding a null tyype to an union type definition. [1] This prepares the way towards PHP 8.4 compatibility. [1] https://php.watch/versions/8.4/implicitly-marking-parameter-type-nullable-deprecated Resolves: #104237 Releases: main, 12.4, 11.5 Change-Id: Ieb8d05b2e44dc448f7a2142c5ad6a91e68cf98c0 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/84973 Tested-by:
-
- Jun 27, 2024
-
-
Benni Mack authored
Since HTML Sanitizer was introduced, lib.parseFunc does "transformations", instead of ensuring that HTML is "safe", which wasn't possible anyways (that was one of the reasons why htmlSanitize is introduced). A quick explanation to the existing functionality of allowTags and denyTags: * If parseFunc stumbles across a tag, which is NOT a typotag (tags.a for example), and NOT an external block, it will be checked if it is in "allowTags" or NOT in "denyTags", then it gets rendered, otherwise the tag including its contents is htmlspecialchar'ed. The tags are thus NOT removed, but instead hsced. In order to simplify the process, allowTags and denyTags can now be omitted, with the following result: If allowTags = a,b,em... ONLY these tags are allowed, and denyTags does not matter anymore already. allowTags can now be set to "*", thus denyTags can be used to mark explicitly use "denyTags". It now makes little sense to define allowTags AND den...
-
- Jun 26, 2024
-
-
Oliver Bartsch authored
For additional context does the PolicyMutatedEvent now provide the current PSR-7 Request. Resolves: #104141 Releases: main, 12.4 Change-Id: I1817366e77f20f6c43eef0ee209fbb419e7237e2 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/84913 Tested-by:
-
- Jun 21, 2024
-
-
Benni Mack authored
This change allows to explicitly set includeRecordsWithoutDefaultTranslation = 0 in TypoScript. Resolves: #93881 Releases: main, 12.4 Change-Id: Ieef59efa320f401345c0c40c2514f988bd1d6715 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/84798 Tested-by:
-
Benni Mack authored
This change * simplifies allowTags and denyTags in lib.parseFunc by comparing with in_array rather than "inList()" for EVERY tag! * Remove superfluous if() statements - GeneralUtility::get_tag_attributes always returns an array - substr does not return "false" but an empty string since PHP 8.0 Resolves: #104170 Releases: main Change-Id: I1980ab3b8ea6fd4a836782475dd4c61b07f50ed3 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/84814 Tested-by:
-
- Jun 19, 2024
-
-
Sascha Egerer authored
The ContentObjectRenderer catches \Exception's that occur during the rendering of a content element. However, since PHP 7, there is a \TypeError exception that occurs, for example, if the given type does not match the declared type. Because \TypeError is not a subtype of \Exception, these errors are not caught in the production context, and instead of not rendering a single content element, the whole page is not rendered. Since all types of \Throwable are essentially errors that will interrupt the rendering process, the catch block must accommodate all of these, not just implementations of \Exception. Resolves: #102044 Releases: main, 12.4, 11.5 Change-Id: If6218f013caf21d7fcd2c0d0d5b6b51c3bf9963e Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/81573 Reviewed-by:
-
Mogens Fiebrandt authored
When implementing a custom ImageViewHelper to manipulate the image with the GifBuilder, after processing instructions has been applied, the processed image in the typo3temp/assets/images folder was a 1x1px sized image. This happened because the ContentObjectRenderer::getImgResource() returned null instead of an ImageResource, when the path of a processed file was passed as $file argument. It turned out, that the return of ResourceFactory::retrieveFileOrFolderObject() also can be an instance of ProcessedFile. So that the @return annotation had to be expanded by this class. The change in ContentObjectRenderer::getImgResource() now handles paths of processed files properly. Resolves: #103872 Releases: main Change-Id: Ie67b77b680a339054bcf99d522234cb1d10e2ca6 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/84337 Tested-by:
-
- Jun 14, 2024
-
-
Christoph Lehmann authored
Local resources are currently not "cache-busted", for example, have no version in URL. TypoScript has no possibility to add the cache buster. When replacing them a new filename must be used (which feels little hacky), because web clients may have cached the old file version. This introduces 1) getText "asset" to cache-bust assets in TypoScript .. code-block:: typoscript page.20 = TEXT page.20 { value = { asset : EXT:core/Resources/Public/Icons/Extension.svg } insertData = 1 } # Result: typo3/sysext/core/Resources/Public/Icons/Extension.svg?1709051481 2) cache-busted assets with the :html:`<f:uri.resource>` ViewHelper .. code-block:: html <f:uri.resource path="EXT:core/Resources/Public/Icons/Extension.svg" /> Before: typo3/sysext/core/Resources/Public/Icons/Extension.svg Now: typo3/sysext/core/Resources/Public/Icons/Extension.svg?1709051481 The ViewHelper argument :html:`useCacheBusting` is enabled by default. Depending on FE/versionNumberInFilename the cache buster is applied as query string or embedded in the filename. Resolves: #99203 Releases: main Change-Id: Ie421a1a9b08b542686437bb65c8663e433045a58 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/77018 Reviewed-by:Simon Schaufelberger <simonschaufi+typo3@gmail.com> Reviewed-by:
Josef Glatz <typo3@josefglatz.at> Tested-by:
-
Benni Mack authored
The StandardContentPreviewRenderer has some quirks, which allows to render the content via a Fluid Template via Page TSconfig. mod.web_layout.tt_content.preview.textmedia = EXT:site_mysite/Resources/Private/Templates/Preview/Textmedia.html This is now done via a PSR-14 EventListener. This was previously (back in v10) not possible while the legacy "Page module" and the "Fluid-based" page module existed and the PSR-14 event was not possible. This way, the StandardContentPreviewRenderer is trimmed down. Also, some additional logic is now restructured within the StandardContentPreviewRenderer in order to separate the class into smaller pieces. Also, the TextmediaPreviewRenderer as well as the ImagePreviewRenderer are not needed anymore. Resolves: #103603 Releases: main Change-Id: I879b913529c5928b67d2f98a438015719fc55f86 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/83744 Tested-by:
-
- Jun 13, 2024
-
-
Jochen Roth authored
Currently, Services.yaml files are used to register a services as public and shared. This has been changed throughout the core (where possible) to use the PHP attribute "Autoconfigure" (public, shared) to have all options in one place. Resolves: #104082 Related: #104023 Releases: main Change-Id: I7598d6d4eae731832f1fff6975b9da7c3d8de87d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/84676 Tested-by:
-
- Jun 11, 2024
-
-
Jochen Roth authored
Currently, Services.yaml files are used to register a services as public. This has been changed throughout the core (where possible) to use the PHP attribute "Autoconfigure" to have all options in one place. Resolves: #104023 Releases: main Change-Id: I3165806fb635c17d10b42f268cc2f0cd194dde56 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/84548 Reviewed-by:
-
- Jun 01, 2024
-
-
Benni Mack authored
This change adapts the newly introduced PageContentFetching data processor, which reduces the number of SQL queries for colPos entries that do not use the "slideMode" feature. This means, that installations which use - multiple colPos on one layout will have 1 instead of "amountOfColPos" DB queries for fetching all content of a page. For colPos with a slide mode, the previous logic still applies. Resolves: #103906 Related: #103894 Releases: main Change-Id: I5172fa427a69f279e88c27f9b97793036d94c533 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/84387 Tested-by:
-
- May 31, 2024
-
-
Benjamin Franzke authored
Allow proxies to cache the TYPO3 content by stripping the nonce from the generated CSP header if the nonce was not actually consumed. Also ensure that the nonce value substitution consumes a nonce to ensure that a (replaced) nonces in cached-content receive a matching CSP header as well. Resolves: #103942 Releases: main, 12.4 Change-Id: I437c83de522ff4a6f4ee0ef2f13881d24bfb990c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/84435 Tested-by:
Kai Ole Hartwig <o.hartwig@moselwal.de> Tested-by:
Willi Wehmeier <wwwehmeier@gmail.com> Reviewed-by:
-
Georg Ringer authored
The stdWrap options stripHtml and htmlSpecialChars requires the value to be a string. A typecast forces the string to avoid exceptions. Resolves: #103085 Releases: main, 12.4 Change-Id: Ia936a19e06fdf954ca3aef442cad34c164e9c54e Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/84446 Tested-by:
-
- May 27, 2024
-
-
Christian Kuhn authored
Using PHP attributes to configure DI within classes directly is more easy to understand since developers don't need to constantly look up DI configuration Services.yaml files, but have everything in one place. The patch switches all classes that previously used '@cache.xy' to get a specific cache injected to an `Autowire` attribute. Resolves: #103921 Releases: main Change-Id: I16b064242cdbc2bbcfbed89700c97afac012fdf8 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/84406 Tested-by:
-
- May 24, 2024
-
-
Benni Mack authored
This change adds a new RecordCollector which is similar to CONTENT cObject, except that it does not render the records directly, but instead creates instances of a generic Record object, so the Templating Engine can deal with the way of how the record should be rendered. Based on the Page Layout / Backend Layout, all registered colPos contents are fetched, and grouped, if the Backend Layout has an "identifier" set via a new PageContentFetchingProcessor ("page-content"). The slide functionality can now be defined in the Page Layout as well (Backend Layout), with a Enum defining to Collect, CollectReverse and a simple Slide logic. This feature brings a clearer separation of fetching content from the database and the actual representation in the output (fluid) in place, allowing for further optimizations. In addition, one needs to write much less TypoScript to fetch all contents from a page. Next steps is then to enrich the records with their relations (see next feature), and to optimize the Fluid-based rendering for any kind of content. Resolves: #103894 Releases: main Change-Id: I6a1a0efacefe8c83e86b9551b00199c93e284a28 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/83638 Reviewed-by:
-
- May 21, 2024
-
-
Ayke Halder authored
Several classes in TYPO3 have class doc comments like `Class NameOfClass`. Those comments have no value and can therefore be removed. RegEx search: `/\*\*(\n \*.*)*\n \* Class [A-Z]` Resolves: #103866 Related: #103862 Releases: main Change-Id: Idb4ea9971d05686edb247cc6c96a03911baa19ae Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/84332 Tested-by:
Chris Müller <typo3@brotkrueml.dev> Tested-by:
-
