TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692024-03-06T09:10:49ZTYPO3 Forge
Redmine TYPO3 Core - Bug #103294 (Resolved): Race condition in DI cache persistencehttp://forge.typo3.org/issues/1032942024-03-06T09:10:49ZBenjamin Franzkeben@bnf.dev
<p>With <a class="issue tracker-4 status-5 priority-4 priority-default closed" title="Task: Improve dependency injection container caching (Closed)" href="http://forge.typo3.org/issues/90418">#90418</a> the container cache has been excluded from the<br />regular cache-flush-pipeline.<br />Therefore flushing has been explicitly performed when writing a<br />new cache entry (with the intent to clean up old cache entries).</p>
<p>Issue is: Cleaning up the entire folder by deleting the folder means<br />a concurrent request – that is creating the same DI cache as well –<br />will fail to write the cache when the folder is (re)moved in that<br />moment.</p>
<pre>
In SimpleFileBackend.php line 232:
The temporary cache file "/var/www/html/typo3temp/var/cache/code/di/65e832cba8809119262340.temp" could not be written.
</pre> TYPO3 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 - 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 #101885 (Resolved): runTests.sh -u does not update imageshttp://forge.typo3.org/issues/1018852023-09-09T05:03:10ZBenjamin Franzkeben@bnf.dev
<p>Update does nothing:<br /><pre>
Build/Scripts/runTests.sh -u
> prune unused, dangling local volumes
> pull ghcr.io/core-testing-*:latest versions of those ones that exist locally
> remove "dangling" ghcr.io/core-testing-* images (those tagged as <none>)
###########################################################################
Result of update
Environment: local
PHP: 8.1
SUCCESS
###########################################################################
</pre></p>
<p>Although the images are outdated<br /><pre>
[typo3-clean] (main) $ docker images | grep core-testing-php
ghcr.io/typo3/core-testing-php83 latest 184e88ecc62c 2 weeks ago 206MB
ghcr.io/typo3/core-testing-php82 latest 10292ff1a2dd 7 weeks ago 224MB
ghcr.io/typo3/core-testing-php81 latest d5e5c603d5b4 3 months ago 230MB
ghcr.io/typo3/core-testing-php74 latest 46fc907a5d1c 3 months ago 217MB
ghcr.io/typo3/core-testing-php72 latest 9fb67a3524b5 3 months ago 184MB
</pre></p> TYPO3 Core - Bug #101278 (Resolved): Fix incorrect DateTimeTest method nameshttp://forge.typo3.org/issues/1012782023-07-06T21:16:34ZBenjamin Franzkeben@bnf.devTYPO3 Core - Bug #97123 (Closed): ResourceCompressorTest.php fails in random ordered unit testshttp://forge.typo3.org/issues/971232022-03-06T06:44:52ZBenjamin Franzkeben@bnf.dev
<p><a class="external" href="https://git.typo3.org/typo3/CI/cms/-/jobs/1109375">https://git.typo3.org/typo3/CI/cms/-/jobs/1109375</a></p>
<pre>
1) TYPO3\CMS\Core\Tests\Unit\Resource\ResourceCompressorTest::getFilenamesFromMainDirInBackendContext with data set #3 ('typo3temp/assets/compressed/.htaccess', '../typo3temp/assets/compresse...access')
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'../typo3temp/assets/compressed/.htaccess'
+'typo3temp/assets/compressed/.htaccess'
/builds/typo3/CI/cms/typo3/sysext/core/Tests/Unit/Resource/ResourceCompressorTest.php:604
</pre>
<p>Steps to reproduce:</p>
<pre>
rm -rf typo3temp/Build/Scripts/runTests.sh -s unitRandom -o 1646183048
</pre>
<p>Also reproducible with:</p>
<pre>
rm -f typo3temp/assets/compressed/.htaccess && Build/Scripts/runTests.sh -s unit -e "--filter getFilenamesFromMainDirInBackendContext" typo3/sysext/core/Tests/Unit/Resource/ResourceCompressorTest.php
</pre> TYPO3 Core - Bug #95125 (Closed): Warning during ext_localconf loading causes deprecate write to ...http://forge.typo3.org/issues/951252021-09-06T15:55:54ZBenjamin Franzkeben@bnf.dev
<p>Steps to reproduce</p>
<p>Add something to ext_localconf.php that causes a PHP warning to occur, e.g.</p>
<p>`ext_localconf.php`:</p>
<pre><code class="php syntaxhl" data-language="php"><span class="nv">$foo</span> <span class="o">=</span> <span class="nb">file_get_contents</span><span class="p">(</span><span class="s1">'/tmp/path-to-missing-file.txt'</span><span class="p">);</span>
</code></pre>
<p>Then execute:</p>
<pre>
bin/typo3 cache:warmup
</pre>
<p>(or any other CLI command, but make sure to remove cached before)</p>
<p>Output:</p>
<pre>
PHP Deprecated: TYPO3\CMS\Core\Database\ConnectionPool can not be injected/instantiated during ext_localconf.php/TCA/ext_tables.php loading. Use lazy loading instead. in […]/typo3/sysext/core/Classes/ServiceProvider.php on line 142
</pre> TYPO3 Core - Bug #94453 (Closed): Deprecation log flooded with symfony ContainerInterface autowir...http://forge.typo3.org/issues/944532021-07-01T09:26:38ZBenjamin Franzkeben@bnf.dev
<pre>
TYPO3 Deprecation Notice: Since symfony/dependency-injection 5.1: The "Psr\Container\ContainerInterface" autowiring alias is deprecated. Define it explicitly in your app if you want to keep using it. It is being referenced by the "TYPO3\CMS\Core\Http\Dispatcher" service.
</pre> TYPO3 Core - Bug #94415 (Closed): Use runtime cache for LanguageServicehttp://forge.typo3.org/issues/944152021-06-25T14:18:28ZBenjamin Franzkeben@bnf.dev
<p>Move state for caching purposes<br />from $GLOBALS[LANG] into the runtime cache<br />allowing for further reducing the need to keep<br />the LanguageService in a global state.</p> TYPO3 Core - Bug #94135 (Closed): Typo3DbQueryParserTest fail with wrong timestamp when php timez...http://forge.typo3.org/issues/941352021-05-13T08:25:12ZBenjamin Franzkeben@bnf.dev
<p>My php timezone is Europe/Berlin and unit tests error in this case:</p>
<pre>
./bin/phpunit -d memory_limit=1G -c vendor/typo3/testing-framework/Resources/Core/Build/UnitTests.xml typo3/sysext/extbase/Tests/Unit/Persistence/Generic/Storage/Typo3DbQueryParserTest.php
1) TYPO3\CMS\Extbase\Tests\Unit\Persistence\Generic\Storage\Typo3DbQueryParserTest::visibilityConstraintStatementIsGeneratedAccordingToTheQuerySettings with data set "in fe: respect enable fields and do not include deleted" ('FE', false, array(), false, '(tx_foo_table.deleted_column ...79200)')
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'(tx_foo_table.deleted_column = 0) AND (tx_foo_table.disabled_column = 0) AND (tx_foo_table.starttime_column <= 1451779200)'
+'(tx_foo_table.deleted_column = 0) AND (tx_foo_table.disabled_column = 0) AND (tx_foo_table.starttime_column <= 1451775600)'
/home/ben/src/TYPO310.CMS/typo3/sysext/extbase/Tests/Unit/Persistence/Generic/Storage/Typo3DbQueryParserTest.php:607
/home/ben/src/TYPO310.CMS/vendor/phpunit/phpunit/phpunit:61
2) TYPO3\CMS\Extbase\Tests\Unit\Persistence\Generic\Storage\Typo3DbQueryParserTest::respectEnableFieldsSettingGeneratesCorrectStatement with data set "in FE: respectEnableFields=true" ('FE', true, '(tx_foo_table.deleted_column ...79200)')
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'(tx_foo_table.deleted_column = 0) AND (tx_foo_table.disabled_column = 0) AND (tx_foo_table.starttime_column <= 1451779200)'
+'(tx_foo_table.deleted_column = 0) AND (tx_foo_table.disabled_column = 0) AND (tx_foo_table.starttime_column <= 1451775600)'
/home/ben/src/TYPO310.CMS/typo3/sysext/extbase/Tests/Unit/Persistence/Generic/Storage/Typo3DbQueryParserTest.php:672
/home/ben/src/TYPO310.CMS/vendor/phpunit/phpunit/phpunit:61
</pre> 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 #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 #87997 (Rejected): Links to workspace overlays should not be generated without b...http://forge.typo3.org/issues/879972019-03-25T11:49:57ZBenjamin Franzkeben@bnf.dev
<p>If an editor links to a versioned page id (let's say 1011) directly (e.g. by specifying that id in header_link),<br />that link is currently generated as /index.php?id=1011 when the frontend is visited as a regular visitor (e.g. without backend/workspace context).</p>
<p>Visiting that page will fail with "page not found" (which is fine).</p>
<p>It would be expected that links wouldn't be generated at all (that means: link is empty), as for hidden/deleted pages.</p> 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 - Task #83953 (Closed): Inject the PackageManager into the DependencyResolverhttp://forge.typo3.org/issues/839532018-02-17T18:58:36ZBenjamin Franzkeben@bnf.dev