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 - Bug #102377 (Resolved): Backend requests are cached (and used) within 1s timeframehttp://forge.typo3.org/issues/1023772023-11-16T05:26:57ZBenjamin Franzkeben@bnf.dev
<p>Backend responses must never be cached. The Cache-Control instruction "must-revalidate" implicitly enables<br />caching in order to possibly reuse a response. While that could only happen when two requests to the same URL are<br />invoked withing one second (because the browsers `If-Modified-Since` header and our `Last-Modified` header<br />do match, causing the webserver to issue a 304 response), that is certainly possible in CI setups or fast user clicks.</p>
<p>Nightly runs (and new CI) caught following CSP errors that happended because a previous request to the same backend URL<br />was tried to be reused.<br />That means the browser sends a `If-Modified-Since` header, the server compares that to our <code>Last-Modified</code> header and because those match for 1s (given times on server and client are equal), the server responds with a 304 response and new CSP headers.</p>
<p>Now, the client uses those new CSP headers on the old (cached) content, causing CSP errors.</p>
<p>Log from a previous nightly: <a class="external" href="https://git.typo3.org/typo3/CI/cms/-/jobs/2719694">https://git.typo3.org/typo3/CI/cms/-/jobs/2719694</a></p>
<pre>
1) TemplateCest: Open the TypoScript Object Browser and search a keyword.
Test Acceptance/Application/Template/TemplateCest.php:searchInTypoScriptActive
Step Use existing session "admin"
Fail Found following JavaScript errors in the browser console:
01:12:43.964 SEVERE - http://web/typo3/index.php 24 Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' 'nonce-q-0rXT6ndm1d4k1PB_skehGuei9NU4RmepZIoI0jaD4t4mptySRwtg' 'report-sample'". Either the 'unsafe-inline' keyword, a hash ('sha256-mOe1j2nA39ZHBa9vuj8vjm6s1j12BoBxmU5pq+c8myY='), or a nonce ('nonce-...') is required to enable inline execution.
01:12:43.965 SEVERE - http://web/typo3/index.php 28 Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' 'nonce-q-0rXT6ndm1d4k1PB_skehGuei9NU4RmepZIoI0jaD4t4mptySRwtg' 'report-sample'". Either the 'unsafe-inline' keyword, a hash ('sha256-eYBX9tiv0eShqtr6+0ybc98Tpn+++UDyS8IavaWnnig='), or a nonce ('nonce-...') is required to enable inline execution.
01:12:43.985 SEVERE - http://web/typo3/sysext/core/Resources/Public/JavaScript/java-script-item-handler.js?1699903243 12:137 Uncaught TypeError: Failed to resolve module specifier '@typo3/core/java-script-item-processor.js'
Scenario Steps:
1. $I->useExistingSession("admin") at Acceptance/Application/Template/TemplateCest.php:26
Artifacts:
Png: /builds/typo3/CI/cms/typo3/sysext/core/Tests/../../../../typo3temp/var/tests/AcceptanceReports/TYPO3.CMS.Core.Tests.Acceptance.Application.Template.TemplateCest.searchInTypoScriptActive.headless.fail.png
Html: /builds/typo3/CI/cms/typo3/sysext/core/Tests/../../../../typo3temp/var/tests/AcceptanceReports/TYPO3.CMS.Core.Tests.Acceptance.Application.Template.TemplateCest.searchInTypoScriptActive.headless.fail.html
FAILURES!
Tests: 36, Assertions: 162, Failures: 1.
</pre> TYPO3 Core - Task #102132 (Closed): CI Composer max failure: phpstan: Ignored error pattern in T...http://forge.typo3.org/issues/1021322023-10-10T04:43:13ZBenjamin Franzkeben@bnf.dev
<p><a class="external" href="https://git.typo3.org/typo3/CI/cms/-/jobs/2632464">https://git.typo3.org/typo3/CI/cms/-/jobs/2632464</a></p>
<pre>
- Upgrading phpstan/phpdoc-parser (1.20.0 => 1.24.2)
- Upgrading phpstan/phpstan-phpunit (1.3.14 => 1.3.15)
</pre>
<pre>
$ Build/Scripts/runTests.sh -s phpstan -p 8.1
06:14
------ -----------------------------------------------------------------------------------------------
Line core/Tests/Unit/Database/Schema/Parser/TableBuilderTest.php
------ -----------------------------------------------------------------------------------------------
Ignored error pattern #^Call to static method
PHPUnit\\Framework\\Assert\:\:assertSame\(\) with 0 and string\|null
will always evaluate to false\.$# in path
/builds/typo3/CI/cms/typo3/sysext/core/Tests/Unit/Database/Schema/Parser/TableBuilderTest.php
was not matched in reported errors.
</pre> 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 #95972 (Closed): BackendUserAuthentication uses empty() to check for array valueshttp://forge.typo3.org/issues/959722021-11-15T09:26:16ZBenjamin Franzkeben@bnf.dev
<p>empty returns true, if an array key is set, e.g. to 0.</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 #93270 (Under Review): BroadcastMessage.fromData() is not idempotenthttp://forge.typo3.org/issues/932702021-01-12T06:35:24ZBenjamin Franzkeben@bnf.dev
<p>If BroadcastMessage is recreated using <code>BroadcastMessage.fromData()</code> it does not retain the original object structure. This is because <code>BroadcastMessage.fromData()</code> nests the entrire data (which includes a <code>payload</code> property itself) into another wrapping <code>payload</code> property.</p>
<p>Given following JavaScript code (executable in a Browser console in a window of the TYPO3 Backend):</p>
<pre><code class="javascript syntaxhl" data-language="javascript"><span class="nb">window</span><span class="p">.</span><span class="nf">require</span><span class="p">([</span><span class="dl">'</span><span class="s1">TYPO3/CMS/Backend/BroadcastMessage</span><span class="dl">'</span><span class="p">],</span> <span class="p">({</span><span class="nx">BroadcastMessage</span><span class="p">})</span> <span class="o">=></span> <span class="p">{</span>
<span class="kd">const</span> <span class="nx">bm1</span> <span class="o">=</span> <span class="k">new</span> <span class="nc">BroadcastMessage</span><span class="p">(</span><span class="dl">'</span><span class="s1">component</span><span class="dl">'</span><span class="p">,</span> <span class="dl">'</span><span class="s1">eventName</span><span class="dl">'</span><span class="p">,</span> <span class="p">{</span><span class="na">foo</span><span class="p">:</span> <span class="dl">'</span><span class="s1">bar</span><span class="dl">'</span><span class="p">})</span>
<span class="c1">// Create bm2 from bm1, as if bm1 has been sent via broadcastchannel</span>
<span class="kd">const</span> <span class="nx">bm2</span> <span class="o">=</span> <span class="nx">BroadcastMessage</span><span class="p">.</span><span class="nf">fromData</span><span class="p">(</span><span class="nx">bm1</span><span class="p">)</span>
<span class="nx">console</span><span class="p">.</span><span class="nf">log</span><span class="p">(</span><span class="dl">'</span><span class="s1">bm1</span><span class="dl">'</span><span class="p">,</span> <span class="nx">bm1</span><span class="p">.</span><span class="nx">payload</span><span class="p">)</span>
<span class="nx">console</span><span class="p">.</span><span class="nf">log</span><span class="p">(</span><span class="dl">'</span><span class="s1">bm2</span><span class="dl">'</span><span class="p">,</span> <span class="nx">bm2</span><span class="p">.</span><span class="nx">payload</span><span class="p">)</span>
<span class="p">})</span>
</code></pre>
<p>The expected result/output is that <code>payload</code> contains the same value for both <code>BroadcastMessage</code> instances:<br /><pre>
bm1 {foo: "bar"}
bm2 {foo: "bar"}
</pre></p>
<p>While it actually is:<br /><pre>
bm1 {foo: "bar"}
bm2 {payload: {foo: "bar"}}
</pre></p>
<p><code>BroadcastMessage.fromData()</code> should be fixed to be idempotent, while keeping backwards compatibility (to existing event-subscribers) by doing the "additional" payload wrapping in <code>BroadcastMessage.createCustomEvent</code>. The "good" thing is, that BroadcastMessage isn't used directly by subscribers, it is transformed into a <code>CustomEvent</code>, therefore this can be fixed without breaking BC.</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> TYPO3 Core - Bug #89873 (Closed): backend:lock/backend:unlock are not longer available as schedul...http://forge.typo3.org/issues/898732019-12-06T10:12:05ZBenjamin Franzkeben@bnf.dev
<p><a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Tasks backend:lock & backend:unlock most not be schdulable (Closed)" href="http://forge.typo3.org/issues/89387">#89387</a> dropped the support with the patch in <a class="external" href="https://review.typo3.org/c/Packages/TYPO3.CMS/+/61938">https://review.typo3.org/c/Packages/TYPO3.CMS/+/61938</a><br />The reason was to fix execution from the backend.</p>
<p>The schedulers <strong>primary</strong> task is to <strong>schedule</strong> tasks, not to execute them from the backend.<br />The backend-execution is only an additional functionality, which is available because it's sometime handy for manual tasks/testing.<br />We shouldn't mark commands as non-schedulable when scheduling them is a perectly valid usecase.</p> TYPO3 Core - Bug #87229 (Closed): checkDataSubmission is missing in extension scannerhttp://forge.typo3.org/issues/872292018-12-19T20:05:14ZBenjamin Franzkeben@bnf.dev
<p>In <a class="issue tracker-4 status-5 priority-4 priority-default closed" title="Task: Deprecate hooks superseded by PSR-15 middlewares (Closed)" href="http://forge.typo3.org/issues/86279">#86279</a> checkDataSubmission slipped through and was forgotten to be mentioned in a .rst file and the extension scanner configuration.</p>