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 - 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> TYPO3 Core - Bug #84497 (Closed): RsaEncryptionEncoder::getRsaPublicKey() must not be deprecatedhttp://forge.typo3.org/issues/844972018-03-20T12:16:24ZMathias Brodalambrodala@pagemachine.de
<p>With <a class="issue tracker-4 status-5 priority-4 priority-default closed" title="Task: Extract request processing from RsaEncryptionEncoder (Closed)" href="http://forge.typo3.org/issues/84407">#84407</a> the <code>RsaEncryptionEncoder::getRsaPublicKey()</code> method was deprecated since it is used in the now deprecated request handling of that class.</p>
<p>However that method has value for 3rd party code too since otherwise people need to copy these lines into their code.</p>
<p>The method should not be deprecated. In fact <code>RsaPublicKeyGenerationController</code> should probably use it too to avoid code duplication.</p>