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 - 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 - 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 #87035 (Closed): AdditionalFactoryConfiguration.php not used anymorehttp://forge.typo3.org/issues/870352018-11-29T10:32:53ZMathias Brodalambrodala@pagemachine.de
<p>The <code>typo3conf/AdditionalFactoryConfiguration.php</code> file can be used to provide additional default values to be put into <code>typo3conf/LocalConfiguration.php</code> upon TYPO3 setup.</p>
<p>However, this file is not used anymore since TYPO3v9 and currently must be placed one level above instead, so basically next to <code>index.php</code>.</p>
<p>This is a regression introduced with <a class="issue tracker-4 status-5 priority-4 priority-default closed" title="Task: Replace further path usages with Environment API (Closed)" href="http://forge.typo3.org/issues/85560">#85560</a>.</p> TYPO3 Core - Bug #85415 (Closed): Missing space in inline record control buttonshttp://forge.typo3.org/issues/854152018-06-28T11:46:56ZMathias Brodalambrodala@pagemachine.de
<p>There is no space between the icon and text of inline record control buttons like <strong>Create new</strong> and <strong>Localize all records</strong>:</p>
<p><img src="http://forge.typo3.org/attachments/download/33560/inline-controls.png" alt="" loading="lazy" /></p> TYPO3 Core - Task #85034 (Closed): Log message when typolink failshttp://forge.typo3.org/issues/850342018-05-17T15:39:14ZMathias Brodalambrodala@pagemachine.de
<p><code>ContentObjectRenderer::typoLink()</code> catches the <code>UnableToLinkException</code> from link builders and only returns the link text. Additionally the exception details should be logged to simplify debugging.</p> TYPO3 Core - Bug #82518 (Closed): Broken composite form element check in RenderAllFormValuesViewH...http://forge.typo3.org/issues/825182017-09-20T13:51:32ZMathias Brodalambrodala@pagemachine.de
<p>The check for composite form elements in the <code>RenderAllFormValuesViewHelper</code> is broken:</p>
<pre>
if (
!$element instanceof FormElementInterface
|| $element->getType() === 'Honeypot'
|| (
isset($renderingOptions['_isCompositeFormElement'])
&& $renderingOptions['_isCompositeFormElement'] = true
)
) {
continue;
}
</pre>
<p>This was implicitly fixed for master in <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: EXT:form - do not show hidden field on confirmation page (Closed)" href="http://forge.typo3.org/issues/81770">#81770</a>.</p> TYPO3 Core - Bug #81760 (Closed): Typo in label for "Recently updated pages" menu descriptionhttp://forge.typo3.org/issues/817602017-06-30T15:23:09ZMathias Brodalambrodala@pagemachine.de
<p>The description of the <strong>Recently updated pages</strong> menu currently says:</p>
<blockquote>
<p>Menu of recenlty updated pages</p>
</blockquote>
<p>This should be fixed to say <em>recently</em>.</p> TYPO3 Core - Bug #81297 (Closed): Extbase record preview leads to 404 due to missing cHashhttp://forge.typo3.org/issues/812972017-05-22T14:56:45ZMathias Brodalambrodala@pagemachine.de
<p>With <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: Require cHash for cached plugin actions in Extbase (Closed)" href="http://forge.typo3.org/issues/78002">#78002</a> the cHash is enforced for Extbase plugins if arguments are present. This however breaks the <a href="https://docs.typo3.org/typo3cms/TSconfigReference/PageTsconfig/TCEmain/Index.html#preview" class="external">record preview</a> feature since it does not add a <code>cHash</code> argument but uses <code>no_cache</code> instead.</p>
<p>A possible fix could be <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Avoid usage of no_cache in preview link configuration (Closed)" href="http://forge.typo3.org/issues/78336">#78336</a> which adds an option to enable <code>cHash</code> calculation for record preview URLs.</p> TYPO3 Core - Bug #80316 (Closed): Misleading deprecation message for GeneralUtility::requireOnce/...http://forge.typo3.org/issues/803162017-03-17T09:58:20ZMathias Brodalambrodala@pagemachine.de
<p>The methods <code>GeneralUtility::requireOnce()</code> and <code>GeneralUtility::requireFile</code> currenty log a message like the following upon usage:</p>
<pre>
TYPO3\CMS\Core\Utility\GeneralUtility::requireOnce() - since TYPO3 CMS 8, this file will be removed in TYPO3 CMS 9
</pre>
<p>Since <code>GeneralUtility.php</code> is unlikely to be removed that soon, this should be fixed. ;-)</p> TYPO3 Core - Task #77153 (Closed): Mention fileinfo PHP extensionhttp://forge.typo3.org/issues/771532016-07-19T11:07:50ZMathias Brodalambrodala@pagemachine.de
<p>Since <a class="issue tracker-4 status-5 priority-4 priority-default closed" title="Task: Remove fileinfo as dependency in SystemEnvironment/Check (Closed)" href="http://forge.typo3.org/issues/74177">#74177</a> the PHP extension <code>fileinfo</code> is no hard dependency anymore. However, without this extension the detection of file types does not work at all. This results in files being shown as "Unknown" in the file module and broken output in extensions which check the resource type of media (e.g. EXT:news).</p>
<p>Thus this extension should at least be mentioned in the installation instructions.</p> TYPO3 Core - Bug #76976 (Closed): Missing dependency on PHP extension "mbstring"http://forge.typo3.org/issues/769762016-07-07T12:19:28ZMathias Brodalambrodala@pagemachine.de
<p>All current TYPO3 LTS versions require the PHP extension "mbstring" which is mentioned in the installation requirements but not checked anywhere. This should be added to the Composer manifest as well as the system environment check.</p> TYPO3 Core - Bug #73518 (Closed): Disabled menu item state wrong for pages hidden in default lang...http://forge.typo3.org/issues/735182016-02-17T11:20:03ZMathias Brodalambrodala@pagemachine.de
<p>With <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: Use API to check for "Hide default translation of page" (Closed)" href="http://forge.typo3.org/issues/73083">#73083</a> a cleanup was performed but an error was introduced in the backport to 6.2 which breaks the disabled menu item state (<code>USERDEF1</code> / <code>USERDEF2</code>).</p> TYPO3 Core - Bug #73083 (Closed): Use API to check for "Hide default translation of page"http://forge.typo3.org/issues/730832016-02-02T17:15:33ZMathias Brodalambrodala@pagemachine.de
<p>Throughout the core the logic to handle <code>pages.l18n_cfg</code> with value <code>1</code> (Hide default translation of page) is duplicated instead of calling <code>GeneralUtility::hideIfDefaultLanguage()</code> This should be fixed.</p>