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 - 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 - Task #96267 (New): Add dedicated error for class construction without dependencieshttp://forge.typo3.org/issues/962672021-12-07T09:29:03ZMathias Brodalambrodala@pagemachine.de
<p>Right now if <code>GeneralUtility::makeInstance()</code> is used to construct a class which uses constructor dependency injection and has not being marked as <code>public</code>, a low-level <code>\ArgumentCountError</code> is thrown by PHP.</p>
<p>This should be improved by catching this case and replacing the error with a custom one (e.g. <code>MissingDependenciesError</code>). Either that custom error already hints at possible solutions or its dedicated error code is used to link to the docs with more details. The docs could then suggest to mark the class as <code>public</code> or manually pass the dependencies as arguments.</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 - Task #91381 (Closed): Clearly document "final" nature of Redirect finisherhttp://forge.typo3.org/issues/913812020-05-13T13:19:29ZMathias Brodalambrodala@pagemachine.de
<p>It happens quite often that users create form definitions like this:</p>
<pre><code class="yaml syntaxhl" data-language="yaml"><span class="c1"># ...</span>
<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">Redirect</span>
<span class="c1"># ...</span>
<span class="pi">-</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">EmailToReceiver</span>
<span class="c1"># ...</span>
</code></pre>
<p>Here the <code>EmailToReceiver</code> will never be executed since the <code>Redirect</code> finisher terminates the current (HTTP) request immediately.</p>
<p>We should take some countermeasures to avoid this situation or at least give hints that a form definition like this will not give the expected results:</p>
<ul>
<li>Update the docs to warn about this in the section about finishers in general and for the <code>Redirect</code> finisher in particular</li>
</ul>
<p>Other countermeasures are included in <a class="issue tracker-2 status-1 priority-4 priority-default" title="Feature: Implement feedback about "final" nature of Redirect finisher (New)" href="http://forge.typo3.org/issues/94809">#94809</a>.</p> TYPO3 Core - Task #89866 (Closed): Use new Typo3Copyright API everywherehttp://forge.typo3.org/issues/898662019-12-05T17:08:33ZMathias Brodalambrodala@pagemachine.de
<p>After <a class="issue tracker-4 status-5 priority-4 priority-default closed" title="Task: Move Copyright information generation out of TYPO3 Backend (Closed)" href="http://forge.typo3.org/issues/89756">#89756</a> there are still some locations which directly use e.g. the <code>TYPO3_copyright_year</code> constant and should be migrated to the <code>Typo3Copyright</code> class.</p> TYPO3 Core - Task #89761 (New): Optimize form listinghttp://forge.typo3.org/issues/897612019-11-24T12:15:43ZMathias Brodalambrodala@pagemachine.de
<p>Currently forms are retrieved as follows in exactly this order:</p>
<ol>
<li>Traverse all configured storage folders</li>
<li>Collect all <code>*.yaml</code> files in a folder</li>
<li>Read the full content of each <code>*.yaml</code> file</li>
<li>Determine if the content looks like a form definition</li>
<li>Skip anything which does not end with <code>.form.yaml</code></li>
</ol>
<p>There is clearly room to improve on each step and especially the order could be changed to have simple filters (like for <code>.form.yaml</code>) executed early using custom FAL filters.</p> TYPO3 Core - Epic #89759 (New): Performance improvements in Forms modulehttp://forge.typo3.org/issues/897592019-11-24T12:08:23ZMathias Brodalambrodala@pagemachine.deTYPO3 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 - Epic #89731 (New): Configuration streamlininghttp://forge.typo3.org/issues/897312019-11-21T18:55:56ZMathias Brodalambrodala@pagemachine.deTYPO3 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 - Task #88220 (Accepted): Documentation for "Allow multiple recipients in EmailFinisher"http://forge.typo3.org/issues/882202019-04-26T12:35:22ZMathias Brodalambrodala@pagemachine.de
<p>The EXT:form documentation (setup/YAML) must be updated for <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>.</p> TYPO3 Core - Task #87157 (Closed): TYPO3v8 should declare compatibility with PHP 7.3http://forge.typo3.org/issues/871572018-12-14T09:27:37ZMathias Brodalambrodala@pagemachine.de
<p>PHP 7.3 was released recently and all tests in TYPO3v8 are running just fine with this version, thus we should declare compatibility with PHP 7.3 in TYPO3v8.</p>