TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692021-01-26T11:47:22ZTYPO3 Forge
Redmine 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 #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 - 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 #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 #84973 (Closed): Cannot delete invalid Scheduler taskhttp://forge.typo3.org/issues/849732018-05-11T17:39:24ZMathias Brodalambrodala@pagemachine.de
<p>When trying to delete an invalid Scheduler task (e.g. due to the related code being removed) an error occurs:</p>
<pre>
Fatal error: TYPO3\CMS\Scheduler\Scheduler::isValidTaskObject(): The script tried to execute a method or access a property of an incomplete object. Please ensure that the class definition &quot;<Task>&quot; of the object you are trying to operate on was loaded _before_ unserialize() gets called or provide a __autoload() function to load the class definition in /.../typo3/sysext/scheduler/Classes/Scheduler.php on line 449
</pre> TYPO3 Core - Bug #84491 (Closed): Breaks field in EXT:styleguidehttp://forge.typo3.org/issues/844912018-03-20T09:21:36ZMathias Brodalambrodala@pagemachine.de
<p>EXT:styleguide, elements basic > text_17 breaks with</p>
<blockquote>
<p>Argument 2 passed to TYPO3\CMS\Backend\Controller\Wizard\TableController::configurationStringToArray() must be of the type integer, null given, called in /.../typo3/sysext/backend/Classes/Controller/Wizard/TableController.php on line 496</p>
</blockquote> TYPO3 Core - Bug #84178 (Closed): Cannot create but upload file with "@" in namehttp://forge.typo3.org/issues/841782018-03-08T14:45:32ZMathias Brodalambrodala@pagemachine.de
<p>In FAL there are at least two different ways to create files which apparently do not apply the same sanitation/validation rules to file names.</p>
<p>This can be verified easily in the <strong>Filelist</strong> module: if you try to upload a file called <strong><a class="email" href="mailto:foo@bar.txt">foo@bar.txt</a></strong> everything simply works.</p>
<p>But if you create a file called <strong><a class="email" href="mailto:foo@bar.txt">foo@bar.txt</a></strong> a <code>ResourceDoesNotExistException</code> is thrown:</p>
<pre>
#1329647780: Object with identifier "1:/foo@bar.txt" does not exist in storage
</pre>
<p>When opening the file list once more after this, an error flash message is shown which says <em>File name "<a class="email" href="mailto:foo@bar.txt">foo@bar.txt</a>" was not allowed!</em>.</p>
<p>This behavior can be traced back to these two code paths:</p>
<ul>
<li><code>LocalDriver::addFile()</code> calls <code>LocalDriver::sanitizeFileName()</code> which accepts <strong><a class="email" href="mailto:foo@bar.txt">foo@bar.txt</a></strong> (this is used e.g. for file uploads)</li>
<li><code>LocalDriver::createFile()</code> calls <code>AbstractDriver::isValidFilename()</code> which denies <strong><a class="email" href="mailto:foo@bar.txt">foo@bar.txt</a></strong> (this is used for everything else)</li>
</ul> TYPO3 Core - Bug #83692 (Closed): Missing renderType for sys_redirect.target_statuscodehttp://forge.typo3.org/issues/836922018-01-26T15:45:46ZMathias Brodalambrodala@pagemachine.de
<p>Flushing all caches and refreshing the redirect module gives the following message:</p>
<blockquote>
<p>TYPO3 Deprecation Notice<br />Core: Error handler (BE): TYPO3 Deprecation Notice: Automatic TCA migration done during bootstrap. Please adapt TCA accordingly, these migrations will be removed. The backend module "Configuration -> TCA" shows the modified values. Please adapt these areas: Using the 'type' = 'select' field in "sys_redirect['columns']['target_statuscode']['config']['type'] = 'select'" without the "renderType" setting in "sys_redirect['columns']['target_statuscode']['config']['renderType']" is deprecated. The TCA table 'pages_language_overlay' is not used anymore and has been removed automatically in order to avoid negative side-effects. in /.../typo3/sysext/core/Classes/Utility/ExtensionManagementUtility.php line 1705</p>
</blockquote>
<p>Thus a <code>'renderType' => 'selectSingle'</code> must be set for the <code>target_statuscode</code> field.</p> TYPO3 Core - Bug #83177 (Closed): State not immediately updated after enabling/disabling pagehttp://forge.typo3.org/issues/831772017-11-30T15:07:58ZMathias Brodalambrodala@pagemachine.de
<p>When enabling/disabling pages, the new page tree quickly refreshes but no change is visible. Only explicitly refreshing the tree or TYPO3 backend makes the change visible.</p> TYPO3 Core - Bug #83176 (Closed): Cannot move page to the end of the treehttp://forge.typo3.org/issues/831762017-11-30T15:05:48ZMathias Brodalambrodala@pagemachine.de
<p>With the new page tree pages cannot be moved to the end anymore, only between other pages.</p> TYPO3 Core - Bug #82852 (Closed): Empty page with invalid config.metaCharsethttp://forge.typo3.org/issues/828522017-10-25T09:12:43ZMathias Brodalambrodala@pagemachine.de
<p>If an invalid value is set for <code>config.metaCharset</code>, the whole page output is dropped and an empty page is shown instead.</p>
<p>There was a workaround added (<a class="issue tracker-1 status-5 priority-3 priority-lowest closed behind-schedule" title="Bug: No output in FE of 8.7.2 due to config.metaCharset = UTF-8 (Closed)" href="http://forge.typo3.org/issues/81634">#81634</a>) for cases like <code>UTF-8</code> instead of <code>utf-8</code> but there are millions of ways of doing it wrong, e.g. <code>utf8</code> instead of <code>utf-8</code>.</p>
<p>Instead of silently dropping the page content without notice, an error should be thrown which clearly hints at the error.</p> TYPO3 Core - Bug #82790 (New): Finisher FormEngine definition fails with nested optionshttp://forge.typo3.org/issues/827902017-10-17T16:48:25ZMathias Brodalambrodala@pagemachine.de
<p>If a finisher is configured by nested options (similar to <code>elements</code> or <code>databaseColumnMappings</code> of the <code>SaveToDatabase</code> finisher), an error will occur while the FlexForm of a form plugin is being built. This causes the option in question and all other following options to be skipped entirely.</p>
<p>This is caused by e.g. <code>option.nestedKey</code> being looked up in <code>TYPO3.CMS.Form.prototypes.standard.finishersDefinition.MyFinisher.FormEngine.elements</code> which causes <code>ArrayUtility::getValueByPath()</code> to throw an exception. Due to this, no element configuration is found and the option is skipped.</p>
<p>As a workaround I have set the relevant options to empty values in my form definition.</p> TYPO3 Core - Bug #82786 (Closed): Invalid "recordOverview" in form YAML confighttp://forge.typo3.org/issues/827862017-10-17T16:25:12ZMathias Brodalambrodala@pagemachine.de
<p>The form YAML config uses <code>recordOverview</code> in various locations which must be <a href="https://docs.typo3.org/typo3cms/TCAReference/ColumnsConfig/Type/Group.html#recordsoverview" class="external"><code>recordsOverview</code></a> instead</p> TYPO3 Core - Bug #82352 (Closed): Form content element does not ensure "Forms" CType grouphttp://forge.typo3.org/issues/823522017-09-07T19:13:28ZMathias Brodalambrodala@pagemachine.de
<p>The form content element is currently placed in the "Forms" <code>CType</code> group but only if EXT:felogin is installed which actually adds this group. Otherwise it ends up in the "Special" group, essential anything which is last in <code>CType</code>.</p>
<p>This probably needs a larger change, e.g. an API to ensure form select field groups are present.</p>