TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692021-12-07T09:29:03ZTYPO3 Forge
Redmine 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 - 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 #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> TYPO3 Core - Bug #53974 (Closed): Environment variables prefixed with REDIRECT_ ignoredhttp://forge.typo3.org/issues/539742013-11-26T11:16:07ZMathias Brodalambrodala@pagemachine.de
<p>Using Apache mod_rewrite in certain setups (mostly PHP in CGI mode) makes environment variables from original requests available in the target request as <code>REDIRECT_<envvar></code>, thus e.g. setting <code>TYPO3_DISABLED_CORE_UPDATER</code> becomes <code>REDIRECT_TYPO3_DISABLED_CORE_UPDATER</code>.</p>
<p>This should be handled transparently by <code>GeneralUtility::getIndpEnv()</code> and relevant locations be updated (e.g. <code>TYPO3_CONTEXT</code>, <code>TYPO3_DISABLE_CORE_UPDATER</code>).</p>