TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692023-07-12T15:02:45ZTYPO3 Forge
Redmine TYPO3 Core - Bug #101340 (Resolved): Switching tab in linkbrowser displays an errorhttp://forge.typo3.org/issues/1013402023-07-12T15:02:45ZRémy DANIEL
<p>Switching tab in linkbrowser displays an error :</p>
<pre>
Page tree error
Got unexpected response from the server. Please check logs for details.
</pre>
<p>This is because the ajax request of the "Pages" tab is not yet finished and get canceled.<br />It happens in a website with a big page tree.</p>
Step to reproduce:
<ol>
<li>add a sleep(2) in \TYPO3\CMS\Backend\Controller\Page\TreeController::fetchDataAction to simulate a big page tree</li>
<li>in a text content, add a link</li>
<li>switch rapidly to another tab of the link browser</li>
<li>observes the error in the upper right corner of the BE</li>
</ol>
<p>See attached screenshot</p> TYPO3 Core - Bug #100975 (New): Undefined property TYPO3\CMS\Linkvalidator\Task\ValidatorTask::$l...http://forge.typo3.org/issues/1009752023-06-08T06:53:42ZRémy DANIEL
<p>I can see this error in logs when a LinkValidator scheduler task is executed :</p>
<pre>
[ERROR] Warning: Undefined property:
TYPO3\CMS\Linkvalidator\Task\ValidatorTask::$logger
</pre>
<p>It's weird because $logger should be available, thanks the trait of the abstract class.<br />Maybe the serialization/unserialization of the task unsets $logger (see unsetScheduler method in AbstractTask ?).</p>
<p>Note: the error may occur for the first time only if the configuration emailTemplateName was left empty when the task was created. The missing configuration is automatically fixed and the task saved.</p>
<p>Note 2: I have no backtrace of the error</p> TYPO3 Core - Bug #100076 (Resolved): Inconsistent value of \TYPO3\CMS\Core\Imaging\GraphicalFunct...http://forge.typo3.org/issues/1000762023-03-03T18:17:49ZRémy DANIEL
<p>Depending of the inputs, getImageScale returns either int or float for the scaled width/heigth.</p>
<p>This can triggers strict type warnings in calling code, if width/heigth are expected to be integers.</p> TYPO3 Core - Bug #99079 (New): User tsconfig overridden by subgroupshttp://forge.typo3.org/issues/990792022-11-14T09:58:18ZRémy DANIEL
<p>Given the following TSconfig file:</p>
<pre>
# EXT:site/Configuration/TSconfig/user.tsconfig
options.clearCache.pages = 0
</pre>
<p>Given the following BE group setup:</p>
<ul>
<li>Group Default<br />tsconfig: <INCLUDE_TYPOSCRIPT: source="FILE:EXT:site/Configuration/TSconfig/user.tsconfig"></li>
</ul>
<ul>
<li>Group Special<br />subgroups: Default</li>
</ul>
<ul>
<li>Group Advanced editors<br />subgroups: Default<br />tsconfig: options.clearCache.pages = 1</li>
</ul>
<p>And given a user member of the groups "Advanced editors" and "Special".</p>
<p>This user does not see the clearCache.pages button.</p>
<p>The reason is the order in the resolution of the subgroups, and the tsconfig parsing (see \TYPO3\CMS\Core\Authentication\BackendUserAuthentication::prepareUserTsConfig)<br />The resolved subgroups are : Default, Advanced editors, Default, Special<br />For each of this groups, the TSconfig is computed:</p>
<pre>
# TSCONFIG of group Default
# INCLUDE EXT:site/Configuration/TSconfig/user.tsconfig
options.clearCache.pages = 0
# TSCONFIG of group Advanced editors
options.clearCache.pages = 1
# TSCONFIG of group Default
# EXT:site/Configuration/TSconfig/user.tsconfig
options.clearCache.pages = 0
# TSCONFIG of group Special
</pre>
<p>At the end, the all TSconfig is parsed, and options.clearCache.pages will be 0.</p>
<p>A possible fix will be that the parser includes file only once.</p>
<p>My workaround was to remove the subgroup Default from the group Special.</p> TYPO3 Core - Bug #96306 (Closed): TSFE set_no_cache should be loggued as notice in preview modehttp://forge.typo3.org/issues/963062021-12-09T14:35:24ZRémy DANIEL
<p>If TSFE->set_no_cache is called, either a warning or a notice is triggered.</p>
<p>Since <a class="issue tracker-4 status-5 priority-4 priority-default closed" title="Task: Deprecate TSFE constructor with no_cache parameter (Closed)" href="http://forge.typo3.org/issues/86002">#86002</a> and the use of backend.user aspect, preview mode is not considered anymore, <br />and warnings are triggered instead of notices.</p> TYPO3 Core - Bug #94109 (Closed): The Typoscript template analyzer displays an error with getEnvhttp://forge.typo3.org/issues/941092021-05-11T14:33:15ZRémy DANIEL
<p>I follow the possibility to "inject" environment variable in Typoscript, as described in the docs:</p>
<p><a class="external" href="https://docs.typo3.org/c/typo3/cms-core/master/en-us/Changelog/9.4/Feature-85146-ReadEnvironmentVariablesInTypoScript.html?highlight=getenv">https://docs.typo3.org/c/typo3/cms-core/master/en-us/Changelog/9.4/Feature-85146-ReadEnvironmentVariablesInTypoScript.html?highlight=getenv</a></p>
<p>The parsing and the "injection" work well, but the Typoscript template analyzer displays an error:</p>
<p><img src="http://forge.typo3.org/attachments/download/36059/image.png" alt="" loading="lazy" /></p> TYPO3 Core - Bug #93195 (Closed): cHash comparison failure on a workspace page previewhttp://forge.typo3.org/issues/931952020-12-31T12:13:53ZRémy DANIEL
<p><strong>Description of the bug</strong></p>
<p>I use f:uri.action to generate a link to an Extbase plugin, with some plugin arguments.<br />There is not RouteEnhancer on the plugin, so a cHash is added to the generated uri.</p>
<p>When the target page of the link is a draft version of the page, accessing the generated uri leads to a 404 (cHash comparison failed).</p>
<p><strong>How to reproduce</strong></p>
<p>It is not easy to reproduce, but here is some steps.</p>
<p>The issue exists since TYPO3 10. I cannot reproduce it on TYPO3 9.</p>
<ol>
<li>setup ext:workspace with one draft workspace</li>
<li>create a site with a rootpage and a working TS setup</li>
<li>switch to the draft workspace</li>
<li>on a page, create a TS template with this setup override: <br /> <pre>
page.10 >
page.10 = FLUIDTEMPLATE
page.10 {
template = TEXT
template.value = {f:uri.action(action: 'show', controller: 'Test', extensionName: 'Test', arguments: {foo: 'bar'})}
}</pre></li>
<li>the page has now a live version (uid=1, t3ver_wsid=0) and a draft version (uid=2, t3ver_oid=1, t3ver_wsid=1)</li>
<li>display the preview of the page: you see the uri generated with a cHash</li>
<li>go to the generated url: a 404 is triggered because of a cHash comparison failure</li>
</ol>
<p><strong>Debugging</strong></p>
<p>When building the cHash, the ID of the page is used along with other parameters in the cHash calculation .<br />When validating the cHash, the ID of the page found by the router is used (see <code>\TYPO3\CMS\Frontend\Middleware\PageArgumentValidator::getRelevantParametersForCacheHashCalculation</code>).<br />In most of the case, there is no reason that this page's id change, so this part of the cHash calculation/checking works well.</p>
<p>Now, while debugging, I found that when generating the uri, <ins>the uid of the live page is used</ins>.</p>
<p>But when the uri is requested and the cHash is validated, the page id is taken from <code>$request->getAttribute('routing')</code> (which is a PageArguments instance).<br /><ins>Here, the page id is the draft uid</ins>.</p>
<p>Because the page id are not the same, the cHash comparison could not succeed, and this will trigger a 404.</p> TYPO3 Core - Bug #93012 (Closed): Email address are not wrapped in A tag if config.spamProtectEma...http://forge.typo3.org/issues/930122020-12-07T09:56:45ZRémy DANIEL
<p>When the <code>config.spamProtectEmailAddresses</code> is set, a mailto:<a class="email" href="mailto:xxx@yyy.zzz">xxx@yyy.zzz</a> string passed through lib.parseFunc is transformed to a mailto link, with an href of the form "<code>javascript:linkTo_UnCryptMailto()</code>".</p>
<p>Problem, the <code><a></code> tag is removed in the rendered html, only the <a class="email" href="mailto:xxx@yyy.zzz">xxx@yyy.zzz</a> stays.</p>
<p>If I set <code>config.spamProtectEmailAddresses</code> to 0, the <code><a href="mailto:xxx@yyy.zzz">xxx@yyy.zzz</a></code> is present in the rendered html.</p>
<p>When debugging, I found that the <code>makelinks</code> conf of <code>lib.parseFunc</code> works well, but just after, the <code>tags.a</code> conf triggers a <code>TEXT</code> cObj with the <code><a href="javascript:linkTo_UnCryptMailto()">xxx@yyy.zzz</a></code> as value, and typolink removes the <code>javascript:</code> href, for security reason (see <code>ContentObjectRenderer->resolveMixedLinkParameter</code>)</p>
<p><strong>How to reproduce:</strong></p>
<pre>
page = PAGE
page.config.disableAllHeaderCode = 1
page.config.spamProtectEmailAddresses = -3
page.10 = TEXT
page.10.value = mailto:xxx@yyy.zzz
page.10.stdWrap.parseFunc < lib.parseFunc
</pre> TYPO3 Core - Bug #92762 (Closed): Accessing a restricted subpage of a sysfolder triggers a 404 in...http://forge.typo3.org/issues/927622020-11-03T19:06:10ZRémy DANIEL
<p>On TYPO3 9, accessing a restricted subpage of a sysfolder triggered a 403.<br />On TYPO3 10, a 404 is triggered.</p>
<p>This is a regression introduced in <a class="external" href="https://review.typo3.org/c/Packages/TYPO3.CMS/+/58829">https://review.typo3.org/c/Packages/TYPO3.CMS/+/58829</a></p>
<p><strong>How to reproduce</strong></p>
<p>With the following page tree:</p>
<pre>
Rootpage
- page 1 (public, enabled)
- sysfolder 3 (enabled)
-- subpage 2 (restricted to authenticated users, enabled)
</pre>
<p>Without a frontend session, access the subpage 2 triggers a 404.</p>
<p><strong>What should I see?</strong></p>
<p>Without a frontend session, access the subpage B should trigger a 403.</p> TYPO3 Core - Bug #92442 (New): Preview of a record's translation is not show if parent is hiddenhttp://forge.typo3.org/issues/924422020-09-29T13:00:03ZRémy DANIEL
<p>Hi</p>
<p>Given the following record set:</p>
<ul>
<li>record 1, sys_language_uid=0, hidden=1</li>
<li>record 2, sys_language_uid=1, l10n_parent=1, hidden=1</li>
</ul>
<p>Make an extbase plugin which lists the records using an extbase repository, and put this plugin on a page.</p>
<p><strong>The issue</strong></p>
<p>In the admin panel I check "show hidden records" and I can preview the record 1 if FE language is 0.<br />If FE language is 1, I cannot preview the record 2.<br />If I unhide the record 1, its works: I can see the record 2.</p>
<p><strong>Expected</strong></p>
<p>I should be able to preview a hidden record either if it is a base record or a translation, and whatever the hidden status of the base record is.</p>
<p><strong>Explanation and fix proposal</strong></p>
<p>The issue resides in Typo3DbQueryParser::addTypo3Constraints() which uses a doctrine query builder in order to add the additional where clause related to localization handling (content fallback + hideNonTranslated).<br />But the query builder is using the DefaultRestrictionContainer, which does not check the Visibility aspect at all when building the expressions.</p>
<p>In order to fix the issue, Typo3DbQueryParser must check for frontend mode, and set FrontendRestrictionContainer instead of DefaultRestrictionContainer in the needed query builders.</p> TYPO3 Core - Bug #92399 (New): Scheduler tasks are executed in the same php processhttp://forge.typo3.org/issues/923992020-09-24T16:41:51ZRémy DANIEL
<p>Hi.</p>
<p>The new scheduler:run command runs tasks in a loop.<br />This can be an issue, because a single php process runs several tasks and those tasks share the same memory.</p>
<p>Example :<br />I have an issue with Solr indexing tasks: a site A is indexed and loads singletons (Extbase's configuration manager), then the site B gets the configuration manager of the site A! (both sites are on the same TYPO3 instance).</p>
<p>I attached a patch which modifies the scheduler command in order to execute task in subprocesses.</p> TYPO3 Core - Bug #92068 (Closed): felogin (extbase) redirect from GET/POST is not working properlyhttp://forge.typo3.org/issues/920682020-08-21T19:31:52ZRémy DANIEL
<p>Take a felogin form (the new one of TYPO3 v10 made with Extbase)<br />Add it to a /login page with the following flexform settings:</p>
<p>Redirect modes:<br />- Defined by GET/POST parameter<br />- After login<br />Check "Use First Supported Mode from Selection" <br />Set a page from your page tree in "After Successful Login Redirect to Page"</p>
<p>With those settings, I expect two things:</p>
<p>A. I access directly the /login page, I should see the login form.<br />Then I log in and I should be redirected to the page set in "After Successful Login Redirect to Page"</p>
<p>B. I access a restricted page /private-page with a non logged-in user.<br />Now TYPO3 should trigger a 403 error, and my custom PageErrorHandler should redirect me to /login?redirect_url=/private-page<br />Now I should see the login form.<br />Then I log in, and should be redirected to /private-page</p>
<p>On TYPO3 v10.4.6, the scenario B is not working.<br />The ?redirect_url=/private-page GET parameter is not propagated to the <input hidden name="redirect_url">,<br />so the redirect_url is lost when the form is posted.</p>
<p>This scenario used to work with the pi_base version in v9.</p> TYPO3 Core - Bug #90063 (Closed): GeneralUtility::writeFileToTypo3tempDir returns always an error...http://forge.typo3.org/issues/900632020-01-07T10:42:15ZRémy DANIEL
<p>TYPO3 9 + composer mode</p>
<p>The above code returns always an error, but the file is correctly created:</p>
<pre><code class="php syntaxhl" data-language="php"><span class="nv">$filepath</span> <span class="o">=</span> <span class="s1">'/var/www/html/web/typo3temp/var/tx_static404/foo.txt'</span><span class="p">;</span>
<span class="nv">$error</span> <span class="o">=</span> <span class="nc">\TYPO3\CMS\Core\Utility\GeneralUtility</span><span class="o">::</span><span class="nf">writeFileToTypo3tempDir</span><span class="p">(</span><span class="nv">$filepath</span><span class="p">,</span> <span class="s1">'foo'</span><span class="p">);</span>
<span class="c1">// $error contains '"/var/www/html/web/typo3temp/var/tx_static404/" was not within directory ProjectPath + var' instead of NULL</span>
</code></pre>
<p>The issue is that writeFileToTypo3tempDir checks if the directory of the file is within two allowed pathes:<br />- Environment::getPublicPath() + "/typo3temp/" <br />- Environment::getVarPath()</p>
<p>But even if the file is written in the within the first path, the second path is still checked.</p>
<p>The foreach should break as soon as the file is successfully created, and returns NULL error message, as expected.</p> TYPO3 Core - Bug #89730 (Closed): The EmailFinisher does not parse variables before assigning to ...http://forge.typo3.org/issues/897302019-11-21T18:54:26ZRémy DANIEL
<p>Hello</p>
<p><strong>Context</strong></p>
<p>Following this guide: [<a class="external" href="https://docs.typo3.org/c/typo3/cms-form/8.7/en-us/Concepts/FrontendRendering/Index.html#concepts-frontendrendering-codecomponents-customfinisherimplementations-finishercontext-sharedatabetweenfinishers">https://docs.typo3.org/c/typo3/cms-form/8.7/en-us/Concepts/FrontendRendering/Index.html#concepts-frontendrendering-codecomponents-customfinisherimplementations-finishercontext-sharedatabetweenfinishers</a>]</p>
<p>I am trying to get a variable from a previous finisher and to set it in the variables of a next finisher.<br />Here is the summary of the finishers in the form definition:</p>
<pre>
finishers:
-
identifier: SaveToDatabase
options:
table: 'tx_myext_domain_model_offer'
mode: 'insert'
...
-
identifier: EmailFinisher
options:
...
variables:
recordUid: '{SaveToDatabase.insertedUids.0}'
</pre>
<p><strong>Issue</strong></p>
<p>In the fluid template of the email, the value of the variable <code>{recordUid}</code> is <code>SaveToDatabase.insertedUids.0</code>.</p>
<p><strong>Expected</strong></p>
<p>In the fluid template of the email, the value of the variable <code>{recordUid}</code> should be the UID of the record created by the finisher SaveToDatabase.</p>
<p><strong>Solution</strong></p>
<p>In \TYPO3\CMS\Form\Domain\Finishers\EmailFinisher::initializeStandaloneView(), <code>$this->parseOption</code> should be used instead of directly accessing <code>$this->options</code>.</p>
<p>Reproduced on TYPO3 8 and 9.</p> TYPO3 Core - Bug #50873 (Closed): sectionIndex menu is empty when the page is not in menuhttp://forge.typo3.org/issues/508732013-08-07T14:34:03ZRémy DANIEL
<p>In AbstractMenuContentObject::sectionIndex(), sectionIndex menu items are first based on the page record, and then overridden with tt_content properties.</p>
<p>But if $basePageRow has the 'nav_hide' property set to 1, then the resulting menuItem will systematically failed in AbstractMenuContentObject::filterMenuPages().</p>
<p>We have already the tt_content's 'sectionIndex' property in order to exclude a tt_content element from a sectionIndex menu, so I see no reason to not to unset 'nav_hide'.</p>
<p>To fix that, we need to force 'nav_hide' on the menuItem to 0 in AbstractMenuContentObject::sectionIndex().</p>
<p>Patch included, tested on TYPO3 6.1 (should be OK on earlier version)</p>