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 #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 - Bug #89169 (Closed): Redirects indey key too long after source path increasehttp://forge.typo3.org/issues/891692019-09-13T17:00:04ZMathias Brodalambrodala@pagemachine.de
<p>Due to <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: redirects: longer URL strings are stripped in source_path (Closed)" href="http://forge.typo3.org/issues/88336">#88336</a> redirect URLs can now be longer. However, this also affects the <code>index_source</code> index which includes <code>source_host</code> and <code>source_path</code> which now easily extends regular index limits:</p>
<pre>
$ typo3cms d:u -vvv
No schema updates were performed for update types:
"field.add", "field.change", "table.add", "table.change"
The following errors occurred:
+---------------+-------------------------------------------------+-----------------------------+
| Type | SQL Statement | Message |
+---------------+-------------------------------------------------+-----------------------------+
| Change fields | ALTER TABLE `sys_redirect` CHANGE `source_path` | Specified key was too long; |
| | `source_path` VARCHAR(2048) DEFAULT '' NOT NULL | max key length is 3072 |
| | | bytes |
| | | |
+---------------+-------------------------------------------------+-----------------------------+
</pre>
<p>The collation is <code>utf_general_ci</code> for the mentioned fields and table.</p>
<p>After manually dropping the <code>index_source</code> index the change can be applied however:</p>
<pre>
$ typo3cms d:u -vvv
The following database schema updates were performed:
+---------------+-------------------------------------------------+
| Type | SQL Statements |
+---------------+-------------------------------------------------+
| Add fields | CREATE INDEX `index_source` ON `sys_redirect` |
| | (source_host(80), source_path(80)) |
| Change fields | ALTER TABLE `sys_redirect` CHANGE `source_path` |
| | `source_path` VARCHAR(2048) DEFAULT '' NOT NULL |
+---------------+-------------------------------------------------+
</pre> 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 #85914 (Closed): Errors in L10nModeUpdater with "l10n_mode = exclude" in pages_l...http://forge.typo3.org/issues/859142018-08-21T09:20:32ZMathias Brodalambrodala@pagemachine.de
<p>Given a field in <code>pages_language_overlay</code> marked with <code>'l10n_mode' => 'exclude'</code> the <code>L10nModeUpdater</code> fails to process all records when upgrading from TYPO3v7 to TYPO3v8. The error:</p>
<blockquote>
<p>Child record was not processed</p>
</blockquote>
<p>In our specific case the field <code>media</code> was marked as such since editors are not supposed to manage it in translations. (Notice that the field is actually never hidden, see <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: TCA pages_language_overlay column 'l10n_mode' => 'exclude' gets ignored (Closed)" href="http://forge.typo3.org/issues/81348">#81348</a>) When running the upgrade wizard, it constantly failed with the mentioned error message but in fact did get further by one record on each run.</p>
<p>While looking into this I noticed that the <code>DataMapProcessor</code> determines if <code>'l10n_mode' => 'exclude'</code> is set for a field based on <code>DataMapItem::getFromTableName()</code> which is always <code>pages</code> for <code>pages_language_overlay</code>. Thus for the given example above <code>$GLOBALS['TCA']['pages']['columns']['media']['l10n_mode']</code> is checked instead of <code>$GLOBALS['TCA']['pages_language_overlay']['columns']['media']['l10n_mode']</code>.</p>
<p>After moving the <code>l10n_mode</code> to the TCA of <code>pages</code> instead I noticed that this is reverted on the fly by <code>TcaMigration::migratePageLocalizationDefinitions()</code> which moves the <code>l10n_mode</code> back from <code>pages</code> to <code>pages_language_overlay</code>. So it looks like like it is in fact impossible to set <code>l10n_mode</code> for columns of <code>pages</code>/<code>pages_language_overlay</code>.</p>
<p>In the end the issue could be solved/worked around by dropping <code>l10n_mode</code> completely here but I think that's not how it's supposed to be.</p> TYPO3 Core - Bug #85536 (Closed): Missing mail part content type in Test Mail Setuphttp://forge.typo3.org/issues/855362018-07-12T09:53:35ZMathias Brodalambrodala@pagemachine.de
<p>The <strong>Test Mail Setup</strong> in the <strong>Enviroment</strong> section of the maintenance area sends mails with a HTML body and a plain text part. However, the latter does not have a content-type which it should have for a cleaner mail structure.</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 - Bug #85139 (Closed): Invalid arguments for method call matcherhttp://forge.typo3.org/issues/851392018-06-01T12:31:22ZMathias Brodalambrodala@pagemachine.de
<p>The changes from <a class="issue tracker-4 status-5 priority-4 priority-default closed" title="Task: Deprecate usages of CharsetConverter in core (Closed)" href="http://forge.typo3.org/issues/85125">#85125</a> and <a class="issue tracker-4 status-5 priority-4 priority-default closed" title="Task: Deprecate Backend Module Routing methods (Closed)" href="http://forge.typo3.org/issues/85113">#85113</a> introduced an invalid/incomplete argument configuration for the method call matcher. These should be fixed.</p> TYPO3 Core - Bug #85111 (Closed): HTTPS not used for cross-domain links without forceAbsoluteUrlhttp://forge.typo3.org/issues/851112018-05-29T16:10:58ZMathias Brodalambrodala@pagemachine.de
<p>If you add a cross-domain link and set <code>forceAbsoluteUrl</code> the <a href="https://github.com/TYPO3/TYPO3.CMS/blob/1ab8bcf/typo3/sysext/frontend/Classes/Typolink/PageLinkBuilder.php#L170-L172" class="external">link will use HTTPS if the current site uses HTTPS</a>.</p>
<p>However, the same logic is missing in case <code>forceAbsoluteUrl</code> is not set which will normally lead to a relative link. Cross-domain links are absolute per definition however so all links will use HTTP instead of HTTPS.</p>