TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692024-02-26T11:56:46ZTYPO3 Forge
Redmine TYPO3 Core - Bug #103202 (Resolved): TODO comments in FileInterface::setContents() cut offhttp://forge.typo3.org/issues/1032022024-02-26T11:56:46ZMathias Brodalambrodala@pagemachine.de
<p>Currently <code>FileInterface::setContents()</code> looks like this:</p>
<pre><code class="php syntaxhl" data-language="php"> <span class="cd">/**
* Replace the current file contents with the given string.
*
* @TODO : Consider to remove this function from the interface, as its
* @TODO : At the same time, it could be considered whether to make the whole
* @return $this
*/</span>
<span class="k">public</span> <span class="k">function</span> <span class="n">setContents</span><span class="p">(</span><span class="kt">string</span> <span class="nv">$contents</span><span class="p">):</span> <span class="kt">self</span><span class="p">;</span>
</code></pre>
<p>The TODO comments are cut off since the dreaded <code>[TASK] Move and Namespace (sic!) classes</code> commit. (<a class="issue tracker-4 status-5 priority-4 priority-default closed child" title="Task: Namespace switch core main patch (Closed)" href="http://forge.typo3.org/issues/40096">#40096</a>)</p>
<p>These should be restored for the time being.</p> TYPO3 Core - Bug #103177 (New): Inconsistent behavior in MathUtility::canBeInterpretedAsInteger()...http://forge.typo3.org/issues/1031772024-02-22T11:52:58ZMathias Brodalambrodala@pagemachine.de
<p>The behavior of <code>MathUtility::canBeInterpretedAsInteger()</code> is inconsistent:</p>
<pre>
var_dump(MathUtility::canBeInterpretedAsInteger(true)); // true
var_dump(MathUtility::canBeInterpretedAsInteger(false)); // false
</pre>
<p>Assuming that the common <code>true</code> = <code>1</code>, <code>false</code> = <code>0</code> logic applies, the behavior should be fixed to accept both boolean values. Both can be coerced into integers and thus interpreted a such:</p>
<pre>
var_dump(MathUtility::canBeInterpretedAsInteger(true)); // true
var_dump(MathUtility::canBeInterpretedAsInteger(false)); // true
</pre>
<p>Alternatively both boolean values should be rejected for consistency:</p>
<pre>
var_dump(MathUtility::canBeInterpretedAsInteger(true)); // false
var_dump(MathUtility::canBeInterpretedAsInteger(false)); // false
</pre> TYPO3 Core - Bug #103057 (Resolved): Text as page ID silently convertedhttp://forge.typo3.org/issues/1030572024-02-06T08:02:50ZMathias Brodalambrodala@pagemachine.de
<p>Given you do a request like <code>/index.php?id=foobar</code>, thus a text instead of a number as <code>id</code> then you will see the start page of your site.</p>
<p>Also number-like texts like <code>/index.php?id=2step</code> will try to use the number part of the <code>id</code>, in this case <code>/index.php?id=2</code>.</p>
<p>In all of these cases the frontend should throw a 404 instead.</p>
<p>Especially since there is no more support for page aliases since <a class="issue tracker-4 status-5 priority-4 priority-default closed child" title="Task: Remove pages.alias database field (Closed)" href="http://forge.typo3.org/issues/87356">#87356</a></p> 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 #102055 (Under Review): Form runtime next/previous page ignores variantshttp://forge.typo3.org/issues/1020552023-09-28T08:06:46ZMathias Brodalambrodala@pagemachine.de
<p>Given a form with conditional pages variants are not respected when the navigation is built. Example:</p>
<pre><code class="yaml syntaxhl" data-language="yaml"><span class="na">type</span><span class="pi">:</span> <span class="s">Form</span>
<span class="na">prototypeName</span><span class="pi">:</span> <span class="s">standard</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">multi-step-form</span>
<span class="na">label</span><span class="pi">:</span> <span class="s">Muli step form</span>
<span class="na">renderables</span><span class="pi">:</span>
<span class="pi">-</span>
<span class="na">type</span><span class="pi">:</span> <span class="s">Page</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">page-1</span>
<span class="na">label</span><span class="pi">:</span> <span class="s">First step</span>
<span class="na">renderables</span><span class="pi">:</span>
<span class="pi">-</span>
<span class="na">type</span><span class="pi">:</span> <span class="s">Checkbox</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">checkbox-1</span>
<span class="na">label</span><span class="pi">:</span> <span class="s">Check this and the 2nd step will be skipped</span>
<span class="pi">-</span>
<span class="na">type</span><span class="pi">:</span> <span class="s">Page</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">page-2</span>
<span class="na">label</span><span class="pi">:</span> <span class="s">Second step</span>
<span class="na">renderingOptions</span><span class="pi">:</span>
<span class="na">enabled</span><span class="pi">:</span> <span class="kc">false</span>
<span class="na">variants</span><span class="pi">:</span>
<span class="pi">-</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">variant-2</span>
<span class="na">condition</span><span class="pi">:</span> <span class="s1">'</span><span class="s">traverse(formValues,</span><span class="nv"> </span><span class="s">"checkbox-1")</span><span class="nv"> </span><span class="s">==</span><span class="nv"> </span><span class="s">0'</span>
<span class="na">renderingOptions</span><span class="pi">:</span>
<span class="na">enabled</span><span class="pi">:</span> <span class="kc">true</span>
<span class="pi">-</span>
<span class="na">type</span><span class="pi">:</span> <span class="s">Page</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">page-3</span>
<span class="na">label</span><span class="pi">:</span> <span class="s">Third step</span>
<span class="na">renderingOptions</span><span class="pi">:</span>
<span class="na">enabled</span><span class="pi">:</span> <span class="kc">false</span>
<span class="na">variants</span><span class="pi">:</span>
<span class="pi">-</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">variant-2</span>
<span class="na">condition</span><span class="pi">:</span> <span class="s1">'</span><span class="s">traverse(formValues,</span><span class="nv"> </span><span class="s">"checkbox-1")</span><span class="nv"> </span><span class="s">==</span><span class="nv"> </span><span class="s">1'</span>
<span class="na">renderingOptions</span><span class="pi">:</span>
<span class="na">enabled</span><span class="pi">:</span> <span class="kc">true</span>
</code></pre>
<p>Enabling the checkbox on the 1st page and going to the next page will show the 3rd page and a "Submit" button.</p>
<p>Not enabling the checkbox on the 1st page and going to the next page will show the 2nd page and a "Next Page" button. However, there is no next page here. In this case the button should also say "Submit".</p>
<p>The example above generally disables all subsequent pages and conditionally enables them which is a logical approach IMO. Especially because it allows you to have conditions which match their page 1:1. The reverse logic as <a href="https://docs.typo3.org/c/typo3/cms-form/main/en-us/I/Concepts/Variants/Index.html?highlight=steps#hide-steps" class="external">suggested by the docs</a> also doesn't work however:</p>
<pre><code class="yaml syntaxhl" data-language="yaml"><span class="na">type</span><span class="pi">:</span> <span class="s">Form</span>
<span class="na">prototypeName</span><span class="pi">:</span> <span class="s">standard</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">multi-step-form</span>
<span class="na">label</span><span class="pi">:</span> <span class="s">Muli step form</span>
<span class="na">renderables</span><span class="pi">:</span>
<span class="pi">-</span>
<span class="na">type</span><span class="pi">:</span> <span class="s">Page</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">page-1</span>
<span class="na">label</span><span class="pi">:</span> <span class="s">First step</span>
<span class="na">renderables</span><span class="pi">:</span>
<span class="pi">-</span>
<span class="na">type</span><span class="pi">:</span> <span class="s">Checkbox</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">checkbox-1</span>
<span class="na">label</span><span class="pi">:</span> <span class="s">Check this and the 2nd step will be skipped</span>
<span class="pi">-</span>
<span class="na">type</span><span class="pi">:</span> <span class="s">Page</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">page-2</span>
<span class="na">label</span><span class="pi">:</span> <span class="s">Second step</span>
<span class="na">variants</span><span class="pi">:</span>
<span class="pi">-</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">variant-2</span>
<span class="na">condition</span><span class="pi">:</span> <span class="s1">'</span><span class="s">traverse(formValues,</span><span class="nv"> </span><span class="s">"checkbox-1")</span><span class="nv"> </span><span class="s">==</span><span class="nv"> </span><span class="s">1'</span>
<span class="na">renderingOptions</span><span class="pi">:</span>
<span class="na">enabled</span><span class="pi">:</span> <span class="kc">false</span>
<span class="pi">-</span>
<span class="na">type</span><span class="pi">:</span> <span class="s">Page</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">page-3</span>
<span class="na">label</span><span class="pi">:</span> <span class="s">Third step</span>
<span class="na">variants</span><span class="pi">:</span>
<span class="pi">-</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">variant-2</span>
<span class="na">condition</span><span class="pi">:</span> <span class="s1">'</span><span class="s">traverse(formValues,</span><span class="nv"> </span><span class="s">"checkbox-1")</span><span class="nv"> </span><span class="s">==</span><span class="nv"> </span><span class="s">0'</span>
<span class="na">renderingOptions</span><span class="pi">:</span>
<span class="na">enabled</span><span class="pi">:</span> <span class="kc">false</span>
</code></pre> TYPO3 Core - Bug #95525 (New): Field label "DB mounts" is unclearhttp://forge.typo3.org/issues/955252021-10-07T15:05:44ZMathias Brodalambrodala@pagemachine.de
<p>The field <strong>DB mounts</strong> in users/groups is used to grant access to pages and page trees.</p>
<p>Thus the field should actually be named <strong>Page mounts</strong> / <strong>Web mounts</strong> or similar to actually tell what this is about. The term "DB" does not make sense for any user.</p> TYPO3 Core - Bug #95272 (New): Redirect after page slug change ignores TCA defaultshttp://forge.typo3.org/issues/952722021-09-20T07:22:11ZMathias Brodalambrodala@pagemachine.de
<p>With <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Auto-create Redirects on Slug Changes (Closed)" href="http://forge.typo3.org/issues/89115">#89115</a> automatic redirects after page slug changes have been added.</p>
<p>However, these redirects are created using lowlevel DB API calls instead of the <code>DataHandler</code> and thus to not take TCA defaults into account.</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 #92361 (New): Inconsistent port usage in redirectshttp://forge.typo3.org/issues/923612020-09-21T16:07:48ZMathias Brodalambrodala@pagemachine.de
<p>Currently it is not possible to set up valid redirects with ports. One can enter a "<host>:<port>" as <code>source_host</code> but this will be dropped again on next form display since the <code>SourceHost</code> evaluation marks the host as invalid.</p>
<p>However, a port must be set here since the <code>RedirectHandler</code> does respect this. If redirects are set up without port, there is no match and the redirects won't work.</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 #87667 (New): Replacements not applied for existing slughttp://forge.typo3.org/issues/876672019-02-06T14:41:41ZMathias Brodalambrodala@pagemachine.de
<p>Since <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Using slash in slug in extension record throws exception in frontend (Closed)" href="http://forge.typo3.org/issues/86740">#86740</a> one can define <code>replacments</code> for <code>slug</code> fields, e.g. to get rid of slashes.</p>
<p>However, these are not applied for existing or predefined slugs, e.g. when creating pages through the <code>DataHandler</code>.</p>
<p>All <code>replacements</code> must be applied upon sanitation, no matter the source of the slug.</p> TYPO3 Core - Bug #87328 (New): "Make new translation of this page" can create invalid page transl...http://forge.typo3.org/issues/873282019-01-04T14:05:41ZMathias Brodalambrodala@pagemachine.de
<p>Since <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: BE page module => 'Make new translation of this page' doesn't use command localize to create tran... (Closed)" href="http://forge.typo3.org/issues/81345">#81345</a> the <strong>Make new translation of this page</strong> feature within the page module directly creates localizations instead of opening the edit view for page translations.</p>
<p>This can lead to invalid page translations if e.g. the <code>title</code> has been configured to be empty in translations (unset <code>l10n_mode</code>) and thus must be filled by editors explicitly. In this case the edit view is shown correctly with errors after localization but one can simply close the view without additional prompt or action. After this the translation exists without title which in itself can lead to further issues. When trying to save instead a proper dialog is shown mentioning the invalid fields.</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 #59822 (New): Same action called on property mapping errors with view.pluginName...http://forge.typo3.org/issues/598222014-06-23T17:17:00ZMathias Brodalambrodala@pagemachine.de
<p>With <code>plugin.tx_<myext>.view.pluginNamespace</code> one can have all plugins of an extension share the same prefix for form data, e.g. for having multiple plugins affect the same object.</p>
<p>However, if property mapping errors occur in this setup, all plugins show the same output (of the last plugin).</p>
<p>This error occurs due to the internal argument <code>__referrer</code> having the same prefix for all plugins, thus the last one prevails and all actions are redirected to this referring request.</p> TYPO3 Core - Bug #56812 (New): TCA fields without positioning added to last tab, not "Extended" tabhttp://forge.typo3.org/issues/568122014-03-12T12:59:26ZMathias Brodalambrodala@pagemachine.de
<p>TCA fields added via <code>ExtensionManagementUtility::addToAllTCAtypes</code> are appended to the <code>showitem</code> list of all types if no explicit positioning (e.g. <code>after:title</code>) has been requested.</p>
<p>By default this appends the fields to the "Extended" tab which is present by default and ready to receive all fields which are simply appended.</p>
<p>However, if one adds a new tab via <code>--div--</code> without explicit positioning with some fields, all unrelated fields without explicit positioning are now appended to this tab instead. The resulting <code>showitem</code> portion which makes the issue clear:</p>
<blockquote>
<p>--div--;LLL:EXT:cms/locallang_ttc.xlf:tabs.extended, --div--;LLL:EXT:myext/locallang_db.xml:mytab, tx_myext_myfield;;;;1-1-1, unrelated_field</p>
</blockquote>
<p>The new tab with the field <code>tx_myext_myfield</code> was simply appended to the <code>showitem</code> list, thus preventing the "Extended" tab from being the last. The <code>unrelated_field</code> is now placed in the new tab.</p>
<p>A temporary fix is to set a explicit position for the newly added tab; this ensures that the tab and its fields are not simply appended and leaves the "Extended" tab on the last position.</p>
<p>The real fix however would involve explicitely placing all fields without explicit positioning in the "Extended" tab. This way arbitrary tabs could be appended without unrelated fields showing up in them.</p>
<p>This issue affects all TYPO3 CMS versions.</p>