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 #103421 (Resolved): Update ckeditor5 to 41.2.1http://forge.typo3.org/issues/1034212024-03-19T07:46:03ZBenjamin Franzkeben@bnf.dev
<p><a class="external" href="https://github.com/ckeditor/ckeditor5/releases/tag/v41.2.1">https://github.com/ckeditor/ckeditor5/releases/tag/v41.2.1</a></p> TYPO3 Core - Task #103420 (Resolved): runTests.sh cleanupshttp://forge.typo3.org/issues/1034202024-03-19T07:20:44ZBenjamin Franzkeben@bnf.devTYPO3 Core - Bug #103382 (Resolved): Context-Menu placed in invisible area when opened at bottom ...http://forge.typo3.org/issues/1033822024-03-13T09:21:55ZBenjamin Franzkeben@bnf.dev
<p><a class="external" href="https://typo3.slack.com/archives/C03AM9R17/p1710271829140209?thread_ts=1710244943.836959&cid=C03AM9R17">https://typo3.slack.com/archives/C03AM9R17/p1710271829140209?thread_ts=1710244943.836959&cid=C03AM9R17</a><br /><a class="external" href="https://typo3.slack.com/archives/C03AM9R17/p1710244943836959">https://typo3.slack.com/archives/C03AM9R17/p1710244943836959</a></p> TYPO3 Core - Task #103358 (Resolved): Make admin user creation optional in CLI installerhttp://forge.typo3.org/issues/1033582024-03-11T09:32:20ZBenjamin Franzkeben@bnf.dev
<p>Improve the CLI command `setup` to allow instance creation<br />without enforcing admin user and password to be defined.</p>
<p>This enables to create tiny test setups where no admin user is<br />needed or where users are imported from fixtures.</p> TYPO3 Core - Task #103354 (Resolved): Update TypeScript to 5.4http://forge.typo3.org/issues/1033542024-03-09T16:24:33ZBenjamin Franzkeben@bnf.devTYPO3 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 #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 #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 - 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>