TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692018-02-19T14:15:03ZTYPO3 Forge
Redmine TYPO3 Core - Task #83961 (Closed): Remove unused bootstrap dependency from frontend RequestHandlerhttp://forge.typo3.org/issues/839612018-02-19T14:15:03ZBenjamin Franzkeben@bnf.dev
<p>Due tue moving FE and BE user authentication to middlewares, the Bootstrap instance is no longer needed in the frontend request handler.</p> 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 #83869 (Closed): Remove request type specific code in Bootstraphttp://forge.typo3.org/issues/838692018-02-13T00:26:02ZBenjamin Franzkeben@bnf.devTYPO3 Core - Bug #83867 (Closed): ProductionExceptionHandler: assumes TSFE is always availablehttp://forge.typo3.org/issues/838672018-02-12T21:56:06ZBenjamin Franzkeben@bnf.dev
<p>Uncaught Error: Call to a member function isBackendUserLoggedIn() on null<br />in […]/typo3/sysext/core/Classes/Error/ProductionExceptionHandler.php:103</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 - Task #83727 (Closed): Reimplement EXT:redirect as PSR-15 middlewarehttp://forge.typo3.org/issues/837272018-01-29T21:17:48ZBenjamin Franzkeben@bnf.dev
<p>The redirect handling is a perfect usecase of PSR-15 middlewares.</p>
<p>Redirect handling wants to a) prevent the regular frontend rendering and b) return an own response. c) in case a no redirect matches it want's the regular RequestHandler to be invoked.</p>
<p>a) is doable by not invoking the RequestHandler a middleware gets passed by parameter<br />b) is simple by simply returning an own PSR-7 Response<br />c) is the standard case for a middleware.</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 - Feature #83725 (Closed): Introduce PSR-15 HTTP Middleware supporthttp://forge.typo3.org/issues/837252018-01-29T21:10:04ZBenjamin Franzkeben@bnf.dev
<p>The PSR-15 middleware specification was released on 22nd of january 2018.<br />TYPO3 should support PSR-15 middlewares out-of-the box.</p>
<p>Supporting PSR-15 middlewares improves interoperability with independent libraries and would superseed ugly hooks like <code>$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/index_ts.php']['preprocessRequest']</code> (ugly as they have not been adapted when PSR-7 Requests/Responses were introduced).</p> TYPO3 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> TYPO3 Core - Bug #79043 (Closed): PSR-7 non 302 redirects do not workhttp://forge.typo3.org/issues/790432016-12-20T09:25:18ZBenjamin Franzkeben@bnf.dev
<p>If a Response object sets a status code other than 302 and adds a Location header,<br />Core\Bootstrap::sendResponse will always sent a 302 response code, instead of the defined one.</p>
<p>This is because the php header() function implicitly sets the response code to 302 if a location header is sent:<br /><a class="external" href="http://php.net/manual/en/function.header.php#refsect1-function.header-parameters">http://php.net/manual/en/function.header.php#refsect1-function.header-parameters</a></p> TYPO3 Core - Bug #78730 (Closed): rtehtmlarea: isRequiredClass check is incorrecthttp://forge.typo3.org/issues/787302016-11-17T09:58:40ZBenjamin Franzkeben@bnf.dev
<p>Given the following TSConfig:</p>
<pre><code>RTE {<br /> classes {<br /> btn-default {<br /> name = Default Button<br /> requires = btn<br /> }<br /> btn-primary {<br /> name = Primary Button<br /> requires = btn<br /> }<br /> btn.selectable = 0<br /> }<br /> }</code></pre>
<p>The incorrect isRequiredClass check causes the btn class to be<br />removed from the RTE toolbarbuttons. This happens because it's<br />considered unneded in DOM.removeClass(), which is called by<br />DOM.addClass() (to remove incompatible classes).</p>
<p>The check in isRequiredClass was probably copied from<br />some classesRequired lookups, but forgot to inverse the<br />class that's searched for.</p>
<p>This also fixes the RTE to properly remove the selectable=0 class<br />(e.g. btn), when a class that requires the aformentioned is removed<br />(e.g. btn-primary).</p>
<p>(Note: To avoid further incompatibilities between classes configured<br />for the RTE content and the RTE toolbar, it should be consided to not<br />render RTE Buttons using DOM.addClass())</p> TYPO3 Core - Bug #78728 (Closed): YouTubeRender should urlencode the originhttp://forge.typo3.org/issues/787282016-11-17T07:01:01ZBenjamin Franzkeben@bnf.dev
<p>Commit 84ab413 (<a class="external" href="https://review.typo3.org/49416">https://review.typo3.org/49416</a>) fixed the origin<br />parameter to incude the full host (and thus the scheme).<br />The full host url was not urlencoded. As the scheme contains<br />slashes we should really urlencode that.</p> TYPO3 Core - Bug #78727 (Closed): indexed_search/template_css has useless appended to the ...http://forge.typo3.org/issues/787272016-11-17T06:35:52ZBenjamin Franzkeben@bnf.dev
<p>The seachword input field has a appended. It's not clear why<br />that was ever needed. But it's kinda useless and requires quite some<br />css hacks to hide that, if the label and input field are inlined.</p> TYPO3 Core - Bug #78719 (Closed): Backend Login ignores redirect_urlhttp://forge.typo3.org/issues/787192016-11-16T15:03:24ZBenjamin Franzkeben@bnf.dev
<p>The commit 9099b64c (<a class="external" href="http://review.typo3.org/39234">http://review.typo3.org/39234</a>) introduced a new form API, and forgot to pass the GET parameter 'redirect_url' into the login template, the hidden input field is never filled.</p>
<p>That means redirect_url works for already logged-in users, but not if the user has to login first.</p>