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 - Feature #103072 (New): Manage translation DB fieldshttp://forge.typo3.org/issues/1030722024-02-07T10:59:45ZMathias Brodalambrodala@pagemachine.de
<p>Currently the TCA of TYPO3 knows these <code>ctrl</code> options to enable and manage translation behavior for tables:</p>
<p>- <code>languageField</code> (<code>sys_language_uid</code> by convention)<br />- <code>transOrigPointerField</code> (<code>l10n_parent</code> by convention, <code>l18n_parent</code> in <code>tt_content</code>)<br />- <code>translationSource</code>(<code>l10n_source</code> by convention)<br />- <code>transOrigDiffSourceField</code> (<code>l10n_diffsource</code> by convention, <code>l18n_diffsource</code> in <code>tt_content</code>)</p>
<p>Each of these have 2 purposes:</p>
<p>1. Enable translations or a related feature<br />2. Tell TYPO3 which DB field to use in queries</p>
<p>This by itself is a problem but the main question is whether the names of these DB fields need to be configurable at all.</p>
<p>There are recently a lot of consolidations and simplifications in TCA. The same could be applied here:</p>
<p>- Turn these options from <code>string</code> to <code>bool</code>, thus only enable/disable the feature. TYPO3 would then use fixed DB field names and thus fully manage these.<br />- Consolidate/merge these options with better and clearer names, e.g. <code>'enableTranslations' => true</code>, <code>'trackTranslationDifferences' => true</code> or similar.</p> 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 - Feature #102077 (Closed): Custom default value for getFormValue() function in varian...http://forge.typo3.org/issues/1020772023-10-02T09:20:30ZMathias Brodalambrodala@pagemachine.de
<p>The "form" extension provides a <code>getFormValue()</code> function to be used in variant conditions. It allows accessing form values without triggering an "undefined array index" error in PHP.</p>
<p>However, it unconditionally returns <code>null</code> in case a form value is undefined. This should be extended to optionally provide a custom default/fallback value. This would shorten conditions considerably, e.g. when checking for values of a <code>MultiCheckbox</code> field:</p>
<table>
<tr>
<th>Before</th>
<th>After</th>
</tr>
<tr>
<td> getFormValue("multiCheckboxField") && "foo" in getFormValue("multiCheckboxField") </td>
<td> "foo" in getformValue("multiCheckboxField", []) </td>
</tr>
</table> 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 - Task #97873 (Closed): Named handlers in HTTP stackhttp://forge.typo3.org/issues/978732022-07-08T08:57:25ZMathias Brodalambrodala@pagemachine.de
<p>Since <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: RequestFactory respects Guzzle Middleware/Handler configuration from TYPO3_CONF_VARS (Closed)" href="http://forge.typo3.org/issues/88871">#88871</a> one can add custom middlewares/handlers to the handler stack used by Guzzle within TYPO3 via <code>$GLOBALS['TYPO3_CONF_VARS']['HTTP']['handler']</code>.</p>
<p>These are pushed onto the handler stack without name. Chances are high that a name is available in the <code>$GLOBALS['TYPO3_CONF_VARS']['HTTP']['handler']</code> array so this should be pushed together with the middleware/handler.</p>
<p>Benefit: easier debugging.</p> 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 - Feature #96055 (Closed): Let the command "language:update" issue warningshttp://forge.typo3.org/issues/960552021-11-23T09:57:29ZMathias Brodalambrodala@pagemachine.de
<p>Currently the CLI command <code>language:update</code> fails hard if translations could not be fetched. (No matter if for a private extension or a public extension without translations, see <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: CLI command language:update fails due to packages without translation packs (Closed)" href="http://forge.typo3.org/issues/95700">#95700</a>)</p>
<p>It would be useful if these where warnings instead by default since failed translations are updates are usually not that important and low priority.</p>
<p>An optional CLI option could be added to turn these warnings into errors again which would be useful for CI systems.</p> TYPO3 Core - Feature #89417 (New): Snippets/components in form definitionshttp://forge.typo3.org/issues/894172019-10-15T09:58:57ZMathias Brodalambrodala@pagemachine.de
<p>It would be useful if the Form framework did support snippets/components. These could then be referenced in a regular form definition and would be inserted on the fly as soon as the form is built.</p>
<p>Obviously some kind of parameter support would be necessary here to make it easy to e.g. set the name for a form field provided by a snippet.</p>
<p>Maybe this could be achieved with <a class="issue tracker-2 status-5 priority-4 priority-default closed child parent" title="Feature: Support "imports" within forms form definition files (Closed)" href="http://forge.typo3.org/issues/84204">#84204</a> and YAML anchors/references.</p> TYPO3 Core - Feature #71038 (Rejected): Install extensions with dependencies on CLIhttp://forge.typo3.org/issues/710382015-10-26T14:31:03ZMathias Brodalambrodala@pagemachine.de
<p>The <code>ExtensionCommandController</code> provides the <code>extension:install</code> command which can be used to install extensions via CLI while ignoring all dependencies.</p>
<p>A switch like <code>--with-dependencies</code> could be added which triggers installation of all extensions required by the extension to install. Of course these must exist when invoking this command. (Which is already given if the extension was fetched via Composer.)</p> TYPO3 Core - Feature #55757 (Closed): Add PageTSconfig analyzerhttp://forge.typo3.org/issues/557572014-02-07T12:26:47ZMathias Brodalambrodala@pagemachine.de
<p>Similar to what the Template Analyzer does for the TypoScript Object Browser an additional mod function for analyzing PageTS would be useful.</p>
<p>ATM one can only see the currently parsed PageTS for pages. It is impossible to find out where and how this configuration was set which makes debugging for larger sites harder than it should be.</p>
<p>A PageTSconfig analyzer could help here by showing the content of added PageTS files and dynamically added sections like <code>defaultPageTSconfig</code>.</p> TYPO3 Core - Task #53455 (Closed): Update backend page titlehttp://forge.typo3.org/issues/534552013-11-08T15:22:28ZMathias Brodalambrodala@pagemachine.de
<p>Since the introduction text of the install tool has been updated recently for 6.2 I think it is about time the page title of the backend is also updated to reflect the brand change. Thus "TYPO3 <version>" becomes "TYPO3 CMS <version>".</p>