TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692023-11-15T09:10:28ZTYPO3 Forge
Redmine TYPO3 Core - Bug #102374 (Resolved): Missing null check in redirect slug update hookhttp://forge.typo3.org/issues/1023742023-11-15T09:10:28ZMathias Brodalambrodala@pagemachine.de
<p>With <a class="issue tracker-4 status-5 priority-4 priority-default closed" title="Task: Unneeded pseudo-uncertain instanceof usage (Closed)" href="http://forge.typo3.org/issues/102140">#102140</a> various <code>instanceof</code> checks where removed. In case of the <code>DataHandlerSlugUpdateHook</code> of EXT:redirects this check also did ensure that unprocessable items are skipped. This is not the case anymore which can cause an error like this:</p>
<p><a class="external" href="https://github.com/pagemachine/typo3-flat-urls/actions/runs/6874052335/job/18695061932#step:3:476">https://github.com/pagemachine/typo3-flat-urls/actions/runs/6874052335/job/18695061932#step:3:476</a></p>
<blockquote>
<p>Error: Call to a member function withChanged() on null</p>
</blockquote> TYPO3 Core - Bug #95868 (Closed): Invalid example for RenderFormValueViewHelperhttp://forge.typo3.org/issues/958682021-11-04T10:35:43ZMathias Brodalambrodala@pagemachine.de
<p>With <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Add option to get a single processed form value (Closed)" href="http://forge.typo3.org/issues/84713">#84713</a> the <code>RenderFormValueViewHelper</code> has been introduced.</p>
<p>The related changelog entry refers to <code>{page.rootForm.elements.*}</code> which does not exist. This must be <code>{form.formDefinition.elements.*}</code> instead.</p> TYPO3 Core - Bug #93368 (Needs Feedback): Domain redirects to records not working anymorehttp://forge.typo3.org/issues/933682021-01-26T11:47:22ZMathias Brodalambrodala@pagemachine.de
<p>Given domain redirects to records when a domain for such a redirect is requested a 404 error is triggered instead of a redirect.</p>
<p>Criteria to trigger this behavior:</p>
<ol>
<li>The <code>base</code> of all sites must be a full URL like <code>http://example.org/</code>, not simply <code>/</code> (slash).</li>
<li>The incoming domain must not be the <code>base</code> of any site.</li>
<li>The redirect must point to a record URN like <code>t3://record?identifier=<identifier>&uid=<uid></code>. (There's an automatic fallback in case of <code>t3://page</code> URNs.)</li>
</ol>
<p>The incoming domain does not match the <code>base</code> of any site which is why a <code>NullSite</code> is used instead while matching redirects. Due to this <code>TypoScriptFrontendController::getPageAndRootline()</code> (called from <code>RedirectService::bootFrontendController()</code>) triggers an immediate 404 response. This prevents the record URN to be resolved to a valid URL.</p>
<p>As a workaround one can override <code>RedirectService::getTargetUrl()</code> and fall back to any valid site.</p> TYPO3 Core - Bug #92568 (Closed): PopulatePageSlugs upgrade wizard migrates wrong RealURL path da...http://forge.typo3.org/issues/925682020-10-15T09:58:34ZMathias Brodalambrodala@pagemachine.de
<p>The <code>PopulatePageSlugs</code> upgrade wizard allows to migrate entries from <code>tx_realurl_pathdata</code>. However, due to an additional <code>DESC</code> sorting, the wrong entry is used in case there is more than one for a page. This can actually happen often for <code>$reasons</code>.</p>
<p>Given the following two entries in <code>tx_realurl_pathdata</code>:</p>
<table>
<tr>
<th>uid </th>
<th>... </th>
<th>pagepath </th>
<th>expire </th>
</tr>
<tr>
<td> 1 </td>
<td> ... </td>
<td> first/path </td>
<td> 0 </td>
</tr>
<tr>
<td> 2 </td>
<td> ... </td>
<td> second/path </td>
<td> 0 </td>
</tr>
</table>
<p>RealURL will use the <code>first/path</code>, but the <code>PopulatePageSlugs</code> upgrade wizard will use the <code>second/path</code>. This leads to changed URLs after the upgrade.</p>
<p>RealURL itself does not apply any explicit sorting:</p>
<p><a class="external" href="https://github.com/dmitryd/typo3-realurl/blob/2.6.2/Classes/Cache/DatabaseCache.php#L286">https://github.com/dmitryd/typo3-realurl/blob/2.6.2/Classes/Cache/DatabaseCache.php#L286</a></p>
<pre><code class="php syntaxhl" data-language="php"> <span class="nv">$row</span> <span class="o">=</span> <span class="nv">$this</span><span class="o">-></span><span class="n">databaseConnection</span><span class="o">-></span><span class="nf">exec_SELECTgetSingleRow</span><span class="p">(</span><span class="s1">'*'</span><span class="p">,</span> <span class="s1">'tx_realurl_pathdata'</span><span class="p">,</span>
<span class="s1">'pid='</span> <span class="mf">.</span> <span class="p">(</span><span class="n">int</span><span class="p">)</span><span class="nv">$pageId</span> <span class="mf">.</span>
<span class="s1">' AND language_id='</span> <span class="mf">.</span> <span class="p">(</span><span class="n">int</span><span class="p">)</span><span class="nv">$languageId</span> <span class="mf">.</span>
<span class="s1">' AND rootpage_id='</span> <span class="mf">.</span> <span class="p">(</span><span class="n">int</span><span class="p">)</span><span class="nv">$rootPageId</span> <span class="mf">.</span>
<span class="s1">' AND mpvar='</span> <span class="mf">.</span> <span class="p">(</span><span class="nv">$mpVar</span> <span class="o">?</span> <span class="nv">$this</span><span class="o">-></span><span class="n">databaseConnection</span><span class="o">-></span><span class="nf">fullQuoteStr</span><span class="p">(</span><span class="nv">$mpVar</span><span class="p">,</span> <span class="s1">'tx_realurl_pathdata'</span><span class="p">)</span> <span class="o">:</span> <span class="s1">'\'\''</span><span class="p">)</span> <span class="mf">.</span>
<span class="s1">' AND expire=0'</span>
<span class="p">);</span>
</code></pre>
<p>Thus in this case <code>ASC</code> is used by default.</p> TYPO3 Core - Bug #89616 (Closed): Extbase returns deleted objects if only endtime is configuredhttp://forge.typo3.org/issues/896162019-11-08T12:50:25ZMathias Brodalambrodala@pagemachine.de
<p>Given a table configured like this in TCA:</p>
<pre><code class="php syntaxhl" data-language="php"><span class="k">return</span> <span class="p">[</span>
<span class="s1">'ctrl'</span> <span class="o">=></span> <span class="p">[</span>
<span class="c1">// ...</span>
<span class="s1">'delete'</span> <span class="o">=></span> <span class="s1">'deleted'</span><span class="p">,</span>
<span class="s1">'enablecolumns'</span> <span class="o">=></span> <span class="p">[</span>
<span class="s1">'endtime'</span> <span class="o">=></span> <span class="s1">'endtime'</span><span class="p">,</span>
<span class="p">],</span>
<span class="c1">// ...</span>
<span class="p">],</span>
<span class="c1">// ...</span>
<span class="p">];</span>
</code></pre>
<p>If used in the BE/CLI context, Extbase will now return deleted rows in case <code>endtime</code> is <code>0</code>.</p>
<p>This is caused by Extbase's usage of <code>BackendUtility::BEenableFields()</code> will lead <code>Typo3DbQueryParser::getBackendConstraintStatement()</code> to generate a broken statement fragment like this:</p>
<pre><code class="sql syntaxhl" data-language="sql"> <span class="k">AND</span> <span class="p">(</span><span class="nv">`tx_mytable`</span><span class="p">.</span><span class="nv">`endtime`</span> <span class="o">=</span> <span class="mi">0</span><span class="p">)</span> <span class="k">OR</span> <span class="p">(</span><span class="nv">`tx_mytable`</span><span class="p">.</span><span class="nv">`endtime`</span> <span class="o">></span> <span class="mi">1573213620</span><span class="p">)</span> <span class="k">AND</span> <span class="n">tx_mytable</span><span class="p">.</span><span class="n">deleted</span><span class="o">=</span><span class="mi">0</span>
</code></pre>
<p>This allows selecting rows which are <code>deleted</code> as long as <code>endtime</code> is <code>0</code></p>
<p>Workaround: add at least one additional <code>enablecolumn</code>, so either <code>disabled</code> or <code>starttime</code>. This will lead to a working statement fragment like this:</p>
<pre><code class="sql syntaxhl" data-language="sql"> <span class="k">AND</span> <span class="p">(</span><span class="nv">`tx_mytable`</span><span class="p">.</span><span class="nv">`starttime`</span> <span class="o"><=</span> <span class="mi">1573214160</span><span class="p">)</span> <span class="k">AND</span> <span class="p">((</span><span class="nv">`tx_mytable`</span><span class="p">.</span><span class="nv">`endtime`</span> <span class="o">=</span> <span class="mi">0</span><span class="p">)</span> <span class="k">OR</span> <span class="p">(</span><span class="nv">`tx_mytable`</span><span class="p">.</span><span class="nv">`endtime`</span> <span class="o">></span> <span class="mi">1573214160</span><span class="p">))</span> <span class="k">AND</span> <span class="n">tx_mytable</span><span class="p">.</span><span class="n">deleted</span><span class="o">=</span><span class="mi">0</span>
</code></pre> TYPO3 Core - Task #89481 (Closed): Add security reporting procedure to READMEhttp://forge.typo3.org/issues/894812019-10-23T09:08:10ZMathias Brodalambrodala@pagemachine.de
<p>The current README does not have a single mention how security issues should be reported. This can lead to public reports which violates the <a href="https://en.wikipedia.org/wiki/Responsible_disclosure" class="external">responsible disclosure</a> principle.</p> TYPO3 Core - Bug #88806 (Closed): "Test Mail Setup" broken: Too few arguments to function EventDi...http://forge.typo3.org/issues/888062019-07-19T16:29:10ZMathias Brodalambrodala@pagemachine.de
<p>Using <strong>Test Mail Setup</strong> in the <strong>Environment</strong> module currently fails with an error which can be found in the TYPO3 logfile:</p>
<code>
Fri, 19 Jul 2019 16:25:30 +0200 [CRITICAL] request="262570147be62" component="TYPO3.CMS.Core.Error.DebugExceptionHandler": Core: Exception handler (WEB): Uncaught TYPO3 Exception: Too few arguments to function TYPO3\CMS\Core\EventDispatcher\EventDispatcher::__construct(), 0 passed in /.../typo3/sysext/core/Classes/Utility/GeneralUtility.php on line 3450 and exactly 1 expected | ArgumentCountError thrown in file /.../typo3/sysext/core/Classes/EventDispatcher/EventDispatcher.php in line 35. Requested URL: http://.../typo3/install.php?install[controller]=environment&install[context]=backend - {"TYPO3_MODE":"BE","exception":{}}
</code>
<p>For some reason dependency injection does not seem to be working properly here.</p> TYPO3 Core - Bug #88515 (Accepted): Cannot unset DateTime value via nullhttp://forge.typo3.org/issues/885152019-06-07T11:15:44ZMathias Brodalambrodala@pagemachine.de
<p>Given an Extbase domain model with a <code>DateTime</code> property and a DB field declared as usual:</p>
<pre><code>my_date int(11) unsigned DEFAULT '0' NOT NULL</code></pre>
<p>Setting a value here from a Fluid form works fine and the date is stored as timestamp in the DB.</p>
<p>However, when trying to clear this property, an <code>SqlException</code> occurs:</p>
<blockquote>
<p>(1/1) #1470230767 TYPO3\CMS\Extbase\Persistence\Generic\Storage\Exception\SqlErrorException<br />Column 'my_date' cannot be null</p>
<p>in /.../typo3/sysext/extbase/Classes/Persistence/Generic/Storage/Typo3DbBackend.php line 197</p>
</blockquote>
<p>The error occurs when <code>Backend::persistObject()</code> calls <code>DataMapper::getPlainValue()</code> with the current <code>null</code> value for the <code>DateTime</code> property and thus gets a string <code>"NULL"</code> in return. This then fails because <code>null</code> values are not allowed here in SQL.</p>
<p>An override of <code>AbstractDomainObject::_getProperties()</code> with a fallback to <code>0</code> (zero) for date properties works around the issue, however this should be fixed in Extbase itself:</p>
<pre><code class="php syntaxhl" data-language="php"><span class="k">public</span> <span class="k">function</span> <span class="n">_getProperties</span><span class="p">():</span> <span class="kt">array</span>
<span class="p">{</span>
<span class="nv">$properties</span> <span class="o">=</span> <span class="k">parent</span><span class="o">::</span><span class="nf">_getProperties</span><span class="p">();</span>
<span class="nv">$properties</span><span class="p">[</span><span class="s1">'myDate'</span><span class="p">]</span> <span class="o">??=</span> <span class="mi">0</span><span class="p">;</span>
<span class="k">return</span> <span class="nv">$properties</span><span class="p">;</span>
<span class="p">}</span>
</code></pre> TYPO3 Core - Bug #87519 (Closed): Class 'TYPO3\CMS\Core\Http\JsonResponse' not foundhttp://forge.typo3.org/issues/875192019-01-22T12:39:40ZMathias Brodalambrodala@pagemachine.de
<p>The <code>RequireJsController</code> uses the <code>JsonResponse</code> class in TYPO3v8 which was added with TYPO3v9 however.</p>
<p>This must be rewritten to not break the BE login.</p> TYPO3 Core - Bug #86743 (Closed): Inline "then"/"else" not working for IfHasRoleViewHelperhttp://forge.typo3.org/issues/867432018-10-25T11:08:02ZMathias Brodalambrodala@pagemachine.de
<p>Since TYPO3v8 using the inline <code>then</code> and <code>else</code> arguments on the <code>IfHasRoleViewHelper</code> does not work anymore.</p>
<p>Thus <code>{f:security.ifHasRole(role: 10, then: 'YES', else: 'NO')}</code> leads to an error:</p>
<blockquote>
<p>Undeclared arguments passed to ViewHelper TYPO3\CMS\Fluid\ViewHelpers\Security\IfHasRoleViewHelper: then, else. Valid arguments are: role</p>
</blockquote>
<p>This happens because <code>IfHasRoleViewHelper::initializeArguments()</code> does not call the same method of <code>TYPO3Fluid\Fluid\Core\ViewHelper\AbstractConditionViewHelper</code>.</p>
<p>In TYPO3v7 this was avoided because <code>TYPO3\CMS\Fluid\Core\ViewHelper\AbstractConditionViewHelper</code> did register these arguments in its constructor. Thus this is a regression.</p> TYPO3 Core - Bug #86544 (Closed): Installation acceptance tests failhttp://forge.typo3.org/issues/865442018-10-02T15:09:34ZMathias Brodalambrodala@pagemachine.de
<p>The acceptance tests use the introduction package and wait for the text <em>Let us introduce you to TYPO3</em> in the frontend after the installation. This text has been removed with version 4.0.0 of the introduction package, thus all tests need to be updated accordingly to look for a different text.</p> TYPO3 Core - Bug #85988 (Closed): @cli annotation deprecated without replacementhttp://forge.typo3.org/issues/859882018-08-27T11:10:51ZMathias Brodalambrodala@pagemachine.de
<p>With <a class="issue tracker-4 status-5 priority-4 priority-default closed" title="Task: Deprecate @cli annotation (Closed)" href="http://forge.typo3.org/issues/85977">#85977</a> the <code>@cli</code> annotation has been deprecated without replacement but hinting at a successor in TYPO3v10. No matter if and when this will really happen we cannot do a deprecation without a replacement so this change needs to be reverted.</p> TYPO3 Core - Bug #85531 (Closed): Error with "select" and "group" field using l10n_display "defau...http://forge.typo3.org/issues/855312018-07-10T16:00:07ZMathias Brodalambrodala@pagemachine.de
<p>When editing a translated record which contains a <code>group</code> field whose <code>l10n_display</code> is configured as <code>defaultAsReadonly</code> an exception occurs:</p>
<pre>
#1476107295: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /.../typo3/sysext/backend/Classes/Form/Element/GroupElement.php line 120 (More information)
TYPO3\CMS\Core\Error\Exception thrown in file
/.../typo3/sysext/core/Classes/Error/ErrorHandler.php in line 115.
38 TYPO3\CMS\Core\Error\ErrorHandler::handleError(2, "count(): Parameter must be an array or an object that implements Countable", "/.../typo3/sysext/backend/Classes/Form/Element/GroupElement.php", 120, array)
37 count("1")
/.../typo3/sysext/backend/Classes/Form/Element/GroupElement.php:
00118:
00119: $selectedItems = $parameterArray['itemFormElValue'];
00120: $selectedItemsCount = count($selectedItems);
00121:
00122: $maxItems = $config['maxitems'];
</pre>
<p>A similar error occurs a little later on TYPO3v8:</p>
<pre>
#1476107295: PHP Warning: Invalid argument supplied for foreach() in /.../typo3/sysext/backend/Classes/Form/Element/GroupElement.php line 158 (More information)
TYPO3\CMS\Core\Error\Exception thrown in file
/.../typo3/sysext/core/Classes/Error/ErrorHandler.php in line 107.
17 TYPO3\CMS\Core\Error\ErrorHandler::handleError(2, "Invalid argument supplied for foreach()", "/.../typo3/sysext/backend/Classes/Form/Element/GroupElement.php", 158, array)
/.../typo3/sysext/backend/Classes/Form/Element/GroupElement.php:
00156: }
00157: } elseif ($internalType === 'db') {
00158: foreach ($selectedItems as $selectedItem) {
00159: $tableWithUid = $selectedItem['table'] . '_' . $selectedItem['uid'];
00160: $listOfSelectedValues[] = $tableWithUid;
</pre>
<p>The code here expects an array but gets an integer (number of related records) instead.</p>
<p>This is triggered by the <code>SingleFieldContainer</code> which replaces the <code>databaseRow</code> value prepared by <code>TcaGroup</code> with the raw value from <code>defaultLanguageRow</code> in case <code>l10n_display</code> is set to <code>defaultAsReadonly</code>.</p>
<p>This error does not occur on TYPO3v7 but the field is empty instead there.</p>
<p>This can be reproduced e.g. with the following steps:</p>
<ol>
<li>Add <code>'l10n_display' => 'defaultAsReadonly'</code> to <code>$GLOBALS['TCA']['tt_content']['columns']['file_collections']</code></li>
<li>Create an empty file collection on a page</li>
<li>Add a <em>File links</em> content element to that page and select the created file collection</li>
<li>Translate the page and the <em>File links</em> content element</li>
<li>Edit the translated <em>File links</em> content element and see the error</li>
</ol> TYPO3 Core - Bug #85302 (Closed): ResourceStorage throws wrong exception on folder move between s...http://forge.typo3.org/issues/853022018-06-18T15:33:00ZMathias Brodalambrodala@pagemachine.de
<p>The method <code>ResourceStorage::moveFolderBetweenStorages()</code> is currently not implemented and it throws a <code>RuntimeException</code>.</p>
<p>However, the <code>ExtendedFileUtility::func_move()</code> method implies that this should be a <code>BadMethodCallException</code> instead:</p>
<pre><code class="php syntaxhl" data-language="php"> <span class="k">catch</span> <span class="p">(</span><span class="nc">\BadMethodCallException</span> <span class="nv">$e</span><span class="p">)</span> <span class="p">{</span>
<span class="nv">$this</span><span class="o">-></span><span class="nf">writeLog</span><span class="p">(</span><span class="mi">3</span><span class="p">,</span> <span class="mi">1</span><span class="p">,</span> <span class="mi">126</span><span class="p">,</span> <span class="s1">'The function to move a file between storages is not yet implemented'</span><span class="p">,</span> <span class="p">[]);</span>
<span class="nv">$this</span><span class="o">-></span><span class="nf">addMessageToFlashMessageQueue</span><span class="p">(</span><span class="s1">'FileUtility.TheFunctionToMoveAFileBetweenStoragesIsNotYetImplemented'</span><span class="p">);</span>
<span class="p">}</span>
</code></pre>
<p>Due to this users get a misleading error messages which hints at write permission problems (<code>FileUtility.DirectoryWasNotMovedTo</code>) instead of the dedicated message which informs that this action is not yet implemented (<code>FileUtility.TheFunctionToMoveAFileBetweenStoragesIsNotYetImplemented</code>).</p> TYPO3 Core - Bug #85139 (Closed): Invalid arguments for method call matcherhttp://forge.typo3.org/issues/851392018-06-01T12:31:22ZMathias Brodalambrodala@pagemachine.de
<p>The changes from <a class="issue tracker-4 status-5 priority-4 priority-default closed" title="Task: Deprecate usages of CharsetConverter in core (Closed)" href="http://forge.typo3.org/issues/85125">#85125</a> and <a class="issue tracker-4 status-5 priority-4 priority-default closed" title="Task: Deprecate Backend Module Routing methods (Closed)" href="http://forge.typo3.org/issues/85113">#85113</a> introduced an invalid/incomplete argument configuration for the method call matcher. These should be fixed.</p>