TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692018-02-09T15:23:59ZTYPO3 Forge
Redmine TYPO3 Core - Task #83831 (Closed): Make extension scanner aware of the deprecated EidRequestHandlerhttp://forge.typo3.org/issues/838312018-02-09T15:23:59ZBenjamin Franzkeben@bnf.dev
<p>The EidRequestHandler was replaced by a EidHandler middleware.<br />Extensionscanner support for the deprecated class should be added.</p> TYPO3 Core - Task #83803 (Closed): Rewrite eID handling as PSR-15 middlewarehttp://forge.typo3.org/issues/838032018-02-07T22:48:00ZBenjamin Franzkeben@bnf.devTYPO3 Core - Bug #83802 (Closed): Timetracker and pre-process middleware ordering is incorrecthttp://forge.typo3.org/issues/838022018-02-07T21:59:57ZBenjamin Franzkeben@bnf.dev
<p>The middlware's introduced in <a class="external" href="https://review.typo3.org/c/55537/">https://review.typo3.org/c/55537/</a> did not preserve the sequence as used before.</p>
<p>timetracker has been marked to be executed after the preprocessing:</p>
<pre>
'typo3/cms-frontend/timetracker' => [
'target' => \TYPO3\CMS\Frontend\Middleware\TimeTrackerInitialization::class,
'after' => [
'typo3/cms-frontend/preprocessing'
]
]
</pre>
<p>'timetracker' needs to be executed first, then the request 'preprocessing', as done before the mentioned change:</p>
<pre>
// Starting time tracking
$configuredCookieName = trim($GLOBALS['TYPO3_CONF_VARS']['BE']['cookieName']) ?: 'be_typo_user';
/** @var TimeTracker $timeTracker */
$timeTracker = GeneralUtility::makeInstance(TimeTracker::class, ($request->getCookieParams()[$configuredCookieName] ? true : false));
$timeTracker->start();
// Hook to preprocess the current request
foreach ($GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/index_ts.php']['preprocessRequest'] ?? [] as $hookFunction) {
$hookParameters = [];
GeneralUtility::callUserFunction($hookFunction, $hookParameters, $hookParameters);
}
</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 #83793 (Closed): FileDumpController should return PSR-7 responseshttp://forge.typo3.org/issues/837932018-02-06T22:21:08ZBenjamin Franzkeben@bnf.dev
<p>The FAL DriverInterface should be extended to provide a method which does not echo file contents directly but returns a PSR-7 response (e.g. by writing do a StreamInterface).</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>