TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692024-03-28T09:22:02ZTYPO3 Forge
Redmine TYPO3 Core - Task #103496 (Under Review): Use ISO date format by defaulthttp://forge.typo3.org/issues/1034962024-03-28T09:22:02ZMathias Brodalambrodala@pagemachine.de
<p>The configuration option <code>SYS/ddmmyy</code> is set to <code>d-m-y</code> which has issues:</p>
<p>1. Date display can be ambiguous if a 2-digit year could also be a day in a month, e.g. <em>21-04-23</em> could be <em>2021-04-23</em> or <em>2023-04-21</em><br />2. Date display can be unclear for dates in a different century, e.g. <em>21-04-71</em> could be <em>2071-04-21</em> or <em>1971-04-21</em><br />3. The current format is kind-of-German where <code>d.m.y</code> or <code>d.m.Y</code> would be used. Given that TYPO3 targets an internal audience, a bias like this should be removed.</p>
<p>For these reasons the usual ISO date format <code>Y-m-d</code> should be used by default to solve these issues.</p>
<p>Also see <a class="external" href="https://en.wikipedia.org/wiki/List_of_date_formats_by_country">https://en.wikipedia.org/wiki/List_of_date_formats_by_country</a> where basically all countries prefer a 4-digit year to avoid the above mentioned ambiguities.</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 #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 #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 - Task #93246 (Closed): Check maximum PHP version in entrypointshttp://forge.typo3.org/issues/932462021-01-08T15:01:17ZMathias Brodalambrodala@pagemachine.de
<p>The entrypoints for FE, BE and CLI should not only check for a minimum PHP version but also a maximum PHP version. This reflects the <code>composer.json</code> which contains e.g. <code>"php": "^7.4"</code> and thus disallows installation with PHP 8.x.</p>
<p>However, this can accidentally be bypassed if a local development environment uses PHP 7.4 and a remote server uses PHP 8.0.</p>
<p>For this reason an additional check should be added to all entrypoints as safeguard.</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> TYPO3 Core - Feature #89760 (Under Review): Show storage list for selectionhttp://forge.typo3.org/issues/897602019-11-24T12:11:17ZMathias Brodalambrodala@pagemachine.de
<p>There should be a storage list to the left of the form list within the "Forms" module. Here editors should be able to select one of the folders configured in <code>allowedFileMounts</code> and <code>allowedExtensionPaths</code>. In fact, it should be mandatory to select a folder first.</p>
<p>Benefits:</p>
<ol>
<li>It is clear in which folder an editor manages forms</li>
<li>No confusion due to duplicate forms in different folders</li>
<li>Option to introduce pagination which is next to impossible across multiple folders</li>
</ol> TYPO3 Core - Task #89747 (Closed): Allow custom tables in record browserhttp://forge.typo3.org/issues/897472019-11-22T17:35:33ZMathias Brodalambrodala@pagemachine.deTYPO3 Core - Task #89746 (Closed): Make icon for record browser configurablehttp://forge.typo3.org/issues/897462019-11-22T17:34:51ZMathias Brodalambrodala@pagemachine.deTYPO3 Core - Task #89742 (Closed): Deprecate form mixinshttp://forge.typo3.org/issues/897422019-11-22T15:29:30ZMathias Brodalambrodala@pagemachine.de
<p>With <a class="issue tracker-2 status-5 priority-4 priority-default closed child" title="Feature: Restructure ext:form setup files (Closed)" href="http://forge.typo3.org/issues/84221">#84221</a> the form setup has been restructured and inheritances have been resolved. Thus EXT:form does not use its own mixins anymore so they should be deprecated in TYPO3v10 and removed in TYPO3v11.</p> TYPO3 Core - Bug #89720 (Closed): TypoScript import from directory loads all fileshttp://forge.typo3.org/issues/897202019-11-21T10:31:48ZMathias Brodalambrodala@pagemachine.de
<p>The "documentation of the TypoScript <code>@import</code> feature"https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ApiOverview/TypoScriptSyntax/Syntax/Includes.html#includes claims that importing from a directory will automatically only load <code>.typoscript</code> files in that directory:</p>
<pre>
# The filename extension can be omitted and defaults to .typoscript
@import 'EXT:myproject/Configuration/TypoScript/'
</pre>
<p>However, this is not true. If a directory is imported like this, <strong>all</strong> files in that directory are imported as TypoScript and then parsed as such, leading to various errors in the Object Browser / Template Analyzer.</p>
<p>Here <code>fileadmin/form_definitions</code> is imported and a form definition exists in this directory:</p>
<p><img src="http://forge.typo3.org/attachments/download/34716/2019-11-21_10-29.png" alt="" loading="lazy" /></p>
<p>The Template Analyzer then clearly reveals that the form definition has been imported, too:</p>
<p><img src="http://forge.typo3.org/attachments/download/34717/2019-11-21_10-30.png" alt="" loading="lazy" /></p> TYPO3 Core - Task #89481 (Closed): Add security reporting procedure to READMEhttp://forge.typo3.org/issues/894812019-10-23T09:08:10ZMathias Brodalambrodala@pagemachine.de
<p>The current README does not have a single mention how security issues should be reported. This can lead to public reports which violates the <a href="https://en.wikipedia.org/wiki/Responsible_disclosure" class="external">responsible disclosure</a> principle.</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> TYPO3 Core - Task #56177 (Closed): Windows issues with long CSV file name from commit 2db3d30http://forge.typo3.org/issues/561772014-02-21T11:49:53ZMathias Brodalambrodala@pagemachine.de
<p>The commit 2db3d30 added the following file:</p>
<blockquote>
<p>typo3/sysext/workspaces/Tests/Functional/DataHandling/InlineRelationalRecordEditing/CommaSeparatedValue/DataSet/Assertion/createAndLocalizeParentContentRecordWithHotelAndOfferChildRecordsAndDiscardLocalizedParentRecord.csv</p>
</blockquote>
<p>It seems like this file path is too long for either Windows or Git on Windows. If you pull/merge this commit, the file cannot be created, if you do a clean clone, this file is deleted immediately and cannot be restored.</p>
<p>Suggestion: use a shorter file name.</p>