TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692022-10-16T06:04:26ZTYPO3 Forge
Redmine TYPO3 Core - Bug #98625 (Closed): Fluid syntax error in login templatehttp://forge.typo3.org/issues/986252022-10-16T06:04:26ZSebastian Michaelsenmichaelsen@t3seo.de
<p>In the default Login.html template of the <code>felogin</code> extension there's a space at the end of the <code>additionalAttributes</code> attribute, so that it is detected as string, when it should be an array, resulting in:</p>
<pre>
InvalidArgumentException: The argument "additionalAttributes" was registered with type "array", but is of type "string" in view helper "TYPO3\CMS\Fluid\ViewHelpers\Form\PasswordViewHelper"., in file /var/www/html/vendor/typo3fluid/fluid/src/Core/ViewHelper/AbstractViewHelper.php:352
</pre>
<p>This is where it happened</p> TYPO3 Core - Bug #95368 (Closed): Passing an eID array URL parameter logs into the TYPO3 error loghttp://forge.typo3.org/issues/953682021-09-27T10:31:17ZSebastian Michaelsenmichaelsen@t3seo.de
<p>Calling <a class="external" href="https://www.example.com/index.php?eID[]=">https://www.example.com/index.php?eID[]=</a> produces an entry like this in the <code>sys_log</code>:</p>
<pre>
Core: Error handler (FE): PHP Warning: Illegal offset type in /path/to/project/typo3/sysext/frontend/Classes/Middleware/EidHandler.php line 70
</pre>
<p>This is the case for TYPO3 v10.4 and from looking at the code also at master.</p> TYPO3 Core - Feature #95172 (Rejected): Support different connections for read and write access t...http://forge.typo3.org/issues/951722021-09-10T07:57:29ZSebastian Michaelsenmichaelsen@t3seo.de
<p>If you have multiple redis containers with replications you will want to read from one redis instance and write to the other.<br />At the moment, the TYPO3 redis caching backend doesn't support configuring separate connectivity configuration for read and write.</p>
<p>Suggestion:</p>
<p>The possibility to configure <strong>one</strong> connection should be kept as it is for simplicity and backwards compatibility. Additionally the keys <code>read</code> and <code>write</code> can override individual options of the default connection.</p>
<pre><code class="yaml syntaxhl" data-language="yaml"><span class="na">SYS</span><span class="pi">:</span>
<span class="na">caching</span><span class="pi">:</span>
<span class="na">cacheConfigurations</span><span class="pi">:</span>
<span class="na">extbase</span><span class="pi">:</span>
<span class="na">backend</span><span class="pi">:</span> <span class="s1">'</span><span class="s">\TYPO3\CMS\Core\Cache\Backend\RedisBackend'</span>
<span class="na">options</span><span class="pi">:</span>
<span class="na">defaultLifetime</span><span class="pi">:</span> <span class="m">31536000</span>
<span class="na">hostname</span><span class="pi">:</span> <span class="s1">'</span><span class="s">%env(REDIS_REPLICA)%'</span>
<span class="na">port</span><span class="pi">:</span> <span class="m">6379</span>
<span class="na">database</span><span class="pi">:</span> <span class="m">0</span>
<span class="na">write</span><span class="pi">:</span>
<span class="na">hostname</span><span class="pi">:</span> <span class="s1">'</span><span class="s">%env(REDIS_MASTER)%'</span>
</code></pre> TYPO3 Core - Bug #95042 (Closed): email validation makes link generation unnecessary costlyhttp://forge.typo3.org/issues/950422021-08-31T06:11:44ZSebastian Michaelsenmichaelsen@t3seo.de
<p>Whenever links are generated with "legacy" parameter, the <code>\TYPO3\CMS\Core\LinkHandling\LegacyLinkNotationConverter</code> checks if the provided parameter is a valid email address. For validation we use the 3rd party library <code>egulias/email-validator</code>. With blackfire I determined that this library is quite costly in terms of memory and wall time.</p>
<p>I added this simple early return to <code>GeneralUtility::validEmail()</code>:</p>
<pre><code class="php syntaxhl" data-language="php"> <span class="k">if</span> <span class="p">(</span><span class="nb">strpos</span><span class="p">(</span><span class="nv">$email</span><span class="p">,</span> <span class="s1">'@'</span><span class="p">)</span> <span class="o">===</span> <span class="kc">false</span><span class="p">)</span> <span class="p">{</span>
<span class="k">return</span> <span class="kc">false</span><span class="p">;</span>
<span class="p">}</span>
</code></pre>
<p>And it significantly improved the speed of links generation. I don't know if that is a suitable solution for the core, or if such a fix should get into the library itself.</p> TYPO3 Core - Task #94553 (Closed): Enforce trailing commas in multi line arrays with PHP CS Fixerhttp://forge.typo3.org/issues/945532021-07-13T11:47:17ZSebastian Michaelsenmichaelsen@t3seo.de
<p>The PHP CS Fixer rule <code> trailing_comma_in_multiline => ['arrays']</code> ensures that multi line arrays always have a trailing comma.</p>
<pre><code class="php syntaxhl" data-language="php"><span class="nv">$array</span> <span class="o">=</span> <span class="p">[</span>
<span class="s1">'one'</span><span class="p">,</span>
<span class="s1">'two'</span>
<span class="p">];</span>
</code></pre>
<p>becomes</p>
<pre><code class="php syntaxhl" data-language="php"><span class="nv">$array</span> <span class="o">=</span> <span class="p">[</span>
<span class="s1">'one'</span><span class="p">,</span>
<span class="s1">'two'</span><span class="p">,</span>
<span class="p">];</span>
</code></pre>
<p>Having trailing commas makes it easier to rearrange entries and when an entry is added to the list the line before doesn't need to be changed. This results in smaller git changes for a better overview and less likely merge conflicts.</p> TYPO3 Core - Bug #93469 (Closed): Editing file metadata in a workspace takes immediate effect on ...http://forge.typo3.org/issues/934692021-02-09T08:09:54ZSebastian Michaelsenmichaelsen@t3seo.de
<p>Steps to reproduce:</p>
<ul>
<li>Switch into a Workspace</li>
<li>Open the File module and edit a file</li>
<li>Fill out or change the title and save</li>
<li>Switch into the LIVE environment again</li>
<li>Edit the same file again<br />=> There are your Workspace changes, immediately applied to the LIVE record.</li>
</ul>
<p>As an editor I must be sure that my workspace changes can not alter the current LIVE website. Otherwise I will lose trust into the whole workspace feature.</p> TYPO3 Core - Bug #93336 (Closed): Enabling translated content in workspace is not previewablehttp://forge.typo3.org/issues/933362021-01-21T09:35:08ZSebastian Michaelsenmichaelsen@t3seo.de
<p>When you enable content element translation in a WS (which is hidden in LIVE), you cannot see the effect in the workspace preview.</p>
<p>Setup:</p>
<table>
<tr>
<th>Workspace </th>
<th>Default Lang Content </th>
<th>Translated Content </th>
</tr>
<tr>
<td> LIVE </td>
<td> enabled </td>
<td> hidden </td>
</tr>
<tr>
<td> WS </td>
<td> enabled </td>
<td> enabled </td>
</tr>
</table>
<p><code>PageRepository->getRecordOverlay()</code> first does the language overlay and the version overlay afterwards. But the language overlay applies enable field restrictions, so the translation is not loaded (even it would be enabled in the WS version).</p> TYPO3 Core - Bug #93109 (Closed): Records can not be discarded from workspacehttp://forge.typo3.org/issues/931092020-12-18T14:59:21ZSebastian Michaelsenmichaelsen@t3seo.de
<p>When I try to discard news records in the workspaces module I get an SQL error: Unknown column 'tablenames' in 'where clause'.</p>
<p>I tracked down the issue to here: <a class="external" href="https://github.com/TYPO3/TYPO3.CMS/blob/956c01e07885d5c1dffffb2a7ab8aae0db4df9d6/typo3/sysext/core/Classes/DataHandling/DataHandler.php#L5656">https://github.com/TYPO3/TYPO3.CMS/blob/956c01e07885d5c1dffffb2a7ab8aae0db4df9d6/typo3/sysext/core/Classes/DataHandling/DataHandler.php#L5656</a></p>
<p>There it is hardcoded that the mm relation table always has a "tablenames" field. However this is not always the case, e.g. tx_news_domain_model_news.related (<a class="external" href="https://github.com/georgringer/news/blob/master/Configuration/TCA/tx_news_domain_model_news.php#L310">https://github.com/georgringer/news/blob/master/Configuration/TCA/tx_news_domain_model_news.php#L310</a>)</p> TYPO3 Core - Bug #93098 (Closed): Missing 'depends' section in ext_emconf.php leads to errorhttp://forge.typo3.org/issues/930982020-12-17T13:04:57ZSebastian Michaelsenmichaelsen@t3seo.de
<p>If an extension has no <code>'depends'</code> section in <code>ext_emconf.php</code>, but requires packages via <code>composer.json</code>, then during <code>install:generatepackagestates</code> an error is raised:</p>
<p>The package "myext" depends on "my/composer-package" which is not present in the system.</p>
<p>When putting <code>'constraints' => ['depends' => []],</code> into <code>ext_emconf.php</code> it works fine.</p>
<p>Especially for project specific local extensions you may not have any dependencies specified. When it works with the empty depends array, it should also be possible to leave it out entirely.</p> TYPO3 Core - Feature #92780 (Rejected): Provide Event after page URI has been generatedhttp://forge.typo3.org/issues/927802020-11-05T20:37:45ZSebastian Michaelsenmichaelsen@t3seo.de
<p>After <code>PageRouter->generateUri()</code> has created a link to a page, an event should be dispatched that allows extensions to react to the created URI or modify it.</p>
<p>Whenever an extension author <em>modifies</em> a generated URL they would need to take care that the URL can be resolved again in the end.</p>
<p>Use Case 1 (URL modification):<br />Via event the generated page URI is modified in a way that url path slugs are rearranged. Once this modified URI is called, a middleware recognizes it and modifies it back, so TYPO3 can resolve it again.</p>
<p>Use Case 2 (URL Logging):<br />Sometimes you have errors reported or in your logs, where you ask yourself: How did anyone end up on <strong>that</strong> URL? Where and why was it generated? So it could be useful to maintain a log with debugging information whenever a <em>new</em> URI is generated.</p> TYPO3 Core - Bug #85965 (Rejected): FileWriter fails to check for valid log file pathhttp://forge.typo3.org/issues/859652018-08-24T16:43:53ZSebastian Michaelsenmichaelsen@t3seo.de
<p><code>\TYPO3\CMS\Core\Log\Writer\FileWriter::setLogFile()</code> uses <code>GeneralUtility::getFileAbsFileName()</code> to get the absolute path to a given <code>$logFile</code>. <code>GeneralUtility::getFileAbsFileName()</code> always returns a string, even in an error case it returns an empty string. However the return value is checked for being <code>null</code>.</p>
<p><a class="external" href="https://github.com/TYPO3/TYPO3.CMS/commit/bfdc332650a92839e8ae73ec21b29f23609b5a1e#r30280568">https://github.com/TYPO3/TYPO3.CMS/commit/bfdc332650a92839e8ae73ec21b29f23609b5a1e#r30280568</a></p>
<p>That means that exception #1444374805 can never be thrown.</p>
<p>This applies to v7, v8 and master.</p> TYPO3 Core - Task #69381 (Rejected): Move the images field of the images CE to the first form tabhttp://forge.typo3.org/issues/693812015-08-28T08:50:19ZSebastian Michaelsenmichaelsen@t3seo.de
<p>Historically the images of the images content element were always configured in the second tab.<br />Back in the times before FAL this might have been a good idea, because there were many fields that would have cluttered the first view on the record.</p>
<p>Now with FAL and the image config details hidden the collapsed inline records it's time to move the images to the first tab. In fact they are the most important property of the record and should be directly visible.</p> TYPO3 Core - Feature #67450 (Rejected): Support custom markers in search formhttp://forge.typo3.org/issues/674502015-06-15T10:08:29ZSebastian Michaelsenmichaelsen@t3seo.de
<p>indexed_search should support the creation of custom markers via typoscript to output custom labels and arbitrary content</p> TYPO3 Core - Bug #67406 (Rejected): Form sysext detected as broken in install toolhttp://forge.typo3.org/issues/674062015-06-10T23:07:14ZSebastian Michaelsenmichaelsen@t3seo.de
<p>With the big change to the TYPO3 autoloading (<a class="external" href="https://github.com/TYPO3/TYPO3.CMS/commit/ec2b4f4266af7bc93e301ad4735464f958a6d1bf">https://github.com/TYPO3/TYPO3.CMS/commit/ec2b4f4266af7bc93e301ad4735464f958a6d1bf</a>) the form system extension is detected as broken by the install tool.</p>
<p><a class="external" href="http://shots.michaelsen.io/HYEa">http://shots.michaelsen.io/HYEa</a></p> TYPO3 Core - Feature #49805 (Rejected): Access extConf in displayCondhttp://forge.typo3.org/issues/498052013-07-09T10:14:18ZSebastian Michaelsenmichaelsen@t3seo.de
<p>The displayCond directive allows to disable/enable a tceform field or flexform field based on various conditions.</p>
<p>Until now it's not possible to use the extConf (settings from ext_conf_template.txt) as condition.</p>
<p>Introduce new displayCond: EXT:EXTCONF:[settingsname]:[operator]:[value]</p>
<p>Allow the same operators like FIELD, which are: <, >, <=, >=, REQ, <del>, !</del>, IN, !IN, =, !=</p>