TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692018-09-25T14:39:41ZTYPO3 Forge
Redmine 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 - Bug #86371 (Closed): Extbase reflection cache is not configurable in ext_localconf.phphttp://forge.typo3.org/issues/863712018-09-25T14:34:33ZBenjamin Franzkeben@bnf.dev
<p>Since commit <a class="external" href="https://review.typo3.org/#/c/54381/">https://review.typo3.org/#/c/54381/</a> (released on in v9) it is no longer possible to configure 'extbase_reflection' cache in ext_localconf.php files.</p>
<p>The cache is instantiated early during ext_localconf.php by EXT:extbase.<br />The extbase <code>Object\Container</code> is configured (instanciated) in EXT:extbase/ext_localconf.php.<br />The <code>Object\Container</code> then instanciates the <code>ReflectionService</code> in its constructor,<br />which itself creates the extbase_reflection using the CacheManager<br />(all of that during ext_localconf.php loading).</p>
<p>After CacheManager has created the extbase_reflection 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 - Bug #86290 (Closed): Suggested migration regarding config.tx_extbase.objects does no...http://forge.typo3.org/issues/862902018-09-18T08:59:08ZBenjamin Franzkeben@bnf.dev
<p>This refers to the changes from <a class="external" href="https://review.typo3.org/c/58288/">https://review.typo3.org/c/58288/</a></p>
<p>Also different sets of injection methods or properties than the original class will not work.</p>
<p>We should recommend to use <code>\TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Extbase\Object\Container\Container::class)->registerImplementation($oldClassName, $newClassName)</code> in <code>ext_localconf.php</code>.</p> TYPO3 Core - Bug #86248 (Closed): CLI upgrade wizards can not be invoked fully uncachedhttp://forge.typo3.org/issues/862482018-09-13T22:47:27ZBenjamin Franzkeben@bnf.dev
<p>When `typo3/sysext/core/bin/typo3 upgrade:run` is executed, caches from cache_core are loaded.<br />That may lead to unwanted side effects, when caches are stale.</p>
<p>This behaviour is different to the web counterpart (the install tool) which runs in failsafe mode, where all caches are ignored.</p> TYPO3 Core - Bug #86140 (Closed): Legacy backend preview url generation generates URL with duplic...http://forge.typo3.org/issues/861402018-09-04T14:13:35ZBenjamin Franzkeben@bnf.dev
<p>When there is no site configuration, no TCEMAN.preview<br />configuration and no sys_domain record available, BackendUtility::getViewDomain returns a URL like:</p>
<p><a class="external" href="http://http://hostname.tld/">http://http://hostname.tld/</a></p>
<p>This broke due tue the site handling features, probably<br />with <a class="external" href="https://review.typo3.org/57949">https://review.typo3.org/57949</a></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 - 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 - 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 - 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 - 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>