TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692024-03-05T14:32:10ZTYPO3 Forge
Redmine TYPO3 Core - Task #103287 (Resolved): Revert "[TASK] Format fluid format tags consistently"http://forge.typo3.org/issues/1032872024-03-05T14:32:10ZBenjamin Franzkeben@bnf.dev
<p>The patch has been merged with too few votes.</p> TYPO3 Core - Task #103109 (Resolved): Important-102799-TYPO3_CONF_VARSGFXprocessor_stripColorProf...http://forge.typo3.org/issues/1031092024-02-13T11:10:01ZBenjamin Franzkeben@bnf.dev
<p>One patchset was missing from <a class="external" href="https://review.typo3.org/c/Packages/TYPO3.CMS/+/82940">https://review.typo3.org/c/Packages/TYPO3.CMS/+/82940</a> that had been forget to be updated to updates on the main branch.</p> TYPO3 Core - Feature #103043 (Resolved): Modernize tree rendering and implement RTL and dark modehttp://forge.typo3.org/issues/1030432024-02-05T06:09:42ZBenjamin Franzkeben@bnf.devTYPO3 Core - Task #101464 (Closed): Reactivate usage of constructable stylesheets for icon elementhttp://forge.typo3.org/issues/1014642023-07-27T19:41:48ZBenjamin Franzkeben@bnf.dev
<p>With <a class="issue tracker-4 status-5 priority-4 priority-default closed" title="Task: Streamline icon elements (Closed)" href="http://forge.typo3.org/issues/100270">#100270</a> stylesheets in icon elements have been inlined<br />instead of using lit's own style wrapper that uses constructable<br />stylesheets if available.<br />Inline stylesheets need to be parsed over and over again, whenever<br />a web component is used multiple times.<br />The icon element is supposed to be used very often, which is why this<br />matters. Constructable stylesheets are cached and therefore do only<br />need to be parsed once, regardless how often a web component is used.</p> TYPO3 Core - Bug #101288 (Resolved): sudo-mode opens module contents without backend frame when u...http://forge.typo3.org/issues/1012882023-07-07T13:08:44ZBenjamin Franzkeben@bnf.devTYPO3 Core - Task #99580 (Closed): Increase clickable panel-heading touch/click-areahttp://forge.typo3.org/issues/995802023-01-17T16:43:47ZBenjamin Franzkeben@bnf.dev
<p>Current click-area height is 13px, so the padding-area of the panel-heading isn't clickable to toggle collapse.</p>
<p><img src="http://forge.typo3.org/attachments/download/37321/panel-link-size-v2.png" alt="" loading="lazy" /></p> TYPO3 Core - Bug #97144 (Closed): Slow module scrolling in Google Chrome on Linuxhttp://forge.typo3.org/issues/971442022-03-08T15:09:57ZBenjamin Franzkeben@bnf.dev
<p>Scrolling the list module with 100 entries causes FPS to drop to <15fps on Google Chrome (v99) with Linux during scrolling.<br />This is for sure a Chrome Bug, but reveals that <code>overflow: hidden</code> and <code>scrolling="no"</code> on the module iframe is not a good idea.</p>
<p>It would be great to remove the <code>scrolling="no"</code> parameter from the module iframe and enable scrolling on <html> instead of .module-body</p>
<p>There are some past issues to take into account when changing the module-scrolling semantics: <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: Correct horizontal scrolling in iOS browsers (Closed)" href="http://forge.typo3.org/issues/83841">#83841</a> <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: rte_ckeditor displaces dropdown overlays and jumps to top of page on crome/safari (Closed)" href="http://forge.typo3.org/issues/80116">#80116</a> <a class="issue tracker-1 status-5 priority-6 priority-high2 closed" title="Bug: RTE CKeditor top-positioning for maximize and combopanels is broken in browsers with webkit (Closed)" href="http://forge.typo3.org/issues/82780">#82780</a></p>
<p>Using overflow: auto on <code><html></code> as suggested in <a class="external" href="https://forge.typo3.org/issues/80116#note-7">https://forge.typo3.org/issues/80116#note-7</a> was mainly avoided because of mobile iOS overscroll behaviour, otherwise this could have already been changed with: <a class="external" href="https://review.typo3.org/c/Packages/TYPO3.CMS/+/55647">https://review.typo3.org/c/Packages/TYPO3.CMS/+/55647</a></p>
<p>Consider using the standardized <code>overscroll-behaviour</code> property to fix issues on that part.</p> TYPO3 Core - Task #96703 (Closed): Fix definition availability checks in DI compiler passeshttp://forge.typo3.org/issues/967032022-01-31T07:28:01ZBenjamin Franzkeben@bnf.dev
<p>findDefinition() doesn't actually return a boolean (or null)<br />value on failure but throws an exception instead. As an alternative<br />$container->hasDefintion may be used to check for definition availability.</p> TYPO3 Core - Task #96691 (Closed): Add phpstan plugin for psr/containerhttp://forge.typo3.org/issues/966912022-01-30T15:02:37ZBenjamin Franzkeben@bnf.devTYPO3 Core - Task #93773 (Closed): Move SVG Tree to Lit Elementshttp://forge.typo3.org/issues/937732021-03-18T13:41:48ZBenjamin Franzkeben@bnf.dev
<p>The entire SVG Tree should be a HTML element, to allow further<br />reduction of d3 usage in favor of native HTML5 APIs.</p> TYPO3 Core - Task #92722 (Closed): Refactor TER RemoteRegistry to avoid container usage as it is ...http://forge.typo3.org/issues/927222020-10-27T20:02:20ZBenjamin Franzkeben@bnf.devTYPO3 Core - Bug #92239 (Closed): SymfonyEventDispatcher is not symfony/event-dispatcher-contract...http://forge.typo3.org/issues/922392020-09-09T12:09:37ZBenjamin Franzkeben@bnf.dev
<p><b>Fatal error</b>: Declaration of TYPO3\CMS\Core\Adapter\SymfonyEventDispatcher::dispatch(object $event, ?string $eventName = NULL): object must be compatible with Symfony\Contracts\EventDispatcher\EventDispatcherInterface::dispatch($event) in <b>[…]typo3/sysext/core/Classes/Adapter/SymfonyEventDispatcher.php</b> on line <b>26</b><br /></p>
<p><a class="external" href="https://bamboo.typo3.com/browse/CORE-GTN-229">https://bamboo.typo3.com/browse/CORE-GTN-229</a></p> TYPO3 Core - Bug #91220 (Accepted): ExtensionManager dependency calculation does not take extensi...http://forge.typo3.org/issues/912202020-04-28T11:40:12ZBenjamin Franzkeben@bnf.dev
<p>When one extension depends on two extensions where both extensions depend on a third one, but with a different set of matching versions, then ExtensionManager is unable to find the common dependency version that is allowed by both extensions, because it decided for a very too early.</p>
<p>Sound very complicated in written words, therefore an example:</p>
<p>Two custom extensions: "master" and "other_ext"</p>
<p>EXT:master (allowing powermail v6-v8 and depending on `other_ext`)</p>
<pre><code>'constraints' => array(<br /> 'depends' => array(<br /> 'typo3' => '9.5.0-9.5.99',<br /> 'powermail' => '6.0.0-8.99.99',<br /> 'other_ext' => '*',<br /> ),<br /> ),<br />EXT:other_ext (allowing only powermail v6)</code></pre>
<pre><code>'constraints' => array(<br /> 'depends' => array(<br /> 'typo3' => '9.5.0-9.5.99',<br /> 'powermail' => '6.0.0-6.99.99',<br /> ),<br /> ),</code></pre>
<p>When installing "master" on 9.5 the error "powermail was requested to be downloaded in different versions (6.2.0 and 7.4.0)." will be thrown.</p>
<p>That is because the latest version of powermail is used when checking dependencies for "EXT:master" – the compatible v6 should/could be taken into account as both extensions are marked to be compatible with it and v6 itself is marked to be v9.5 compatible.</p>
<p>Note: This is <strong>not</strong> a bug that was introduced with <a class="external" href="https://review.typo3.org/c/Packages/TYPO3.CMS/+/64308/">https://review.typo3.org/c/Packages/TYPO3.CMS/+/64308/</a> (that patch is fine) – it's just an additional and more complex case.</p>
<p><a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Special dependencies are not checked during install of dependencies (Closed)" href="http://forge.typo3.org/issues/91179">#91179</a> is therefore related, but not the source of this bug.</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 #86492 (Closed): stdWrap on config.additionalHeaders is broken for (fully) cache...http://forge.typo3.org/issues/864922018-10-01T09:56:28ZBenjamin Franzkeben@bnf.dev
<p>The feature to use stdWrap for additionalHeaders was introduced in v9 development cycle: <a class="external" href="https://review.typo3.org/c/50142/">https://review.typo3.org/c/50142/</a><br />It seems this is broken since the initial commit (and is still in master).</p>
<p>Suppose using the following TypoScript (as suggested in the documentation):</p>
<pre>
config.additionalHeaders {
10 {
# The header string
header = X-TYPO3-foo:
header.dataWrap = |{page:uid}
}
}
</pre>
<p>Both the original commit 2124bba49f68f5c35705c5c499abe6a0ee95a6cf and current master result in an Exception for a page that is read from cache because <code>TypoScriptFrontendController->cObj</code> is not initialized:</p>
<pre>
? $this->cObj->stdWrap(trim($header), $options['header.'])
Oops, an error occurred!
Call to a member function stdWrap() on string.
</pre>
<p>cObj is initialized in TSFE::newCObj, which is called by <code>TSFE::preparePageContentGeneration</code>, which itself is only called if the page is uncached or rendered initially (for good reasons).</p>
<p>I'm not sure whether we should revert this feature, instead of fixing this and implcitly allowing uncached stuff to be executed (through stdWrap) for a fully cached page. Things like these may be better handled by middlewares.</p>