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 #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 #84491 (Closed): Breaks field in EXT:styleguidehttp://forge.typo3.org/issues/844912018-03-20T09:21:36ZMathias Brodalambrodala@pagemachine.de
<p>EXT:styleguide, elements basic > text_17 breaks with</p>
<blockquote>
<p>Argument 2 passed to TYPO3\CMS\Backend\Controller\Wizard\TableController::configurationStringToArray() must be of the type integer, null given, called in /.../typo3/sysext/backend/Classes/Controller/Wizard/TableController.php on line 496</p>
</blockquote> TYPO3 Core - Bug #84469 (Closed): State of "Show hidden content elements" not storedhttp://forge.typo3.org/issues/844692018-03-18T13:09:36ZMathias Brodalambrodala@pagemachine.de
<p>The checkbox <em>Show hidden content elements</em> shown in the page module if there are hidden elements does not store its state. When re-opening the same page, the checkbox is checked again even after unchecking. This works properly in TYPO3v8.</p> TYPO3 Core - Bug #81524 (Closed): Cannot send mails with special characters in local parthttp://forge.typo3.org/issues/815242017-06-09T12:47:40ZMathias Brodalambrodala@pagemachine.de
<p>Currently it is impossible to send mails with special characters in their local part, e.g. <code>john.lötzsch@example.org</code>. Swiftmailer fails with the following error:</p>
<pre>
[ Swift_RfcComplianceException ]
Address in mailbox given [john.lötzsch@example.org] does not comply with RFC 2822, 3.6.2.
thrown in file er/lib/classes/Swift/Mime/Headers/MailboxHeader.php
in line 345
</pre>
<p>The mentioned <a href="https://tools.ietf.org/html/rfc2822" class="external">RFC 2822</a> has been extended by <a href="https://tools.ietf.org/html/rfc5335" class="external">RFC 5335</a> which is <a href="https://github.com/swiftmailer/swiftmailer/commit/e7cf4bd807b44be83d8922b3a1abe4d11a3fb15a" class="external">supported by Swiftmailer 6.x and newer</a>, thus an upgrade is necessary. This implies a few <a href="https://github.com/swiftmailer/swiftmailer/blob/v6.0.0/CHANGES#L4" class="external">breaking changes</a> however.</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>