TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692021-11-23T09:53:47ZTYPO3 Forge
Redmine 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 #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 #93679 (Closed): Cropping to 0 (zero) pixels height/width breaks page/content ed...http://forge.typo3.org/issues/936792021-03-08T14:49:53ZMathias Brodalambrodala@pagemachine.de
<p>It is possible to store an image cropping configuration of 0 (zero) pixels in width or height. For this an editor simply needs to reduce the cropping frame to 0 in width or height. After saving an error shows up:</p>
<blockquote>
<p>Width and height of the image must be greater than zero</p>
</blockquote>
<p>(See <a class="external" href="https://github.com/TYPO3/TYPO3.CMS/blob/10.4/typo3/sysext/core/Classes/Imaging/ImageDimension.php#L76">https://github.com/TYPO3/TYPO3.CMS/blob/10.4/typo3/sysext/core/Classes/Imaging/ImageDimension.php#L76</a>)</p>
<p>Unless the <code>crop</code> field of the affected <code>sys_file_reference</code> record is cleared/fixed manually in the database, viewing the page in the <em>Page</em> module or editing the affected record in the <em>List</em> module is impossible due to this error.</p>
<p>A few options to fix this:</p>
<ol>
<li>Require a minimum of 1x1 Pixel for cropping</li>
<li>Display error and disable <em>Accept</em> in the <em>Image manipulation</em> wizard</li>
<li>Handle a width/height of 0 Pixel more gratuitously in <code>ImageDimension</code>.</li>
</ol> TYPO3 Core - Bug #87328 (New): "Make new translation of this page" can create invalid page transl...http://forge.typo3.org/issues/873282019-01-04T14:05:41ZMathias Brodalambrodala@pagemachine.de
<p>Since <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: BE page module => 'Make new translation of this page' doesn't use command localize to create tran... (Closed)" href="http://forge.typo3.org/issues/81345">#81345</a> the <strong>Make new translation of this page</strong> feature within the page module directly creates localizations instead of opening the edit view for page translations.</p>
<p>This can lead to invalid page translations if e.g. the <code>title</code> has been configured to be empty in translations (unset <code>l10n_mode</code>) and thus must be filled by editors explicitly. In this case the edit view is shown correctly with errors after localization but one can simply close the view without additional prompt or action. After this the translation exists without title which in itself can lead to further issues. When trying to save instead a proper dialog is shown mentioning the invalid fields.</p> TYPO3 Core - Bug #87149 (Closed): Cannot debug Generator outputhttp://forge.typo3.org/issues/871492018-12-13T15:08:23ZMathias Brodalambrodala@pagemachine.de
<p>If <code>DebuggerUtility::var_dump()</code> is used on a <code>\Generator</code>, an error occurs:</p>
<blockquote>
<p>Cannot rewind a generator that was already run</p>
</blockquote>
<p>This is due to the implicit <code>rewind()</code> call within <code>DebuggerUtility::renderCollection()</code> which should be avoided for generators.</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 #86935 (Closed): Cannot fetch 404 page with simple basehttp://forge.typo3.org/issues/869352018-11-15T14:37:06ZMathias Brodalambrodala@pagemachine.de
<p>If you set up the <code>errorHandling</code> in a site configuration to use the <code>errorHandler: Page</code> and a dedicated page as <code>errorContentSource</code> this page cannot be displayed if you use a <code>base</code> without a full URL like <code>/</code> or <code>/en/</code> (for language variants)</p>
<p>The following error is displayed as HTML response in this case:</p>
<blockquote>
<p>Error handler could not fetch error page: Possible recursion detected.</p>
</blockquote>
<p>There are many problems with this error message itself:</p>
<ul>
<li>It does not contain the internally resolved URL</li>
<li>It does not contain the exact error message which occurred</li>
</ul>
<p>In this very case a <code>errorContentSource</code> like <code>t3://page?uid=10</code> is resolved to <code>/404</code> (if that's the slug of the 404 page) by the <code>PageContentErrorHandler</code>. Then <code>GeneralUtility::getUrl()</code> tries to load this as a file called <code>/404</code> in the filesystem of the web server since the resolved URL does not contain a scheme and host. At least this additional error could be avoided by using the <code>RequestFactory</code> directly.</p>
<p>The error itself should be fixed by prepending the current scheme and host in case the resolved URL is not a full URL. The <code>PageContentErrorHandler</code> only supports pages and full URLs anyways. This could make it necessary to add an additional <code>StaticFileErrorHandler</code> to cover cases where displaying content of a static file really was intended.</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 - Bug #83260 (Closed): Cannot set "class" for file upload elementhttp://forge.typo3.org/issues/832602017-12-08T14:26:31ZMathias Brodalambrodala@pagemachine.de
<p>HTML classes set via <code>elementClassAttribute</code> for the <code>FileUpload</code> element are not respected.</p> TYPO3 Core - Bug #82853 (Closed): Cannot translate field options by typehttp://forge.typo3.org/issues/828532017-10-25T11:41:28ZMathias Brodalambrodala@pagemachine.de
<p>The translation chain for field options (e.g. for <code>SingleSelect</code>) can only be translated a) by form identifier + field identifier or b) by field identifier. Other properties also include c) by field type.</p>
<p>This should be added.</p> TYPO3 Core - Bug #82717 (Closed): DatabaseRecordLinkBuilder does not respect fragment from linkhttp://forge.typo3.org/issues/827172017-10-10T12:57:08ZMathias Brodalambrodala@pagemachine.de
<p>The <code>DatabaseRecordLinkBuilder</code> executes <code>typoLink</code> with the given link details and a matching link handler configuration.</p>
<p>However, currently the fragment (<code>#foo</code>) is not forwarded to the TypoLink configuration (<code>section</code>).</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 #76928 (Closed): Cannot use speaking paths containing "typo3"http://forge.typo3.org/issues/769282016-07-04T16:16:12ZMathias Brodalambrodala@pagemachine.de
<p>If I use an extension for speaking paths (RealURL/CoolURI/...) and create a page named "TYPO3", the path segment will be ".../typo3/". Opening that page yields a 404 from the webserver.</p>
<p>This is caused by a too generous <code>RewriteRule</code> in the default <code>.htaccess</code> which is meant for passing through static resources.</p>