TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692023-08-09T17:07:24ZTYPO3 Forge
Redmine TYPO3 Core - Bug #101640 (Resolved): PHP Warning: Undefined array key "eval" in ...core/Classes/D...http://forge.typo3.org/issues/1016402023-08-09T17:07:24ZErnesto Baschnyeb@cron.eu
<p>In case I have a TCA "slug" field without a "eval" config, PHP 8 will bail out with this exception, for example when moving a page in the backend:</p>
<pre><code>PHP Warning: Undefined array key "eval" in /srv/www/www_dhbw_de/releases/60/private/typo3/sysext/core/Classes/DataHandling/DataHandler.php line 8390</code></pre> TYPO3 Core - Bug #65646 (Closed): Scheduler misses the "stop" icon when a task is running (6.2 only)http://forge.typo3.org/issues/656462015-03-10T20:21:27ZErnesto Baschnyeb@cron.eu
<p>Since <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: Deleted scheduler task groups selectable (Closed)" href="http://forge.typo3.org/issues/63973">#63973</a> was backported to 6.2 the "stop.png" icon is missing when a task is running and therefor a "broken image" appears in the scheduler instead.</p>
<p>The path of the stop.png changed from 6.2 to master and this was not considered in the backport.</p>
<p>Solution is to fix the backport with a follow-up.</p> TYPO3 Core - Task #60622 (Rejected): Deprecate getUrl, curlProxyServer and encourage usage of HTT...http://forge.typo3.org/issues/606222014-07-27T15:34:20ZErnesto Baschnyeb@cron.eu
<p>The SYS.curl* settings are being used by GeneralUtility::getUrl and openid. And probably other extensions are using that too.</p>
<p>Since 6.0 we have the nice HttpRequest adapter for the PEAR HTTP_Request2 component, which is a full replacement of what our old getUrl does.</p>
<p>So we want to deprecate getUrl along with the curl* settings.</p> TYPO3 Core - Bug #57262 (Closed): Install Tool: getFolderStatus ajax also being called in Step In...http://forge.typo3.org/issues/572622014-03-25T01:23:42ZErnesto Baschnyeb@cron.eu
<p>The Ajax calls to getFolderStatus and getEnvironmentStatus are useful to add the badges in the left menu of the Install Tool.</p>
<p>But they are also being fired when the Step Installer is running (no Left Menu).</p>
<p>It would be more stable if we would only fire these ajax calls when the Left Menu is indeed loaded and not regardless of the page you are in.</p> TYPO3 Core - Bug #53975 (Closed): BeLog: Exception when time input fields are emptyhttp://forge.typo3.org/issues/539752013-11-26T11:20:41ZErnesto Baschnyeb@cron.eu
<p>If you go to "Info>Log" or "Admin>Log" and select "Userdefined" time range and then leave one of the input fields (start or stop) empty and click "Set", you end up with this exception:</p>
<p>Exception while property mapping at property path "":PHP Catchable Fatal Error: Argument 1 passed to TYPO3\CMS\Belog\Domain\Model\Constraint::setManualDateStop() must be an instance of DateTime, null given, called in .../html/typo3_src/typo3/sysext/extbase/Classes/Reflection/ObjectAccess.php on line 215 and defined in .../html/typo3_src/typo3/sysext/belog/Classes/Domain/Model/Constraint.php line 273</p>
<p>When you are in this situation and go to the module again, even changing the Time Select Box to "Undefined" you still get this error (probably because the empty input fields are hidden but submitted again).</p>
<p>And empty input field in start/stop should remove this specific limit.</p> TYPO3 Core - Feature #53666 (Closed): One search box onlyhttp://forge.typo3.org/issues/536662013-11-15T14:39:26ZErnesto Baschnyeb@cron.eu
<p>During the UXW09 it was defined that we only want to end up with one single "search box" (the one at the top right). So the "search" below the List-module should be gone too.</p>
<p>The idea was that the "global search" and the "page specific search" should be done from this central area, and the different search results grouped in separate tabs.</p>
<p>See this screen from back then:</p>
<p><img src="http://forge.typo3.org/attachments/download/25503/typo3-search-global-uxw09.png" alt="" loading="lazy" /></p>
<p>This implementation seem to be missing or gone. Screenshot is grabbed from this page:</p>
<p><a class="external" href="http://forge.typo3.org/projects/usability/wiki/T3UXW09-Team4#The-search-result-list">http://forge.typo3.org/projects/usability/wiki/T3UXW09-Team4#The-search-result-list</a></p>
<p>Maybe you find other interesting details from the concept back then.</p> TYPO3 Core - Bug #51698 (Closed): Delete sys_file entry when a file is deletedhttp://forge.typo3.org/issues/516982013-09-03T22:22:40ZErnesto Baschnyeb@cron.eu
<p>In order to keep sys_file as much in sync with the real file system as possible we should delete the relevant sys_file entry as soon as a file is deleted.</p>
<p>This is part of the "plan" in <a class="issue tracker-4 status-5 priority-4 priority-default closed parent" title="Task: Handling of deleted files in FAL (Closed)" href="http://forge.typo3.org/issues/50876">#50876</a> and should also be backported to 6.0/6.1 to keep the API straight and uniform throughout the releases.</p> TYPO3 Core - Bug #50803 (Closed): Fatal error: "enableFields on non-object" in extension managerhttp://forge.typo3.org/issues/508032013-08-05T22:25:44ZErnesto Baschnyeb@cron.eu
<p>Extbase extensions might fail with:</p>
<p>Fatal error: Call to a member function enableFields() on a non-object in .../typo3_src/typo3/sysext/core/Classes/Resource/StorageRepository.php on line 211</p>
<p>The problem was "uncovered" with the <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Find best-matching local storage instead of default-storage (Closed)" href="http://forge.typo3.org/issues/45498">#45498</a> (the new EM fatals with this error since this patch), but could happen in other situations too.</p>
<p>Reason is that Extbase in certain situations will try to create a dummy simulated "TSFE" object to be able to use cObject stdWrap's in the backend context.</p>
<p>Now this is not a "complete TSFE" and doesn't for example include a proper sys_page property.</p>
<p>So to make sure we are in a proper FE context, we shouldn't rely on "is_object($TSFE)" but instead check if TYPO3_MODE==FE like it is done throughout other places in the core.</p> TYPO3 Core - Bug #45834 (Closed): Detection of curlProxyServer settings buggy on upgrade to 6.0http://forge.typo3.org/issues/458342013-02-25T19:24:39ZErnesto Baschnyeb@cron.eu
<p>In <a class="issue tracker-2 status-5 priority-3 priority-lowest closed behind-schedule" title="Feature: Include HTTP Request2 for better HTTP handling (Closed)" href="http://forge.typo3.org/issues/28344">#28344</a> "HTTP Request2" API was included. It supports detecting old school "curlProxyServer" settings and transfer these to the "new" setting under HTTP:</p>
<pre>
$proxyParts = explode(':', $GLOBALS['TYPO3_CONF_VARS']['SYS']['curlProxyServer'], 2);
$GLOBALS['TYPO3_CONF_VARS']['HTTP']['proxy_host'] = $proxyParts[0];
$GLOBALS['TYPO3_CONF_VARS']['HTTP']['proxy_port'] = $proxyParts[1];
</pre>
<p>This code ended up in Core/Bootstrap::transferDeprecatedCurlSettings() after namespace and bootstrapification.</p>
<p>I have always set up this setting like this:</p>
<pre>
$GLOBALS['TYPO3_CONF_VARS']['SYS']['curlProxyServer'] = 'http://proxy:3128';
</pre>
<p>I guess the implementator of the transferDeprecatedCurlSettings was only thinking about the "proxy:3128" kind of syntax. I end up with:</p>
<pre>
$GLOBALS['TYPO3_CONF_VARS']['HTTP']['proxy_host'] = 'http'
$GLOBALS['TYPO3_CONF_VARS']['HTTP']['proxy_port'] = '//proxy:3128;
</pre>
<p>Other than that, I would also auto-set ['HTTP']['adapter'] to 'curl' if legacy 'curlUse' = TRUE.</p> TYPO3 Core - Bug #30636 (Closed): TCA: subtypes_addlist not being processed if the subtype_value_...http://forge.typo3.org/issues/306362011-10-07T17:32:47ZErnesto Baschnyeb@cron.eu
<a name="How-to-reproduce"></a>
<h2 >How to reproduce:<a href="#How-to-reproduce" class="wiki-anchor">¶</a></h2>
<p>Install mc_googlesitemap in TYPO3 4.5 and wonder where the referred fields from the documentation are: they are not rendered. They are supposed to appear in the content element of type "Menu/Sitemap" when you choose one of the newly introduced Subtypes "Sitemaps for Contents" or "Sitemaps for Pages".</p>
<p><img src="http://forge.typo3.org/attachments/download/19013/subtype_addlist-bug.png" title="Bug in action (extension mc_googlesitemap)" alt="Bug in action (extension mc_googlesitemap)" loading="lazy" /></p>
<a name="Background"></a>
<h2 >Background:<a href="#Background" class="wiki-anchor">¶</a></h2>
<p>Extensions can add fields to an existing table depending on a certain "subtype". E.g. Content Element of type "menu" has subtype stored in "menu_type". Extension mc_googlesitemap wants to add fields depending on the menu_type:</p>
<p>$TCA["tt_content"]["types"]["menu"]["subtype_value_field"]="menu_type";<br />$TCA["tt_content"]["types"]["menu"]["subtypes_addlist"][$_EXTKEY."_pi1"]= ...</p>
<p>This used to work fine since 4.4, but in 4.5 the "menu_type" field is now inside a palette, so the new fields have <strong>no</strong> place to be positioned and so they are not rendered at all.</p>
<a name="Solution"></a>
<h2 >Solution:<a href="#Solution" class="wiki-anchor">¶</a></h2>
<p>Go through the palettes too, and add the new fields right after the palette where the field resides in. Now it looks like this:</p>
<p><img src="http://forge.typo3.org/attachments/download/19014/subtype_addlist-correct.png" title="How it looks with the proposed fix" alt="How it looks with the proposed fix" loading="lazy" /></p> TYPO3 Core - Bug #25772 (Closed): Resizeable textareas: scrollbar sticks to mousehttp://forge.typo3.org/issues/257722011-04-05T17:05:00ZErnesto Baschnyeb@cron.eu
<p>If you have resizeable textareas enabled and you try to use the scrollbar to scroll in your content with Internet Explorer 8, the re-sizing feature "sticks" to your mouse pointer (even after releasing the mouse button).</p>
<p>You can try it out with PageTS field in Page properties.</p> TYPO3 Core - Bug #25771 (Closed): Resizeable textareas with Internet Explorer (IE8): random jumps...http://forge.typo3.org/issues/257712011-04-05T17:03:08ZErnesto Baschnyeb@cron.eu
<p>Since 4.4 (?) textareas (e.g. PageTS field in the Page settings) are resizeable. With Internet Explorer there are some problems with it:</p>
<p>If in the user settings you disable the entry "Make Textareas Resizeable", you are not able to click on any line without causing the scrollbar to randomly jump around the content, thus making it very difficult to edit content in these fields.</p> TYPO3 Core - Bug #24914 (Closed): Upgrade Wizard "Install Outsourced System Extensions" should on...http://forge.typo3.org/issues/249142011-02-01T12:11:22ZErnesto Baschnyeb@cron.eu
<p>The Upgrade Wizard "Install Outsourced System Extensions" (tx_coreupdates_installsysexts) suggests the user to install all system extensions, even those which are already installed. This is confusing to the user that is doing a "new installation" based on the intro package for example, where all those extensions are already installed by default.</p>
<p>Solution would be to do the same logic as we have in "tx_coreupdates_installnewsysexts", which checks every extension if they are installed (and if all are installed, don't present the wizard at all!).</p>
<p>(issue imported from #M17429)</p> TYPO3 Core - Bug #24681 (Closed): CSH tooltips should be placed nearer to the texthttp://forge.typo3.org/issues/246812011-01-20T13:39:57ZErnesto Baschnyeb@cron.eu
<p>Since <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: CSH tooltip often gets in the way of the field it is supposed to provide help for (Closed)" href="http://forge.typo3.org/issues/24578">#24578</a> the tooltips are on top of the labels, improving the usability. But they are some px too far away. Also the (?) icon in the docheader, the arrow pointing out to the tooltip is not placed aligned with the icon.</p>
<p>Solution is to offset the pointer -10px and also move the tooltip closer with some ExtJS magic.</p>
<p>(issue imported from #M17163)</p> TYPO3 Core - Bug #24634 (Closed): Make the t3lib_utility_Mail hook subscriber optional / configur...http://forge.typo3.org/issues/246342011-01-18T10:03:45ZErnesto Baschnyeb@cron.eu
<p>t3lib_utility_Mail::mail subscribed hook allows "old applications" which used to send mail through it to go through SwiftMailer instead.</p>
<p>This allows old extensions which haven't been ported to make use of SwiftMailer to gain access to the configurability of SwiftMailer (different transports) and send RFC conformant E-Mails.</p>
<p>This works fine for simple cases but will fail as soon as the sending application already tried to create the MIME confirmity itself (e.g. by using other libraries or doing it on its own). We don't want to add a full MIME parsing routines in Core just because of that backwards compatibility!</p>
<p>Since this cannot be detected, we implement a switch to disable the subscribed hook.</p>
<p>So if your installation uses some extension which sends mails, test if it works and that the generated mails are ok "out of the box" (which means that the SwiftMail hook is working), if it is not working (e.g. empty body of the mail, wrong attachment count, or garbled mail content), use the switch to turn the hook off (which also means that the configured transport under [MAIL] are not regarded anymore, and mails are send using the old school mail() method.</p>
<p>(issue imported from #M17109)</p>