TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692024-03-23T06:28:58ZTYPO3 Forge
Redmine TYPO3 Core - Task #103473 (Resolved): Account for double click pagetree timeout in acceptance testshttp://forge.typo3.org/issues/1034732024-03-23T06:28:58ZBenjamin Franzkeben@bnf.devTYPO3 Core - Task #103297 (Resolved): Add composer-mode to our acceptance test matrixhttp://forge.typo3.org/issues/1032972024-03-06T10:42:13ZBenjamin Franzkeben@bnf.dev
<p>All applicable acceptance tests should also executed<br />in composer mode in order to cover possible regressions for this mode.</p> TYPO3 Core - Task #103086 (Resolved): Allow execution of acceptance tests with local chromedriver...http://forge.typo3.org/issues/1030862024-02-09T05:57:26ZBenjamin Franzkeben@bnf.dev
<p>A local instance can sometimes be better debugged and odd behaviour easier introspected, when acceptance tests are possible to be run on the host instead of in containers only.</p>
<p>The testing setup should be adapted to allow that using codeception <code>--env</code> parameter</p> TYPO3 Core - Task #102286 (Closed): Allow a custom AbortSignal to be passed to AjaxRequest methodshttp://forge.typo3.org/issues/1022862023-10-30T10:25:14ZBenjamin Franzkeben@bnf.dev
<p>AjaxRequest uses an own abort controller in order to provide<br />the abort() method, in order to allow passing an own AbortSignal<br />instance, the passed signal is now forwarded to the internal<br />abort controller.</p> TYPO3 Core - Bug #101684 (Under Review): <typo3-backend-icon> changed to inline element in TYPO3 v12http://forge.typo3.org/issues/1016842023-08-15T07:32:44ZBenjamin Franzkeben@bnf.dev
<p>Expect: <typo3-backend-icon> should render as in TYPO3 v11</p> TYPO3 Core - Bug #99352 (Closed): PDF Metadata double-encoded by index-search indexer with popple...http://forge.typo3.org/issues/993522022-12-13T08:13:14ZBenjamin Franzkeben@bnf.dev
<pre>
pdfinfo version 21.08.0
Copyright 2005-2021 The Poppler Developers - http://poppler.freedesktop.org
Copyright 1996-2011 Glyph & Cog, LLC
</pre>
<p>There are different versions of pdfinfo available in the wild.<br />Debian/Fedora use pdfinfo (>v20) from the poppler-utils package.<br />Also good hosters like Hetzner use this version.<br />This tool defaults to UTF-8 output for metadata:</p>
<pre>
pdfinfo umlauts-metadata.pdf | grep Title
Title: Test æ ø å ü ö ä
</pre>
<p>On the other hand there are hosters like Mittwald and Domainfactory, which use the older v3 of pdfinfo which defaults to Latin1 output.</p>
<pre>
pdfinfo -v
pdfinfo version 3.02
Copyright 1996-2007 Glyph & Cog, LLC
</pre>
<p>This tool produces Latin1 output by default:</p>
<pre>
pdfinfo umlauts-metadata.pdf | grep Title
Title: Test � � � � � �
</pre>
<p>Both versions support an <code>-enc UTF-8</code> option, which should be used by TYPO3 to circumvent the differences between these tools, instead of always implying that v3 is used and forcefully converting from ISO-8859-1 to UTF_8 – as added in See <a class="external" href="https://review.typo3.org/c/Packages/TYPO3.CMS/+/76861">https://review.typo3.org/c/Packages/TYPO3.CMS/+/76861</a><br /> – which leads to double-encoding with the poppler-utils pdfinfo variant.</p>
<p><img src="http://forge.typo3.org/attachments/download/37256/umlauts-double-encoding.png" alt="" loading="lazy" /></p> TYPO3 Core - Bug #96978 (Closed): Backend "Stay logged in" button does refresh the login-sessionhttp://forge.typo3.org/issues/969782022-02-20T13:50:53ZBenjamin Franzkeben@bnf.dev
<p><strong>Steps to reproduce:</strong></p>
<p>1. Set <code>$GLOBALS['TYPO3_CONF_VARS']['BE']['sessionTimeout']</code> to <code>70</code>.<br />2. Login via /typo3/<br />3. Wait 60 seconds for the login-refresh-popup to occur<br />4. Click the "Stay logged in" button<br />5a Wait 10 seconds and click on a module => A redirect to the login screen will appear<br />5b Wait another 60 seconds => A password-box will appear because the session has not been updated.</p>
<p><strong>Description:</strong><br />For unknown reasons the /ajax/login/refresh<br />route has never been used (all the way back to v6),<br />to request a session timeout update.</p>
<p>Instead the route /ajax/login/timedout, <strong>without</strong> the<br />skipSessionUpdate=1 parameter has been used to<br />refresh an existing session.</p>
<p>With the introducting of configurable loute parameters<br />in <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Move skipSessionUpdate values to AjaxRoutes config (Closed)" href="http://forge.typo3.org/issues/81409">#81409</a> this inconsitency wasn't noticed and the<br />skipSessionUpdate parameter has been moved into the<br />route-configuration, which meant /ajax/login/timedout was<br />always called with skipSessionUpdate=1,<br />even as result of the "Stay logged in" button, where<br />a session update was intended.</p>
<p>Use the dedicated /ajax/login/refresh route<br />in order to actually refresh the session.</p> TYPO3 Core - Bug #96663 (Closed): Redirect notification broken after upgrade from v11.5.3 to v11.5.5http://forge.typo3.org/issues/966632022-01-27T18:49:00ZBenjamin Franzkeben@bnf.dev
<p>JavaScriptHandler.js has been introduced with <a class="external" href="https://review.typo3.org/c/Packages/TYPO3.CMS/+/64123">https://review.typo3.org/c/Packages/TYPO3.CMS/+/64123</a> and publish in v11.5.3</p>
<p>FLAG_USE_TOP_WINDOW has been added in <a class="external" href="https://review.typo3.org/c/Packages/TYPO3.CMS/+/72262">https://review.typo3.org/c/Packages/TYPO3.CMS/+/72262</a> and was released in v11.5.4</p>
<p>When updating from v11.5.3 the browser may still deliver the cached JavaScriptHandler.js as no cache bust invalidation is present.</p>
<p>This results in redirect slug updater notification which uses to be executed in the list_frame (as the v11.5.3 JavaScriptHandler.js doesn't know about FLAG_USE_TOP_WINDOW) where the context for the notification is not prepared.</p>
<p><img src="http://forge.typo3.org/attachments/download/36697/slug-notification.png" alt="" loading="lazy" /></p> TYPO3 Core - Bug #95427 (Closed): Symfony EventDispatcher can not be injected via contracts inter...http://forge.typo3.org/issues/954272021-10-01T09:54:08ZBenjamin Franzkeben@bnf.dev
<p>Uncaught TYPO3 Exception Argument 1 passed to Symfony\Component\Console\Application::setDispatcher() must be an instance of Symfony\Component\EventDispatcher\EventDispatcherInterface, instance of TYPO3\SymfonyPsrEventDispatcherAdapter\EventDispatcherAdapter given, called in […]typo3/sysext/core/Classes/Console/CommandApplication.php on line 77<br />thrown in file […]/web/typo3conf/ext/typo3_console/Libraries/vendor/symfony/console/Application.php</p> TYPO3 Core - Bug #94113 (Closed): Trusted SERVER_NAME check is broken when a HTTPS broker proxies...http://forge.typo3.org/issues/941132021-05-11T18:45:33ZBenjamin Franzkeben@bnf.dev
<p>Scenario:
* Proxy Server HTTPS (SSL termination) => Port 443
* Application Server HTTP => Port 80
* Default trustedHostsPattern configuration (GeneralUtility::ENV_TRUSTED_HOSTS_PATTERN_SERVER_NAME)</p>
<p><a class="external" href="https://mydomain.com">https://mydomain.com</a> (e.g. via nginx server) -> proxied to apache backend -> <a class="external" href="http://10.0.0.1/">http://10.0.0.1/</a></p>
<p>Proxy configuration like:<br /><pre>
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://10.0.0.1;
}
</pre></p>
<p>Because of the HOST_NAME verification that consideres the proxy port is equal to the local webserver port, such configurations currently need to configure a slow custom trustedHostsPattern, although 'mydomain.com' is the correct SERVER_NAME.</p> TYPO3 Core - Task #92250 (Closed): Avoid double-slash in requirejs contrib URLs in backend javasc...http://forge.typo3.org/issues/922502020-09-09T22:11:30ZBenjamin Franzkeben@bnf.dev
<p>URLs to jquery and broadcastchannel-polyfill are currently loaded with double-slash.</p>
<p><img src="http://forge.typo3.org/attachments/download/35436/double-slash-contrib-js.png" alt="" loading="lazy" /></p>
<p>Webservers need to resolve and normalize these, that should be avoided.</p> TYPO3 Core - Bug #91316 (Closed): MetaTagManagerRegistry instance not unique in uncached pluginshttp://forge.typo3.org/issues/913162020-05-06T09:04:27ZBenjamin Franzkeben@bnf.dev
<p>Reported by Aristeidis Karavas (Apr 28th at 11:51) via Slack:<br /><a class="external" href="https://typo3.slack.com/archives/C025BQLFA/p1588067478426300">https://typo3.slack.com/archives/C025BQLFA/p1588067478426300</a></p>
<blockquote>
<p>Why in TYPO3 v10 this won't set the meta tags in frontend?<br />$metaTag = $this->metaTagManagerRegistry->getManagerForProperty($key);<br />$metaTag->addProperty($key, $metaTagValue);<br />If i debug it, it sets everything right but it won't be displayed in the frontend</p>
</blockquote>
<p>The reason is that the PageRenderer stores a new Singleton via <code>GeneralUtility::setSingletonInstance</code> in <code>__wakeup</code>.</p>
<p>That updates <code>MetaTagManagerRegistry</code> instances retrieved via <code>GeneralUtility::makeInstance</code>, but not those injected via symfony DI,<br />where the object will already have been generated, as it is loaded during EXT:seo/ext_localconf.php loading and GeneralUtility::makeInstance<br />will call the DI container.</p>
<p>This issues happens when the PageRenderer was serialized and is unserialized for <code>USER_INT</code> plugins (e.g. uncached extbase plugins).</p>
<p>Same applies to AssetCollector, which is serialized and unserialized as well.</p> TYPO3 Core - Task #91150 (Closed): ext_localconf.php of to-be-installed extensions breaks when DI...http://forge.typo3.org/issues/911502020-04-20T19:10:29ZBenjamin Franzkeben@bnf.dev
<p>ExtensionManager reloads ext_localconf after an extension has been installed.<br />ext_localconf.php files may use DI services.</p>
<p>Now, when an extension is installed and ext_localconf is loaded<br />and a DI service is requested, it will not yet be available.</p>
<p>This has been discovered with georgringer/news in revision 205cb3ef25a4cd49e922a74a8fbcc0b2299fac77.</p>
<a name="Update-2020-04-21"></a>
<h2 >Update 2020-04-21<a href="#Update-2020-04-21" class="wiki-anchor">¶</a></h2>
<ul>
<li>report was based on <a class="external" href="https://github.com/georgringer/news/commit/205cb3ef25a4cd49e922a74a8fbcc0b2299fac77">https://github.com/georgringer/news/commit/205cb3ef25a4cd49e922a74a8fbcc0b2299fac77</a></li>
<li>there has been a work-around for ext:news to tackle this in<br /><a class="external" href="https://github.com/georgringer/news/commit/ac0cb20c5baba297352063d1332641e7c9cc2e3e">https://github.com/georgringer/news/commit/ac0cb20c5baba297352063d1332641e7c9cc2e3e</a></li>
<li>ext:news can be installed with TYPO3 v10</li>
</ul> 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 #91070 (Closed): SMTP transport 'tls' no longer work supportedhttp://forge.typo3.org/issues/910702020-04-16T19:15:15ZBenjamin Franzkeben@bnf.dev
<p>With <code>transport_smtp_encrypt = tls</code> set for STARTTLS SMTP connections,<br />TYPO3 v10 will cast <code>transport_smtp_encrypt</code> to <code>bool</code>.<br />That boolean is passed to symfony mailer which interprets TLS = true as SSL (ssl://) connection.</p>
<p>That results in the following error when sending a mail:</p>
<pre>
Could not deliver mail
Please verify $GLOBALS['TYPO3_CONF_VARS']['MAIL'][*] settings are valid. Error message: Connection could not be established with host "ssl://mail.your-server.de:587": stream_socket_client(): SSL operation failed with code 1. OpenSSL Error messages: error:1408F10B:SSL routines:ssl3_get_record:wrong version number.
</pre>
<p>To use TLS (STARTTLS) TLS = false would need to be passed to Symfony\Component\Mailer\Transport\Smtp\EsmtpTransport.</p>
<p>Should TYPO3 provide a smooth migration to set <code>transport_smtp_encrypt=tls</code> to <code>TLS=false</code>?</p>