TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692018-03-20T06:46:09ZTYPO3 Forge
Redmine TYPO3 Core - Task #84490 (Closed): Add missing HTTP status code presets for PSR-7 responseshttp://forge.typo3.org/issues/844902018-03-20T06:46:09ZBenjamin Franzkeben@bnf.dev
<p>The list of status codes/reason phrases should be synchronized with<br /><a class="external" href="http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml">http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml</a></p> TYPO3 Core - Task #84117 (Closed): Do not reinitialize CacheManager and PackageManager in clearAl...http://forge.typo3.org/issues/841172018-03-02T14:09:54ZBenjamin Franzkeben@bnf.dev
<p>Those (re)initializations originate from <a class="external" href="https://review.typo3.org/19605">https://review.typo3.org/19605</a><br />were reinitializeClassLoaderAndCachesAndPackageManagement()<br />was used to "Reinitialize the class loader during clear cache actions" <br />(according to phpdoc).</p>
<p>Then with the changes in <a class="external" href="https://review.typo3.org/29811">https://review.typo3.org/29811</a><br />reinitializeClassLoaderAndCachesAndPackageManagement()<br />was dropped and splitted into unregisterClassLoader(),<br />flagCachingFrameworkForReinitialization().<br />initializeCachingFramework() and initializePackageManagement().<br />(just historical info, still all good)</p>
<p>Then <a class="external" href="http://review.typo3.org/39827">http://review.typo3.org/39827</a> came and dropped unregisterClassLoader<br />but left the CacheManager and PackageManager reinitialization in place<br />superfluously. It's superfluous as the original usecase was to<br />reinitialize the class loader which is no longer required.</p> TYPO3 Core - Task #84099 (Closed): Decouple SystemEnvironmentBuilder from Bootstraphttp://forge.typo3.org/issues/840992018-03-01T11:10:58ZBenjamin Franzkeben@bnf.dev
<p>Do not rely on defined constants or methods from Bootstrap<br />to be usable on it own (at some point).</p> TYPO3 Core - Task #84083 (Closed): ApplicationContext should consistently be retrieved from Gener...http://forge.typo3.org/issues/840832018-02-28T15:28:39ZBenjamin Franzkeben@bnf.dev
<p>ClassLoadingInformation reads from Bootstrap, that should be adapted to use GeneralUtility.</p>
<p>Bootstrap code states:</p>
<pre>
* Use \TYPO3\CMS\Core\Utility\GeneralUtility::getApplicationContext() instead
</pre>
<p>Therefore the method should just be removed.</p> TYPO3 Core - Task #84082 (Closed): A LogRecord should not rely on global state (requestId from Bo...http://forge.typo3.org/issues/840822018-02-28T15:17:33ZBenjamin Franzkeben@bnf.devTYPO3 Core - Task #83966 (Closed): Consolidate singleton usagehttp://forge.typo3.org/issues/839662018-02-19T18:22:40ZBenjamin Franzkeben@bnf.dev
<p>There is Bootstrap::getInstance()->getEarlyInstance() and<br />GeneralUtility::makeInstance() to retrieve (global) instances.<br />Sometimes the former, sometimes the latter is used (e.g. to<br />retrieve the PackageManager).<br />As there is no obvious reason why diffrent methods are used, this<br />should be unified to one way to retrieve singletons.</p>
<p>Furthermore classes should not know whether something is an<br />early instance or not. Implementation details like that<br />should be abstracted into a singleton container.<br />That (currently) is GeneralUtility::makeInstance().</p> TYPO3 Core - Task #83954 (Closed): Do not use Bootstrap->getInstance()::populateLocalConfigurationhttp://forge.typo3.org/issues/839542018-02-17T19:00:15ZBenjamin Franzkeben@bnf.devTYPO3 Core - Task #83951 (Closed): Decouple Bootstrap and Application initializationhttp://forge.typo3.org/issues/839512018-02-17T13:50:16ZBenjamin Franzkeben@bnf.dev
<p>In order to support full-application subrequests (later on),<br />bootstraping, application initialization and application execution<br />should be decoupled.</p>
<p>To be able to initialize a frontend Application in backend<br />Application context, the frontend Application should not re-execute<br />bootstraping code.</p>
That means:
<ul>
<li>Bootstrap should be limited to bootstrapping (oh wonder!)<br /> => setting up global services/whatever, not more.</li>
<li>A Container (PSR-11) performs initialization<br /> => e.g. `new Frontend/Http/Application()`</li>
<li>Application performs execution<br /> => checking possible (application specifc redirects)<br /> => offloading work to the request handler</li>
</ul> TYPO3 Core - Bug #83946 (Closed): Content-Type for some backend ajax routes and eID scripts broke...http://forge.typo3.org/issues/839462018-02-16T21:06:04ZBenjamin Franzkeben@bnf.dev
<p><a class="external" href="https://review.typo3.org/c/55754">https://review.typo3.org/c/55754</a> refactored all PSR-7<br />related controllers to remove an own response.</p>
<p>Missing is the fact that ajax routes used a<br />pre-generated response with application/json<br />Content-Type header.<br />eID scripts did not use a pre-generated header<br />at all.</p> TYPO3 Core - Task #83864 (Closed): Directly wire Application and RequestHandlerhttp://forge.typo3.org/issues/838642018-02-12T19:09:43ZBenjamin Franzkeben@bnf.dev
<p>Bootstrap should not contain application specific code (HTTP vs CLI). The Application should handle their request handlers themselves.</p> TYPO3 Core - Bug #83854 (Closed): EidHandler triggers an exception when an eID script returns nullhttp://forge.typo3.org/issues/838542018-02-12T09:56:05ZBenjamin Franzkeben@bnf.dev
<p>A null return value returned by a eID script needs to be converted to NullResponse.</p>
<pre>
Core: Exception handler (WEB): Uncaught TYPO3 Exception: Return value of TYPO3\CMS\Frontend\Middleware\EidHandler::process() must implement interface Psr\Http\Message\ResponseInterface, null returned | TypeError thrown in file […]/typo3/sysext/frontend/Classes/Middleware/EidHandler.php in line 66. Requested URL: http://127.0.0.1:3002/index.php?eID=dumpFile&t=f&f=1&token=38b5b8024d5652bc59ce83ed943fec71def7d417
</pre> TYPO3 Core - Task #83794 (Closed): External URL redirect should use PSR-7 Response objectshttp://forge.typo3.org/issues/837942018-02-06T23:47:16ZBenjamin Franzkeben@bnf.dev
<p>Instead of immediately die'ing, allow to post-process redirects in the middleware chain.</p> TYPO3 Core - Task #83726 (Closed): HTTP RequestHandlers should use strict typinghttp://forge.typo3.org/issues/837262018-01-29T21:12:35ZBenjamin Franzkeben@bnf.devTYPO3 Core - Task #83724 (Closed): HTTP RequestHandlers should always return a PSR-7 ResponseInte...http://forge.typo3.org/issues/837242018-01-29T21:03:15ZBenjamin Franzkeben@bnf.dev
<p>The PSR-15 middleware interfaces [1] require that RequestHandlers always return a Response.<br />In order to support PSR-15 middleware (at some point), TYPO3 request handlers should do the same.</p>
<p>A NULL return value should rather be replaced with a PSR-7 Response that's either ignored by Core\Bootstrap or a Response with a 200 status code and an empty body.</p>
<p>[1] <a class="external" href="https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-15-request-handlers.md">https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-15-request-handlers.md</a></p> TYPO3 Core - Bug #79107 (Closed): Extensionmanager shows incorrect warning in composer modehttp://forge.typo3.org/issues/791072016-12-29T13:24:05ZBenjamin Franzkeben@bnf.dev
<p>The warning should be an info instead, as the warning can't be resolved besides not using composer:</p>
<blockquote><blockquote>
<p>The system is set to composer mode. Please notice that it is not possible to add an extension with the Extension Manager. You have to use composer to add further extensions to your system.</p>
</blockquote></blockquote>