TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692023-09-13T03:56:05ZTYPO3 Forge
Redmine TYPO3 Core - Story #101904 (Accepted): CKEditor5 UIhttp://forge.typo3.org/issues/1019042023-09-13T03:56:05ZBenjamin Franzkeben@bnf.dev
<p>Tracker for UI related CKEditor5 bugs or tasks.</p> TYPO3 Core - Bug #91074 (Rejected): typo3conf/ folder is not created when using a custom app-dir ...http://forge.typo3.org/issues/910742020-04-17T01:15:10ZBenjamin Franzkeben@bnf.dev
<p>In composer mode in composer.json:</p>
<pre><code>"extra": {<br /> "typo3/cms": {<br /> "app-dir": "custom",<br /> "web-dir": "public" <br /> }<br /> },</code></pre>
<p>In this case Environment::$projectPath would be /path/to/root/custom and Environment::$publicPath would be /path/to/root/public.</p>
<p>The typo3conf folder is then generated in /path/to/root/custom/typo3conf instead of /path/to/root/public/typo3conf.</p>
<p>This is actually by accident, because "custom" and "public" have the same length.<br />Reason is the code in <a class="external" href="https://git.typo3.org/Packages/TYPO3.CMS.git/blob/9fb677f6f3b3a1cd584b9ef183b35da771d3e25d:/typo3/sysext/install/Classes/FolderStructure/DefaultFactory.php#l134">https://git.typo3.org/Packages/TYPO3.CMS.git/blob/9fb677f6f3b3a1cd584b9ef183b35da771d3e25d:/typo3/sysext/install/Classes/FolderStructure/DefaultFactory.php#l134</a><br /><pre>
$publicPath = substr(Environment::getPublicPath(), strlen(Environment::getProjectPath())+1);
</pre><br />which tries to substract the project path from the public path, while assuming that project path is an ancestor, which results in a public path <code>""</code> to be calculate.<br />The result should rather be <code>"../public"</code>.</p>
<p>We should rather generate a relative path and adapt the FolderStructur Factory to handle relative paths, include partent dots ("..").</p> TYPO3 Core - Bug #86372 (Closed): CacheManager 'assets' cache is not configurable in ext_localcon...http://forge.typo3.org/issues/863722018-09-25T14:39:41ZBenjamin Franzkeben@bnf.dev
<p>Since commit <a class="external" href="https://review.typo3.org/c/54020/">https://review.typo3.org/c/54020/</a> + followup <a class="external" href="https://review.typo3.org/54061">https://review.typo3.org/54061</a> (released only in v9) it is no longer possible to configure the 'assets' cache in ext_localconf.php files.</p>
<p>The IconRegisty is loaded in backend mode and reads the configuration (caches from 'assets') during object construction.<br />IconRegistry is usually instantiated during ext_localconf.php (due to extensions registering icons),<br />and therefore create's the 'assets' cache during ext_localconf.php loading.</p>
<p>After CacheManager has created the assets cache once, it will never be recreated again,<br />when the final configuration is set, after all ext_localconf.php files have been loaded.</p> TYPO3 Core - Task #83953 (Closed): Inject the PackageManager into the DependencyResolverhttp://forge.typo3.org/issues/839532018-02-17T18:58:36ZBenjamin Franzkeben@bnf.devTYPO3 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>