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 #102083 (Resolved): Validation triggered for fields in fieldsets disabled by var...http://forge.typo3.org/issues/1020832023-10-04T10:03:41ZMathias Brodalambrodala@pagemachine.de
<p>Given fields are placed in a fieldset and that fieldset is disabled using variants. Also given that these fields have validators.</p>
<p>Now if one tries to submit the form, it is displayed again without explanation. Inspection of the validation results shows that the validators of the fields have been triggered and couldn't validate the input of the fields. These fields could not be filled by the user since they are disabled together with their fieldset.</p>
<p>Validators of fields within disabled fieldsets should be ignored.</p> 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 #97522 (Closed): Word "new" in command "description" breaks DIhttp://forge.typo3.org/issues/975222022-04-29T16:44:01ZMathias Brodalambrodala@pagemachine.de
<p>Given a command definition like this ...</p>
<pre><code class="yaml syntaxhl" data-language="yaml"><span class="na">services</span><span class="pi">:</span>
<span class="na">_defaults</span><span class="pi">:</span>
<span class="na">autowire</span><span class="pi">:</span> <span class="kc">true</span>
<span class="na">autoconfigure</span><span class="pi">:</span> <span class="kc">true</span>
<span class="na">public</span><span class="pi">:</span> <span class="kc">false</span>
<span class="na">Acme\Foo\</span><span class="pi">:</span>
<span class="na">resource</span><span class="pi">:</span> <span class="s1">'</span><span class="s">../Classes/*'</span>
<span class="na">Acme\Foo\Command\BarCommand</span><span class="pi">:</span>
<span class="na">tags</span><span class="pi">:</span>
<span class="pi">-</span> <span class="na">name</span><span class="pi">:</span> <span class="s">console.command</span>
<span class="na">command</span><span class="pi">:</span> <span class="s">example:bar</span>
<span class="na">description</span><span class="pi">:</span> <span class="s">Build a new bar</span>
<span class="na">schedulable</span><span class="pi">:</span> <span class="kc">false</span>
<span class="na">Acme\Foo\Command\QuxCommand</span><span class="pi">:</span>
<span class="na">tags</span><span class="pi">:</span>
<span class="pi">-</span> <span class="na">name</span><span class="pi">:</span> <span class="s">console.command</span>
<span class="na">command</span><span class="pi">:</span> <span class="s">example:qux</span>
<span class="na">description</span><span class="pi">:</span> <span class="s">Do something</span>
<span class="na">schedulable</span><span class="pi">:</span> <span class="kc">false</span>
</code></pre>
<p>... you get an error like this:</p>
<pre>
[ ParseError ]
syntax error, unexpected '::' (T_PAAMAYIM_NEKUDOTAYIM), expecting '('
Exception trace:
#0 ()
var/cache/code/di/DependencyInjectionContainer_<hash>.php:<line>
...
</pre>
<p>The generated service in the DI cache file:</p>
<pre><code class="php syntaxhl" data-language="php"> <span class="cd">/**
* Gets the public 'Acme\Foo\Command\BarCommand' shared autowired service.
*
* @return \Acme\Foo\Command\BarCommand
*/</span>
<span class="k">protected</span> <span class="k">function</span> <span class="n">getBarCommandService</span><span class="p">()</span>
<span class="p">{</span>
<span class="nv">$this</span><span class="o">-></span><span class="n">services</span><span class="p">[</span><span class="s1">'Acme\\Foo\\Command\\BarCommand'</span><span class="p">]</span> <span class="o">=</span> <span class="nv">$instance</span> <span class="o">=</span> <span class="nc">\TYPO3\CMS\Core\Utility\GeneralUtility</span><span class="o">::</span><span class="nf">makeInstanceForDi</span><span class="p">(</span><span class="nc">\Acme\Foo\Command\BarCommand</span><span class="o">::</span><span class="n">class</span><span class="p">,</span> <span class="nc">\TYPO3\CMS\Core\Utility\GeneralUtility</span><span class="o">::</span><span class="nf">makeInstanceForDi</span><span class="p">(</span><span class="nc">\Acme\Foo\Security\BarDependency</span><span class="o">::</span><span class="n">class</span><span class="p">));</span>
<span class="nv">$instance</span><span class="o">-></span><span class="nf">setName</span><span class="p">(</span><span class="s1">'example:bar'</span><span class="p">);</span>
<span class="nv">$instance</span><span class="o">-></span><span class="nf">setDescription</span><span class="p">(</span><span class="s1">'Build a \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstanceForDi(bar'</span><span class="p">);</span>
<span class="k">return</span> <span class="nv">$instance</span><span class="p">;</span>
<span class="p">}</span>
<span class="cd">/**
* Gets the public 'Acme\Foo\Command\QuxCommand' shared autowired service.
*
* @return \Acme\Foo\Command\QuxCommand
*/</span>
<span class="k">protected</span> <span class="k">function</span> <span class="n">getQuxCommandService</span><span class="p">::</span><span class="kt">class</span><span class="p">)</span>
<span class="p">{</span>
<span class="c1"># ...</span>
<span class="p">}</span>
</code></pre>
<p>This is very likely caused by the rather simple replacement here:</p>
<p><a class="external" href="https://github.com/TYPO3/typo3/blob/6f7514f51634fd98a4d4def818c3f16e28aff538/typo3/sysext/core/Classes/DependencyInjection/ContainerBuilder.php#L166">https://github.com/TYPO3/typo3/blob/6f7514f51634fd98a4d4def818c3f16e28aff538/typo3/sysext/core/Classes/DependencyInjection/ContainerBuilder.php#L166</a></p>
<pre><code class="php syntaxhl" data-language="php"><span class="nv">$code</span> <span class="o">=</span> <span class="nb">preg_replace</span><span class="p">(</span><span class="s1">'/new ([^\(\s]+)\(/'</span><span class="p">,</span> <span class="s1">'\\TYPO3\\CMS\\Core\\Utility\\GeneralUtility::makeInstanceForDi(\\1::class, '</span><span class="p">,</span> <span class="nv">$code</span><span class="p">);</span>
</code></pre> TYPO3 Core - Bug #96929 (Closed): TCA / TCA overrides with variable leakshttp://forge.typo3.org/issues/969292022-02-16T15:38:05ZMathias Brodalambrodala@pagemachine.de
<p>All TCA and TCA overrides files are included without any scoping. This means that variables defined in these files can leak into the following files.</p>
<p>Also all variables defined in <code>ExtensionManagementUtility::buildBaseTcaFromSingleFiles()</code> exist in TCA and TCA override files and could even be manipulated.</p>
<p>See <a class="external" href="https://github.com/TYPO3/typo3/blob/35f7bbb381514efd483b9bfe1570229fc454dd8f/typo3/sysext/core/Classes/Utility/ExtensionManagementUtility.php#L1477">https://github.com/TYPO3/typo3/blob/35f7bbb381514efd483b9bfe1570229fc454dd8f/typo3/sysext/core/Classes/Utility/ExtensionManagementUtility.php#L1477</a></p>
<p>Possible solution: wrap the <code>require</code> calls for TCA / TCA override files with a closure.</p> TYPO3 Core - Bug #96054 (Closed): Command "language:update" does not log error on missing transla...http://forge.typo3.org/issues/960542021-11-23T09:53:47ZMathias Brodalambrodala@pagemachine.de
<p>The CLI command <code>language:update</code> invokes <code>LanguagePackService::languagePackDownload()</code> for each active extension. Here a HTTP request is performed on the translation server which can fail with an exception on 404.</p>
<p>The <code>RequestFactory::request()</code> call here should be adjusted to include <a href="https://docs.guzzlephp.org/en/stable/request-options.html#http-errors" class="external"><code>['http_errors' => false]</code></a> to have Guzzle return the 404 response instead of throwing an exception. This would allow for logging this as a regular warning.</p> TYPO3 Core - Bug #96053 (Closed): Command "language:update" succeeds on missing translations but ...http://forge.typo3.org/issues/960532021-11-23T09:50:25ZMathias Brodalambrodala@pagemachine.de
<p>The CLI command <code>language:update</code> is supposed to always fail if translations could not be fetched for an extension. But the behavior is different if <code>--no-progress</code> (or <code>--verbose</code>) is passed.</p>
<p>To reproduce:</p>
<ol>
<li>Install any extension without translations on the TYPO3 translation server (private or public), e.g. <code>container</code></li>
<li>Run <code>language:update</code>: succeeds</li>
<li>Run <code>language:update --no-progress</code>: fails</li>
<li>Run <code>language:update --verbose</code>: fails</li>
</ol>
<p>(Notice that the order of <code>language:update</code> invocations doesn't matter here.)</p> 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 #94922 (Closed): Missing HTTP status 308 for redirectshttp://forge.typo3.org/issues/949222021-08-18T10:48:59ZMathias Brodalambrodala@pagemachine.de
<p>TYPO3 redirects do not offer the HTTP status code <code>308 Permanent Redirect</code> as counterpart to the <code>307 Temporary Redirect</code> by default. This is essential to provide a modern equivalent to the legacy <code>302 Found</code> status code.</p>
<p>Thus <code>308 Permanent Redirect</code> should be added as status code for redirects.</p> TYPO3 Core - Bug #94816 (Closed): Missing "View" button on pages with doktype > 200http://forge.typo3.org/issues/948162021-08-11T13:17:38ZMathias Brodalambrodala@pagemachine.de
<p>When editing a content element on a page with <code>doktype</code> > 200 the view button will not render this page in the frontend.</p> TYPO3 Core - Bug #94815 (Closed): Cannot link to pages with doktype > 200http://forge.typo3.org/issues/948152021-08-11T13:16:54ZMathias Brodalambrodala@pagemachine.de
<p>Pages with <code>doktype</code> > 200 will be muted in the page tree, just as Sysfolders. Thus you cannot set links to pages with <code>doktype</code> > 200 or content elements on these pages.</p> TYPO3 Core - Bug #84580 (Closed): "Stop page tree" icon/label unclearhttp://forge.typo3.org/issues/845802018-04-03T12:24:52ZMathias Brodalambrodala@pagemachine.de
<p>The option <strong>Stop page tree</strong> which can be enabled for any page has an unclear icon/label.</p>
<p>The icon is a very simple red "+" and the label only reads <strong>Stop page tree</strong>. There is no clear indication that this option prevents the page tree to render the subtree of the page where this option was enabled.</p>
<p>A better icon/label/indication could be added here.</p>