"...backend/Classes/git@git.higidi.com:TYPO3/TYPO3.CMS.git" did not exist on "a52f6a550ace0e71bcd9d8226bd7391f98a8a99f"
- Nov 17, 2022
-
-
Oliver Klee authored
Extbase controllers that call a never-returning method do not need a return statement after that call in order to avoid calling the rest of the action method. The new annotations ensure that PHPStan becomes aware of this control flow. Resolves: #99109 Releases: main, 11.5 Change-Id: I9b9d308440966c71051fe993abd31f23b13c82e0 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/76652 Tested-by:
core-ci <typo3@b13.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
-
- Oct 21, 2022
-
-
Michael Vöhringer authored
PHP8.1 throws an TypeError if we sending null to createStream Resolves: #98417 Releases: main, 11.5 Change-Id: I327751c2cb13991122c84f4333a4976b9d0a0dae Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/76197 Reviewed-by:
Oliver Klee <typo3-coding@oliverklee.de> Reviewed-by:
Stefan Bürk <stefan@buerk.tech> Reviewed-by:
Georg Ringer <georg.ringer@gmail.com> Reviewed-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Tested-by:
-
- Sep 18, 2022
-
-
Christian Kuhn authored
The Extbase Request has been turned into a PSR-7 decorator in v11. Most interface changes have not been enforced in v11 though, since that would have been breaking at this point in the release cycle. With v12, we can now activate the RequestInterface changes. The patch does this, and migrates the "setX()" that violate PSR-7 request immutability towards their 'withX()' counterparts which create new objects. The patch adds quite a bit of syntactic sugar to consuming classes: core phpstan is significantly more happy and extbase extension devs benefit from improved type hints and interface coverage. Change-Id: I111be724fd4e5d6dc9b1305efa31b7c90952730e Resolves: #98370 Related: #94428 Releases: main Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75749 Tested-by:
Lina Wolf <112@linawolf.de> Tested-by:
-
- Jul 14, 2022
-
-
Andreas Fernandez authored
To clean up cluttered severity definitions for flash messages and reports, a new `ContextualFeedback` enum is introduced. The enum is backed, means it holds actual values, which match the previously known integer values for severities. An internal `transform()` method may be used to maintain backward compatibility where needed and to trigger deprecation notices. Resolves: #97787 Releases: main Change-Id: I44b706c929277bc765bf302b2b1d32aa1da31f85 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74925 Tested-by:
Frank Nägler <frank.naegler@typo3.com> Tested-by:
Benni Mack <benni@typo3.org> Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Reviewed-by:
Markus Klein <markus.klein@typo3.org> Reviewed-by:
-
- May 25, 2022
-
-
Oliver Bartsch authored
Ensure to properly typecast optional parameters of throwStatus() before passing them to type hinted methods. Resolves: #97666 Releases: main, 11.5 Change-Id: Ifb6d43cffc97899cdd4ab72d48703bc3db23f0e1 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74735 Tested-by:
Oliver Bartsch <bo@cedev.de> Reviewed-by:
-
- Mar 03, 2022
-
-
Christian Kuhn authored
With refactoring #96998, Extbase validators should always be initialized calling setOptions(). Issue #97010 showed this is easy to forget. The patch avoids instantiating single validators directly, they are now always instantiated using ValidatorResolver->createValidator() which takes care of options setting. Resolves: #97021 Related: #96998 Related: #97010 Releases: main Change-Id: Ibb2966a442b37748d339fd2d88add13387f6ec07 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73694 Tested-by:
-
- Feb 23, 2022
-
-
Christian Kuhn authored
This follows the preparations of #96332 which has been applied to v11 and v12. The Extbase validator interfaces are streamlined and more strict, setOptions() is now mandatory. All validators now declace strict_types=1 and all non-abstract validators are declared final. A ReST file of the breaking interface and AbstractValidator signature changes explains details on how to stay compatible with v11 & v12 aware extensions. Since a lot of the existing unit tests mock single validator subjects, which is no longer possible when they're final, those tests are transferred to functional tests. Change-Id: If04a04e78e2539017da00ae1607cad1c8615774f Resolves: #96998 Related: #96332 Releases: main Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73644 Tested-by:
-
- Feb 22, 2022
-
-
Christian Kuhn authored
With #92238, it has been postulated that Extbase validators should not be dependency injection aware. Further places following this idea have been done in v11 with #94451 and #94384. A final breaking ReST file has been added with #95026. All of that is pretty unfortunate and there is simply no reason that Extbase validators can not get dependencies injected, no matter if they're not singletons. This patch specifically targets v11 to allow dependency injection in Extbase validators again if extension authors really need this, and don't want to stick to manual dependency retrieval as outlined in #95026. This patch should basically mitigate issues for extension upgrades and paves the way for a more solid general solution in v12. Extension authors have a more smooth upgrade path, especially when supporting two core versions at the same time. The v12 version of this patch is identical with v11 for now - The breaking interface change, adapting all core validators, and declaring core validators 'final' in v12 will be done with a dedicated v12 patch as soon as this v11 tailored version has been aligned on. Note all of this is pretty hairy and the solution outlined with the patch for v11 hopefully gives the maximum amount of compatibility without being breaking again, with giving extension authors additional options, and having v12 options to further mitigate this complex mess. Resolves: #96332 Related: #92238 Related: #95026 Related: #94451 Related: #94384 Releases: main, 11.5 Change-Id: I5fea15c9b73c59e5d7c3212a0842bc9a3413d2a1 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73631 Tested-by:
-
- Jan 30, 2022
-
-
Torben Hansen authored
The function getErrorFlashMessage() in ActionController can either return a string or a boolean. This patch adds bool as allowed return type in the doc comment. Resolves: #96697 Releases: main, 11.5 Change-Id: Ibd9bce942280c48fd82960aeaa9b6f691b6730e2 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73230 Tested-by:
-
- Dec 22, 2021
-
-
Christian Kuhn authored
With the removal of ControllerContext a view init call had to be moved out of ControllerContext. It was moved to a wrong place in the view setup chain. This is fixed by the patch. Resolves: #96426 Related: #96183 Releases: main Change-Id: I8a49627040a72649c39aa8ace9da0b0a2e1995c1 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72771 Tested-by:
-
- Dec 04, 2021
-
-
Christian Kuhn authored
Enforce extbase actions always have to return a ResponseInterface, removes StopActionException. Change-Id: I97f469a7385951309752636d4b846089d188e7f0 Resolves: #96234 Related: #92502 Related: #94351 Related: #94394 Related: #94428 Releases: main Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72497 Tested-by:
-
- Dec 03, 2021
-
-
Christian Kuhn authored
Remove main ObjectManager and Container classes plus the v11 compatibility layers in various places. composer rem doctrine/instantiator composer rem doctrine/instantiator -d typo3/sysext/core --no-update Resolves: #96208 Related: #94377 Related: #94370 Related: #94317 Related: #94619 Related: #94451 Related: #90803 Releases: main Change-Id: I19590e73a562babebc1318cb343a512fc0d28e1d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72469 Tested-by:
-
- Dec 02, 2021
-
-
Christian Kuhn authored
Resolves: #96204 Related: #90625 Related: #92996 Releases: main Change-Id: If76ac793f46bedba70fe325d1329d73cbd6a09fa Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72464 Tested-by:
Wouter Wolters <typo3@wouterwolters.nl> Tested-by:
-
Christian Kuhn authored
Change-Id: Idf41a7708c1d9ffee635ece1b7c060b3f751c15d Resolves: #96183 Related: #95139 Releases: main Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72445 Tested-by:
-
- Dec 01, 2021
-
-
Christian Kuhn authored
Needs a styleguide raise composer u typo3/cms-styleguide Resolves: #96174 Related: #94991 Related: #95005 Related: #95164 Related: #95222 Related: #95003 Change-Id: Iba811bf554a5ad575080950c221cc5185281435d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72436 Tested-by:
-
- Sep 21, 2021
-
-
Benni Mack authored
With PHP 8.0 and symfony/polyfill-php80 it is possible to use native str_starts_with() and str_ends_with() methods. This way, the methods * StringUtility::beginsWith() * StringUtility::endsWith() are marked as deprecated. Resolves: #95293 Releases: master Change-Id: I46d15c2f8b93c5f8b487966b2015ebefb1711348 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/71135 Tested-by:
-
- Sep 16, 2021
-
-
Christian Kuhn authored
The extbase ViewInterface fits little purpose: Most methods are part of the fluid based class and interface chain, with the exception of setControllerContext(), which is deprecated, and initializeView(), which is always only implemented as empty method. The patch deprecates the interface keeping its usage in API classes to prevent compatibility issues and prepares the interface removal for v12. Change-Id: I012ad0307f7a40923a793f55b596a27e8b770bf4 Resolves: #95222 Releases: master Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/71089 Tested-by:
Jochen <rothjochen@gmail.com> Tested-by:
-
- Sep 11, 2021
-
-
Torben Hansen authored
Since #94057, ['offlineMode' => false] is added to the settings array in ActionController by default. This has most likely been added by mistake, since it is not used in extbase but in ext:extensionmanager. This patch removes the default 'offlineMode' setting in extbase and ensures, it is always defined in ext:extensionmanager. Resolves: #95187 Related: #94057 Releases: master Change-Id: Id43ea5b4ea598f374193e9119aad1397e9e4aef8 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/71028 Tested-by:
-
- Sep 10, 2021
-
-
Oliver Bartsch authored
The extbase ActionController is already using the PSR-17 ResponseFactoryInterface for creating PSR-7 responses. The body however was still set in a PSR-7 "fashion". This is now changed to also use PSR-17 for setting the response body. More precisly, the PSR-17 StreamFactoryInterface is used explicitly instead of letting the body stream be created implicity by getBody(). The PSR-17 StreamFactoryInterface is therefore from now on available in every extbase action controller. Besides the `createStream` method, the interface also features `createStreamFromResource` and `createStreamFromFile` methods. The latter is really useful for responses that contains files, e.g. a ZIP download. This also adjusts the corresponding changelogs and replaces examples, which used the internal `HtmlResponse` class. Resolves: #95170 Releases: master Change-Id: Ib35046c061afbbc371bec0461953a55720583dee Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70986 Tested-by:
Benjamin Franzke <bfr@qbus.de> Reviewed-by:
Daniel Goerz <daniel.goerz@posteo.de> Reviewed-by:
-
- Sep 09, 2021
-
-
Christian Kuhn authored
The Extbase ControllerContext is a dependency between Extbase and Fluid to communicate state. It is wired into various view related classes. To further decouple fluid from extbase, this class needs to fall. A couple of previous patches deprecated parts of the class already, this patch deprecates the rest. The fluid RenderingContext can be used in view helpers in almost all cases as substitution, especially since extbase request implements PSR-7 ServerRequestInterface. The core itself has no direct usages of ControllerContext anymore, it is only moved around at various places. Change-Id: Ic4af492b9818003321ceeb6c9e6dcd29c5662271 Resolves: #95139 Related: #93019 Related: #93016 Related: #94428 Related: #92826 Releases: master Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70956 Tested-by:
-
- Aug 26, 2021
-
-
Christian Kuhn authored
Extbase ActionController has a view functionality to test if the target template files exist and to render an error message via NotFoundView if not. This is the only use of @internal marked NotFoundView and the only practical usage of extbase ViewInterface canRender(). This structure can be simplified significantly, without loosing functionality. The patch: * Removes @internal NotFoundView and its template * Drops canRender() from ViewInterface * Keeps canRender() in extbase ViewInterface implementations but marks them @deprecated and logs usages. * Changes extbase ActionController to not test canRender() but to let InvalidTemplateResourceException bubble up during $view->render(). This handling as a result - in case of missing templates - provides a full backtrace with a better error message than before, that of course still includes the controller and action name, plus the template location that has not been found. In the frontend, the exception is handled by the casual "plugin based exception handling" (TypoScript config.contentObjectExceptionHandler), a "template missing" programming error is now handled just like any other plugin exception. Resolves: #95003 Releases: master Change-Id: I5e55fdb2f1cfa66682b3b3a6ad0ebd21188dc10e Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70762 Tested-by:
-
- Aug 25, 2021
-
-
Christian Kuhn authored
The fluid view classes have a rather complex inheritance and dependency chain, especially when looking at the various extbase related classes, too. One step is TYPO3Fluid\Fluid\View\TemplateView: This empty class adds no value, TYPO3\CMS\Fluid\View\AbstractTemplateView can extend TYPO3Fluid\Fluid\View\AbstractTemplateView instead, without functional change. Resolves: #94973 Releases: master Change-Id: I41888b371d69ca70deb30ff0d47028d4c8e0e6ff Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70734 Tested-by:
-
- Jul 23, 2021
-
-
Christian Kuhn authored
With all non-legacy usages of ObjectManager being gone, this final patch adds a series of @deprecation annotations throughout the core, adapts some comments, and finally adds a trigger_error() to ObjectManager->get(). Resolves: #94619 Related: #90803 Releases: master Change-Id: Iaa65f7dee4e5aa9eb4e2c217e76105b0263dc6dc Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70054 Tested-by:
-
- Jul 22, 2021
-
-
Christian Kuhn authored
This finishes removal of regular extbase ObjectManager usages throughout the core: All left over places are fallback situations if extensions don't provide proper service definitions. Most places are casual replacements, many of them have been prepared with previous patches. Some places like Query and QueryResult still need special handling: The patch introduces some 'ForwardCompatible' interfaces implemented by core to otherwise OM-fallback if extensions didn't catch up yet. This avoids expensive runtime reflection in potentially often-called areas. When this patch is merged, a final patch can be done, including a ReST with some dedicated transition tips and the ultimate ObjectManager deprecation. Resolves: #94451 Related: #90803 Related: #92238 Releases: master Change-Id: Ic53f3bf6a04d15052680a953c76d19182a2e5e87 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69676 Tested-by:
-
- Jul 12, 2021
-
-
Nikita Hovratov authored
Due to refactoring or very old code some places in the core define unused variables or variables, which are immediately overridden. They are mostly unnecessary. Even in places, where they might be slightly helpful if defined at the beginning of a function, the benefit doesn't excuse the existence. Resolves: #94528 Releases: master Change-Id: I6071bb0bc96472a4b4b7f679bfabbacfb761f472 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69805 Tested-by:
-
- Jun 30, 2021
-
-
Oliver Bartsch authored
Since #94428, the extbase Request implements the PSR-7 ServerRequestInterface. Therefore, all usages of $GLOBALS['TYPO3_REQUEST'] in core extbase controllers are now replaced by accessing the extbase Request object instead. Since the extbase RequestInterface does not yet extend the PSR-7 ServerRequestInterface, as this would be a breaking change, the property type annotation of $request is changed to the specifc Request implementation, to still allow IDE support. Resolves: #94448 Related: #94428 Releases: master Change-Id: Icc8697993eae55766c21bc98d0e1e222d974ebfc Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69674 Tested-by:
-
Oliver Bartsch authored
Since #92784 extbase actions require to return a PSR-7 Response. To ease the migration path, the convenience method htmlResponse() was added. This method creates a new PSR-7 Response with the correct header and status code. Furthermore, in case no $html content is given explicitly, the current view is rendered and the result passed as response body. Extbase however also features the JsonView, which is widely used in third-party extensions as well as in multiple core controllers itself. Also TSFE has to be respected when adding the content-type header with the correct charset. Therefore, a new method jsonResponse(), with similar functionality to htmlResponse(), is now added along with adaptations of all places in core controllers. Resolves: #94440 Related: #92784 Releases: master Change-Id: Ic591a8788f586050578db8b4187e29325d180f49 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69664 Tested-by:
-
Oliver Bartsch authored
Somehow CGL stage was tricked and some unused imports sneaked in. This patch removes them. Resolves: #94444 Releases: master Change-Id: Ifa51845d524e212c8dacec4faf5aa31826fa6cbb Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69671 Tested-by:
-
- Jun 22, 2021
-
-
Christian Kuhn authored
Extbase Request setDispatched() and isDispatched() violate the PSR-7 'immutable' concept and need to fall. With the changes from #92502 where extbase actions usually return a ResponseInterface, together with the deprecation of StopActionException in #94351, we don't need this information in the Request anymore: It can be handled internally within the dispatcher, depending on the type of the response. The patch deprecates the two methods in extbase request and adapts usages towards an internal flag. We throw a deprecation warning since the flag is needed for b/w compat in v11, though. Resolves: #94394 Related: #94351 Related: #92502 Releases: master Change-Id: I1c70daa7f5b0c55e17e4b7c815d260ca68cef23c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69470 Tested-by:
-
- Jun 18, 2021
-
-
Christian Kuhn authored
When extbase has been changed to PSR-7 responses, class ReferringRequest has been nearly obsoleted: It is only used to be immediately turned into a ForwardResponse. To further prepare towards PSR-7 requests, usage of ReferringRequest which extends extbase Request is dropped and the class marked as deprecated. Change-Id: If16c09b0601792f6702fbacee064cd4d514c70c6 Resolves: #94367 Related: #92502 Releases: master Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69513 Tested-by:
-
- Jun 15, 2021
-
-
Christian Kuhn authored
There are three possible cases an extbase controller action can come up with: a) Return a casual psr-7 response (html, json, ...) b) Return an extbase specific ForwardResponse to dispatch extbase-internally to another action. c) Have a redirect the client should receive to call some other Url. a) and b) are simple in v11 - the action returns a PSR-7 ResponseInterface. c) however throws StopActionException instead, which is caught by extbase Dispatcher and then returned. This is ugly. The patch changes this and deprecates the StopActionException. We can not drop the throw call since that would be breaking, but we prepare towards a clean v12 solution, which leads to the sitation that *all* extbase actions return a response. Resolves: #94351 Releases: master Change-Id: Ie5a53109959a008ab1666f52d5a81e6e7ba3efdb Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69498 Tested-by:
-
- Jun 14, 2021
-
-
Christian Kuhn authored
"<html><head><meta http-equiv="refresh" ..." is discouraged by w3.org [1] and should be implemented as server-side 3** response. Extbase redirectToUri() already sets 303 (default) and adds the Location header. The meta http refresh is obsolete and can be dropped together with the delay argument. [1] https://www.w3.org/TR/WCAG20-TECHS/H76.html Resolves: #94341 Releases: master Change-Id: Ic3c037b0ee9edbc0eebf9f1b50180ca6c3f98ba2 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69491 Tested-by:
Richard Haeser <richard@richardhaeser.com> Reviewed-by:
-
- May 30, 2021
-
-
Daniel Goerz authored
* EXT:dashboard * EXT:extbase * EXT:extensionmanager * EXT:filelist Resolves: #94124 Releases: master Change-Id: I57e3f0b390639d2160420e4dc26468c08c6341c9 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69320 Tested-by:
-
- May 28, 2021
-
-
Benni Mack authored
The Extbase action controller does not worry about clearing cache or changing plugins from USER to USER_INT as this is now handled within Extbase Bootstrap, reducing logic within Extbase controllers. Future iterations in this area then allow to a) have Extbase in BE not depend on an active cObject anymore b) have Extbase Bootstrap be sending headers to its parent object. Resolves: #94217 Releases: master Change-Id: Iff1608ecbc37ce7e6461f9e67c73d183354ebc4a Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69110 Tested-by:
-
- May 18, 2021
-
-
Benni Mack authored
Extbase's throwStatus() method is mentioned that the execution workflow indeed should be stopped right away, but never did, as all of TSFE's code was executed again and again. Since TYPO3 v11 (#93007) we now have a "PropagateResponseException" and native PSR-7 Responses in Extbase, which allows us to do exactly that: Stop and have the Application emit the response directly with the status code. Resolves: #94131 Releases: master Change-Id: I3a6d2785603abcce4399378d0dabc2a5d05d6017 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69135 Reviewed-by:
Susanne Moog <look@susi.dev> Reviewed-by:
-
- May 14, 2021
-
-
Larry Garfield authored
PHP 8 promotes a lot of notices (previously ignored) to warnings. That means they can no longer be ignored. Resolves: #94057 Releases: master Change-Id: I37de1b7e8e31eb2be78b8e90af015bc88e121791 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69012 Tested-by:
-
- May 07, 2021
-
-
Larry Garfield authored
Using direct calls and variadics is slightly faster, and usually cleaner to read. I left in the instant-call call_user_func() instances in the entry point files, as that's only a single call and is arguably at least no worse than (function() {})(). Resolves: #94060 Releases: master Change-Id: I95988feadf8522d8d936a273608e0ef2d5ce75b5 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69017 Tested-by:crell <larry@garfieldtech.com> Reviewed-by:
-
- Jan 07, 2021
-
-
Benjamin Franzke authored
In order to strengthen TYPO3's focus on PSR standards, this change uses PSR-17 interfaces instead of the custom ResponseFactoryInterface which was added solely for extbase in #92784. The interface was added as part of the #92784 deprecation, but it actually contradicts with the ideas of interchangable PSR interfaces and therefore we strive for native PSR-17 usage, instead of wrapping PSR interfaces, now. The Extbase ActionController::htmlResponse() method – which was suggested to be used by #92784 – is kept as is (functionality wise [1]), and since the interface was injected into the ActionController using a final method, the impact of this switch is very low. Concrete implementations of PSR interfaces are always internal api, threfore also TYPO3\CMS\Core\Http\Response is switched back to be marked as internal API. Furthermore TYPO3\CMS\Core\Http\JsonResponse properties do not need to be marked internal, as the entire class is internal. [1] ActionController::htmlResponse() is adapted to avoid rewinding() the response body, as every usage/respond is actually expected to rewind or use toString(), and therefore rewind() would be called twice. Only functional tests where buggy in not calling rewind() during test assertion. Releases: master Resolves: #93237 Related: #92784 Change-Id: I59e5a190eaa1f0dd62f08db34987c6d4a72b73c1 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67353 Tested-by:TYPO3com <noreply@typo3.com> Tested-by:
-
- Dec 21, 2020
-
-
Christian Kuhn authored
When extbase controller action don't return a ResponseInterface, a deprecation log is raised: "Controller action TYPO3\CMS\Extbase\Mvc\Controller\ActionController:: does not return ..." Using late static binding and proper action name resolving changes this to a much more helpful message: "Controller action TYPO3\CMS\Styleguide\Controller\StyleguideController->tabAction does not return ..." Resolves: #93144 Related: #92784 Releases: master Change-Id: Ife9acd9dcf9e076eea617c31e7720304c59db75a Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67228 Tested-by:
-
- Dec 09, 2020
-
-
Alexander Schnitzler authored
With this patch method getFlashMessageQueue() of ControllerContext is deprecated and the core avoids using it. A trigger_error call will be implemented in another patch set which deprecates the whole ControllerContext object. Releases: master Resolves: #93016 Change-Id: I20b47dc26892b4affb1aec8e147169738139241c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67044 Tested-by:
-
