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 - 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 - 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 - 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 #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 #94816 (Closed): Missing "View" button on pages with doktype > 200http://forge.typo3.org/issues/948162021-08-11T13:17:38ZMathias Brodalambrodala@pagemachine.de
<p>When editing a content element on a page with <code>doktype</code> > 200 the view button will not render this page in the frontend.</p> TYPO3 Core - Bug #94815 (Closed): Cannot link to pages with doktype > 200http://forge.typo3.org/issues/948152021-08-11T13:16:54ZMathias Brodalambrodala@pagemachine.de
<p>Pages with <code>doktype</code> > 200 will be muted in the page tree, just as Sysfolders. Thus you cannot set links to pages with <code>doktype</code> > 200 or content elements on these pages.</p> TYPO3 Core - Bug #94814 (Closed): Cannot use page with doktype > 200 as shortcut targethttp://forge.typo3.org/issues/948142021-08-11T13:16:20ZMathias Brodalambrodala@pagemachine.de
<p>A shortcut to a page with a <code>doktype</code> > 200 does not work in Shortcut Mode <strong>First subpage of selected/current page</strong>.</p>
<p>Subpages of the current page with a @doktypeq > 200 will not be considered and thus not called in the frontend, even if they clearly are the first subpage of the shortcut.</p> TYPO3 Core - Bug #92454 (Closed): Invalid colPos/language UID used in "Languages" view with defLa...http://forge.typo3.org/issues/924542020-09-30T14:25:00ZMathias Brodalambrodala@pagemachine.de
<p>Given the "Languages" view is used in the Page module with <code>mod.web_layout.defLangBinding</code> enabled, when reordering content elements in a custom section (<code>colPos</code> > 0) via drag and drop, invalid values for <code>colPos</code> and <code>sys_language_uid</code> are sent to the backend and eventually the <code>DataHandler</code>:</p>
<pre>
cmd[tt_content][13][move]: -10
data[tt_content][13][colPos]: false
data[tt_content][13][sys_language_uid]: NaN
</pre>
<p>Here <code>13</code> is the UID of the dragged content element and <code>10</code> is the UID of the content element after which the dragged element should be sorted.</p>
<p>This affects sorting to positions anywhere else but the beginning of the section. The "Columns" view is fine however.</p>
<p>This make it impossible to move the record:</p>
<blockquote>
<p>2: SQL error: 'Incorrect integer value: 'false' for column 'colPos' at row 1' (tt_content:13)</p>
</blockquote>
<p>This can be observed in TYPO3v8 and TYPO3v9. Probably also TYPO3v10 with the classic Page module but this cannot be checked ATM due to <a class="issue tracker-1 status-5 priority-4 priority-default closed child" title="Bug: Page Module: No content elements displayed with mod.web_layout.defLangBinding (Closed)" href="http://forge.typo3.org/issues/90617">#90617</a>.</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>