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 #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 #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 #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 #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 #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 #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 #93679 (Closed): Cropping to 0 (zero) pixels height/width breaks page/content ed...http://forge.typo3.org/issues/936792021-03-08T14:49:53ZMathias Brodalambrodala@pagemachine.de
<p>It is possible to store an image cropping configuration of 0 (zero) pixels in width or height. For this an editor simply needs to reduce the cropping frame to 0 in width or height. After saving an error shows up:</p>
<blockquote>
<p>Width and height of the image must be greater than zero</p>
</blockquote>
<p>(See <a class="external" href="https://github.com/TYPO3/TYPO3.CMS/blob/10.4/typo3/sysext/core/Classes/Imaging/ImageDimension.php#L76">https://github.com/TYPO3/TYPO3.CMS/blob/10.4/typo3/sysext/core/Classes/Imaging/ImageDimension.php#L76</a>)</p>
<p>Unless the <code>crop</code> field of the affected <code>sys_file_reference</code> record is cleared/fixed manually in the database, viewing the page in the <em>Page</em> module or editing the affected record in the <em>List</em> module is impossible due to this error.</p>
<p>A few options to fix this:</p>
<ol>
<li>Require a minimum of 1x1 Pixel for cropping</li>
<li>Display error and disable <em>Accept</em> in the <em>Image manipulation</em> wizard</li>
<li>Handle a width/height of 0 Pixel more gratuitously in <code>ImageDimension</code>.</li>
</ol> TYPO3 Core - Bug #92969 (Closed): Sudo mode password prompt triggers "Password change" in passwor...http://forge.typo3.org/issues/929692020-12-01T14:23:23ZMathias Brodalambrodala@pagemachine.de
<p>Not sure about other password managers but the name/ID <code>confirmationPassword</code> used for the password field introduced in <a class="issue tracker-4 status-8 priority-4 priority-default" title="Task: Introduce Sudo Mode for Install Tool (Under Review)" href="http://forge.typo3.org/issues/92836">#92836</a> triggers a "Password change" workflow in the Enpass password manager.</p>
<p>To avoid usability issues like these the field should be renamed and <code>autocomplete</code> should be considered.</p> TYPO3 Core - Bug #92881 (Closed): FluidEmail not rendered for getHtmlBody()http://forge.typo3.org/issues/928812020-11-19T15:55:14ZMathias Brodalambrodala@pagemachine.de
<p>Currently the <code>FluidEmail</code> added with <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Fluid-based templated emails (Closed)" href="http://forge.typo3.org/issues/90266">#90266</a> triggers rendering of its text and HTML body only on <code>getBody()</code> call. When calling <code>getHtmlBody()</code> instead, no rendering is triggered. Calling <code>getHtmlBody()</code> after calling <code>getBody()</code> will return the rendered HTML body of course.</p>
<p>This needs to be fixed so that each body getter renders its own part.</p> TYPO3 Core - Bug #92781 (Closed): Placeholders not working in multiple recipient keys/addresseshttp://forge.typo3.org/issues/927812020-11-06T10:23:43ZMathias Brodalambrodala@pagemachine.de
<p>With <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Allow multiple recipients in EmailFinisher (Closed)" href="http://forge.typo3.org/issues/80420">#80420</a> multiple recipients are possible in forms. However, placeholders like <code>{email}</code> are not supported anymore like they used to be for the old single options.</p>
<p>Before:</p>
<pre><code class="yaml syntaxhl" data-language="yaml"><span class="na">finishers</span><span class="pi">:</span>
<span class="pi">-</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">EmailToReceiver</span>
<span class="na">options</span><span class="pi">:</span>
<span class="na">recipientAddress</span><span class="pi">:</span> <span class="s1">'</span><span class="s">{email}'</span>
<span class="na">recipientName</span><span class="pi">:</span> <span class="s1">'</span><span class="s">To</span><span class="nv"> </span><span class="s">Example'</span>
</code></pre>
<p>After, not working:</p>
<pre><code class="yaml syntaxhl" data-language="yaml"><span class="na">finishers</span><span class="pi">:</span>
<span class="pi">-</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">EmailToReceiver</span>
<span class="na">options</span><span class="pi">:</span>
<span class="na">recipients</span><span class="pi">:</span>
<span class="s1">'</span><span class="s">{email}'</span><span class="err">:</span> <span class="s1">'</span><span class="s">To</span><span class="nv"> </span><span class="s">Example'</span>
</code></pre> 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>