- Mar 15, 2024
-
-
Oliver Bartsch authored
Resolves: #103385 Releases: main, 12.4, 11.5 Change-Id: Ifd93dfa4049d0d3550d052fa960ae79cc5a27c34 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/83451 Reviewed-by:
Oliver Klee <typo3-coding@oliverklee.de> Tested-by:
Garvin Hicking <gh@faktor-e.de> Tested-by:
Stefan Bürk <stefan@buerk.tech> Tested-by:
Georg Ringer <georg.ringer@gmail.com> Tested-by:
core-ci <typo3@b13.com> Reviewed-by:
-
- Dec 23, 2023
-
-
Christian Kuhn authored
The patch extracts TSFE->determineId() and its sub methods from TSFE into TypoScriptFrontendInitialization middleware. The information created by these methods is modeled into the new DTO PageInformation, which is added as 'frontend.page.information' request attribute before handling other middlewares below. The non-internal old properties within TSFE are set and kept as b/w compat layer for now. This is a powerful change: It allows us to reduce dependencies to TSFE significantly, which we will start to leverage with upcoming patches. The patch is an intermediate change as such: Looking at determineId() and its related methods makes clear the code can benefit heavily from further refactoring. The method could be ultimately extracted into a service class that only returns the 'final' PageInformation object, or throws exceptions for 'early' responses. To keep the patch reviewable at this point, these refactorings will continue with additional patches. Detail notes: * TSFE->sys_page PageRepository instance is for now modeled as (@internal) PageInformation->pageRepository. This can be refactored away later: Consumers should create instances of that class on demand. * "original mount and shortcut page record" are also modeled as (@internal) PageInformation properties for now. They are internal handling since the redirects can only be created after TypoScript has been calculated later on, so the information has to be carried around for now. We *may* be able to change this later. * The two middleware properties $pageNotFound and $pageAccessFailureHistory are a tribute to the current code flow in determineId(). They should be refactored away when the code is further shuffled around. The properties currently require a hack that needs to make the middleware "shared: false" to circumvent side effects in combination with error handling sub requests. * The code flow around determineId() updates local state and state of PageInformation multiple times and is in general very hard to follow. The patch crafted this carefully and did not refactor the code flow heavily for now. Changing the early response creation strategy will make the code flow much more straightforward later. * determineId() and with it the PageInformation object is now created *before* TSFE is instantiated, shifting the instantiation to a slightly later point. * getPageAccessFailureReasons() is for now transferred to the middleware as well. It can be later dissolved when determineId() receives further refactoring. Two consumers (indirectly) by ShortcutAndMountPointRedirect middleware could be dissolved already, so the method could be removed from TSFE. * TSFE->linkVars needs to be dissolved soon: The strategy should be to create "linkVars" on demand within the link handling code and eventually encapsulate it with a runtime cache entry. * getRedirectUriForMountPoint() and getRedirectUriForShortcut() are relocated to ShortcutAndMountPointRedirect middleware. TSFE->getUriToCurrentPageForRedirect() had to be made (@internal) public to do that, but that method can be refactored away when TSFE->linkVars is dissolved. * The hacks within RedirectService are extended to deal with the new situation for now. The entire thing needs to fall at a later point completely. * Further patches should start avoiding the TSFE properties that are now set as b/w compat layer, and start using the PageInformation request attribute instead. This will reduce overall dependencies to TSFE significantly. Resolves: #102715 Releases: main Change-Id: I6470899cf65cbaaeb2177a8b20c0800f045a070c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82267 Reviewed-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
-
- Dec 09, 2023
-
-
Christian Kuhn authored
Refactor TSFE->no_cache towards the new Request attribute 'frontend.cache.instruction': This attribute can be created by middlewares early when they need to disable cache mechanics of middlewares later in the stack. The new construct *requires* a reason when caching is disabled, and the disable instruction can be set by multiple middlewares which can result in multiple reasons being gathered. The admin panel now lists any "cache has been disabled" reasons. Resolves: #102628 Releases: main Change-Id: I86584f17c5a90fe76923cfbf75c3b987da13fd95 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82073 Tested-by:
Oliver Bartsch <bo@cedev.de> Reviewed-by:
Sascha Nowak <sascha.nowak@netlogix.de> Tested-by:
-
- Dec 02, 2023
-
-
Christian Kuhn authored
EXT:adminpanel class TypoScriptWaterfall sets both 'no_cache' and the typoscript context aspect 'forcedTemplateParsing' to true when the admin panel related option 'Force template parsing' is enabled. This setting is "on" by either using the admin panel FE interface (which stores settings in BE user "uc"), or using BE user UserTsConfig admPanel.override.tsdebug.forceTemplateParsing = 1. All consumers of the forcedTemplateParsing aspect property (namely in TypoScriptFrontendController) always check both 'no_cache' and 'forcedTemplateParsing', so that's duplicate information. The patch removes the 'typoscript' context aspect altogether and simplifies consumers to rely on the 'no_cache' flag only. Resolves: #102583 Releases: main Change-Id: I33599ff7c23ce48102f9473d74ae1358f343c36c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82066 Reviewed-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Tested-by:
-
- Dec 01, 2023
-
-
Benni Mack authored
When PHP 8.0 support was added, a lot of places received extra checks with the $conf ?? []. PHPStan complained about this now, as methods already have native PHP types added now, and the check is not needed anymore, so it can be simplified A few other places did not receive proper PHPdoc annotations which has been fixed as well. In addition, some str_ends_with calls are migrated. Resolves: #102528 Releases: main Change-Id: I031d677473d4e9601fbf9d7c90214c311cfea863 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/81975 Tested-by:
Andreas Kienast <a.fernandez@scripting-base.de> Tested-by:
-
- Feb 13, 2023
-
-
Andreas Fernandez authored
PhpStorm now understands that PSR-14 `EventDispatcherInterface->dispatch()` returns an instance of the first argument. Resolves: #99929 Releases: main Change-Id: I0fda1df8cc434b897311049fbef5fe4f1389a2e7 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/77837 Tested-by:
-
Christian Kuhn authored
PhpStorm now understands that PSR-11 ContainerInterface->get() returns an instance of the first argument. Resolves: #99929 Releases: main Change-Id: I4c3e77aed92ce4e9b318923577ce346515a6299c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/77829 Reviewed-by:
-
- Feb 01, 2023
-
-
Christian Kuhn authored
The user authentication classes are still pretty messy. A subset of properties and information of backend user state is intitialized by middlewares and set as aspect to the context object. However, we do not want to add the entire backend user as $request attribute object, to not surface another usage of this object. Instead, it is set as $GLOBALS['BE_USER'] throughout the core, which will eventually vanish at some point, by being substituted by something better. ext:reactions currently violates this. The patch sets $GLOBALS['BE_USER'], consuming reactions should retrieve it from there if needed, just like any other backend related class does it currently. FormProtectionFactory had a similar flaw, it accessed the attribute even though no middleware ever set this. Finally, .phpstorm.meta.php is cleaned up, to not declare this request attribute any longer. Change-Id: Iae4c48a1ccc41f7aeebdf753f9cae6515bb5f9e5 Resolves: #99751 Releases: main Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/77638 Tested-by:
-
- Oct 25, 2022
-
-
Christian Kuhn authored
The patch introduces the new request attribute TypoScriptRequestAttribute as 'frontend.typoscript'. It is set up in the Frontend middleware chain, extensions and content objects can use this attribute to retrieve TypoScript settings and setup. This obsoletes usages of TSFE->tmpl, the patch switches usages to the request attribute. Note we're also establishing a better wording: The old TypoScript 'constants' are now called 'settings'. This matches much better, should avoid confusion for newcomers and is in line with further renaming of a vaguely anticipated new 'constants editor' towards 'settings editing' or similar. Further patches in this naming area will follow. Change-Id: Ib6ffb91db9bf0976f39759b12983d78418d64efa Resolves: #98914 Releases: main Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/76239 Tested-by:
-
- Jul 10, 2022
-
-
linawolf authored
The outdated links in EXT:install are improved in https://forge.typo3.org/issues/97885 Releases: main, 11.5 Resolves: #97886 Change-Id: I25979df8f9f322461ffc6d03ab9030240c2e0e8a Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75090 Tested-by:
Nikita Hovratov <nikita.h@live.de> Reviewed-by:
-
- Jun 06, 2022
-
-
Oliver Klee authored
This is now covered by the annotations using generics in the testing framework base class, and hence not needed anymore. (Removing it also helps get consistent behavior from PhpStorm's static type analysis.) Resolves: #97736 Releases: main, 11.5, 10.4 Change-Id: Ia7d7e790bb92eaf1c9b7ffa4f9d97b2b0a50dee3 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74822 Tested-by:
Simon Schaufelberger <simonschaufi+typo3@gmail.com> Tested-by:
-
- Feb 15, 2022
-
-
Benni Mack authored
A new "ModuleData" object is introduced, which contains the allowed module data properties for a module, overlaid by previously set values from a user. Each module now has access to this object, as it is populated during a middleware and the values are persisted. Resolves: #96895 Releases: main Change-Id: Ie9e17ada201c809ea4c1d0473c447366fbe4bbcc Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73415 Tested-by:
Jochen <rothjochen@gmail.com> Tested-by:
-
Oliver Bartsch authored
Since #96797, the Module object is added to the PSR-7 Request, in case a TYPO3 backend module is requested. To further support autocompletion, the Module definition is now added to the .phpstorm.meta.php file. Resolves: #96905 Related: #96797 Releases: main Change-Id: Id323f27dbe59a386cf38ba73ee75bd07abb11532 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73521 Tested-by:
-
- Jan 25, 2022
-
-
Stefan Bürk authored
Extend PHPStorm meta file with further definitions for autocompletion support and avoid unnecessary php docblocks in the code base. * add request getAttribute() return types * add return type for 'SiteMatcher->matchRequest()' * add return type for 'PageRouter->matchRequest()' Resolves: #96636 Related: #95064 Releases: main, 11.5 Change-Id: I7c2aafc8a0230090e267d9c4eb2f3e5284d8ee0a Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73144 Tested-by:
-
- Sep 04, 2021
-
-
Andreas Fernandez authored
PhpStorm has basic support for generics since version 2021.2 which comes in handy as since the same version the "Dynamic Return Type" plugin is broken. Providing the class-string annotation and a proper return generic supersedes this and recovers the built-in autocompletion. To have the same effect for both, 3rd party code not being under our control or methods having complex returns based on their input, a `.phpstorm.meta.php` file is provided extending PhpStorms code awareness capabilities. Tons of kudos to Alexander Schnitzler providing a boilerplate configuration here: https://github.com/alexanderschnitzler/phpstorm.meta.php-typo3 For more information about capability extension consult https://www.jetbrains.com/help/phpstorm/ide-advanced-metadata.html Resolves: #95064 Releases: master, 10.4, 9.5 Change-Id: I4ea5115550ce7070de01c42c19ac3b93bf6ab4b6 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70872 Tested-by: core-...
-
