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 - 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 - 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 - 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 - 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 - 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 - 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 - 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>