TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692023-07-25T18:53:46ZTYPO3 Forge
Redmine TYPO3 Core - Bug #101443 (Closed): Exception 'Undefined array key "pid"' after moving content in ...http://forge.typo3.org/issues/1014432023-07-25T18:53:46ZErnesto Baschnyeb@cron.eu
<a name="Preconditions"></a>
<h2 >Preconditions:<a href="#Preconditions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Any TYPO3 v11 (or later) installation</li>
<li>PHP 8.x</li>
<li>Workspaces extension enabled</li>
<li>no further extensions or configuration required</li>
</ul>
<a name="How-to-reproduce"></a>
<h2 >How to reproduce:<a href="#How-to-reproduce" class="wiki-anchor">¶</a></h2>
<ul>
<li>Create a Workspace</li>
<li>Create a page</li>
<li>Add two content elements (in LIVE mode)</li>
<li>Switch to the workspace</li>
<li>Drag & drop the first element after the second element - page will be marked as "modified" in the page tree</li>
<li>Try to add a new content element between or after these elements</li>
</ul>
<p>You get this exception:</p>
<pre><code>PHP Warning: Undefined array key "pid" in /app/packages/typo3/typo3/sysext/backend/Classes/Utility/BackendUtility.php line 3445</code></pre>
<a name="Background"></a>
<h2 >Background<a href="#Background" class="wiki-anchor">¶</a></h2>
<p>This bug was introduced with <a class="external" href="https://review.typo3.org/c/Packages/TYPO3.CMS/+/65797">https://review.typo3.org/c/Packages/TYPO3.CMS/+/65797</a></p>
<p>A potential workaround is to add the "pid" field to the list of `BackendUtilities::getCommonSelectFields` (see attached patch, which we will deploy in production to our customer to get around the problem for now). But maybe this is just hiding the real "problem". The @todos in `BackendUtilities::workspaceOL` give me a vibe that something could be fishy around here.</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 - Bug #53940 (Rejected): Extension name is not case insensitive in anymorehttp://forge.typo3.org/issues/539402013-11-25T15:30:01ZErnesto Baschnyeb@cron.eu
<p>The extension "abaticker" for example contains something like:</p>
<pre>
t3lib_extMgm::addPlugin(Array("LLL:EXT:abaTicker/locallang_db.php:tt_content.list_type_pi1", $_EXTKEY."_pi1"),"list_type");
</pre>
<p>In 6.2 this now fails with:</p>
<p>"TYPO3 Fatal Error: Extension key "abaTicker" is NOT loaded" (Exception 1365429656)</p>
<p>So the ExtensionManagementUtil API doesn't seem to be backwards compatible yet (i.e. extPath() etc), as it doesn't seem to expect different CaSe for the passed extension key.</p> TYPO3 Core - Bug #53692 (Closed): Backend background color is limited to height:100%http://forge.typo3.org/issues/536922013-11-16T13:27:25ZErnesto Baschnyeb@cron.eu
<p>In several backend screens where there is need to scroll, the background color stops at 100% height. This can be seen for example in the Login screen (dark gray ends abruptly when scrolling down), the Element browser (gray background) and others.</p>
<p>This is a regression introduced with <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Integrate normalize css reset (Closed)" href="http://forge.typo3.org/issues/47920">#47920</a> (adding the normalizer.css) and needs to be fixed until 6.2 release.</p>
<p>The UX team noted that also: <a class="external" href="https://projects.invisionapp.com/share/H2IU7YVE#/screens/10263303/comments/6159625">https://projects.invisionapp.com/share/H2IU7YVE#/screens/10263303/comments/6159625</a></p> TYPO3 Core - Bug #53683 (Closed): Don't underline the whole preview text in Web>Page content elem...http://forge.typo3.org/issues/536832013-11-15T21:55:21ZErnesto Baschnyeb@cron.eu
<p>Since we underline links in the backend, the Web>Page also renders all preview text inside content element boxes in underline on mouse over, because those are also links (to the edit windows). This is cluttery and ugly. So get rid of the underline of the preview text!</p>
<p>Reported and wished by the UX team.</p> TYPO3 Core - Bug #52261 (Closed): Bad position of eval=>null checkbox http://forge.typo3.org/issues/522612013-09-25T14:24:41ZErnesto Baschnyeb@cron.eu
<p>The new TCA feature "eval=>null" places a new checkbox as a wizard besides your input field. This seem to look "ok" in the sys_file_reference case (which uses the "useOrOverridePlaceholder" mode), but it looks ugly in case you have regular (non-palette) field:</p>
<p><img src="http://forge.typo3.org/attachments/download/25063/eval-null-checkbox.png" alt="" loading="lazy" /></p>
<p>Also note that a potential "options-palette" icon is misplaced too.</p>
<p>The checkbox must be placed nearer to the input field itself.</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 #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 #43466 (Closed): Drag&Drop in page module broken in Chromehttp://forge.typo3.org/issues/434662012-11-29T22:45:19ZErnesto Baschnyeb@cron.eu
<p>In current master (and branch 6.0) the drag&drop functionality is broken in Chrome (and potentially also Safari?).</p>
<p>This used to work on 6.0.0 release.</p>
<p>Using git bisect I was able to identify the change that broke it: <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: BE login shows unaesthetic scrollbars (Closed)" href="http://forge.typo3.org/issues/43330">#43330</a>. Looks harmless, but reverting it makes drag&drop work again.</p>
<p>Any candidates to explain that? :)</p> TYPO3 Core - Bug #43331 (Closed): "Strict standards: Declaration of "CompatbilityClassLoaderPhpBe...http://forge.typo3.org/issues/433312012-11-27T09:27:34ZErnesto Baschnyeb@cron.eu
<p>On PHP < 5.3 I get this warning on top of the login screen (and also in the whole backend, making it completely unusable):</p>
<p>Strict standards: Declaration of TYPO3\CMS\Core\Compatibility\CompatbilityClassLoaderPhpBelow50307::requireClassFileOnce() should be compatible with that of TYPO3\CMS\Core\Core\ClassLoader::requireClassFileOnce() in /.../typo3_src/typo3/sysext/core/Classes/Core/SystemEnvironmentBuilder.php on line 239</p>
<p>Acording to git bisect this got broken with change <a class="issue tracker-4 status-5 priority-3 priority-lowest closed" title="Task: Protect bootstrap methods (Closed)" href="http://forge.typo3.org/issues/43285">#43285</a>.</p>
<p>Indeed the declaration of the methods differ:</p>
<pre>
class ClassLoader {
...
static protected function requireClassFileOnce($classPath) {
...
</pre>
<pre>
class CompatbilityClassLoaderPhpBelow50307 extends \TYPO3\CMS\Core\Core\ClassLoader {
...
static public function requireClassFileOnce($classPath, $className) {
...
</pre>
<p>And by the way, the classname CompatbilityClassLoaderPhpBelow50307 is misspelled (misses an "i" in Compat*i*bility).</p> TYPO3 Core - Bug #13320 (Closed): Don't use cross-extension dependencies (e.g. em)http://forge.typo3.org/issues/133202011-02-24T08:15:08ZErnesto Baschnyeb@cron.eu
<p>Hi,</p>
<p>please apply the following change which was included in typo3_src already:</p>
<p><a class="external" href="http://forge.typo3.org/projects/typo3v4-core/repository/revisions/10615">http://forge.typo3.org/projects/typo3v4-core/repository/revisions/10615</a></p>
<p>We will release 4.5.1a with this fix included and want to make sure that it doesn't happen again.</p>
<p>Thanks!</p> TYPO3 Core - Bug #23798 (Closed): Add new API t3lib_befunc::helpTextArray and use it in the ExtDi...http://forge.typo3.org/issues/237982010-10-20T09:30:50ZErnesto Baschnyeb@cron.eu
<p>Currently the ExtDirect which fetches the tooltip fetches the information on its own from the $TCA_DESCR array. It will also render "TYPO3 Inline Help" as a default header if none is given and will not render an "arrow" which used to symbolize a link to a popup in its content.</p>
<p>This patch adds a new API function t3lib_befunc::helpTextArray which is then used by t3lib_befunc::helpText and also the new ExtDirect call to fetch the information. The tooltips now won't have a title anymore if there is no "alttitle" defined.</p>
<p>Almost none CSH uses "alttile", so usually you won't see any. There are some examples in the Extension manager (e.g. the main titles "Loaded Extensions" etc).<br />(issue imported from #M16074)</p> TYPO3 Core - Bug #15287 (Closed): Illegal SGML characters in outputhttp://forge.typo3.org/issues/152872005-12-15T21:00:15ZErnesto Baschnyeb@cron.eu
<p>Hi,</p>
<p>the "non SGML character number 128" is probably the most annoying validation error that TYPO3-sites hit when users from the Windows world copy&paste input some field which will go right through to the frontend.</p>
<p>THE PROBLEM<br />---------------</p>
<p>The origin of the problem comes from the fact that the ISO-Latin-1 character table specifies every character from the decimal range 32 up to 255, but has a gap in the range from 128 to 159 (see [1]). This range is (mis?)used by Microsoft in the so called "Windows-Latin-1" for various characters. The most frequently chars are the EURO-sign, the emdash ("langer Gedankenstrich", which MS-Word creates automatically if you type an hyphen with spaces around it) and opening-double-quotes (bottom) (also created by Word in German if you start some quotation).</p>
<p>So outputting these characters for the Web in "charset=iso-8859-1" mode is not "valid", because they are not part of this charset (which is also why the W3C-validator chokes on them). The very good article in [2] present some alternatives on how to output them in a generic way.</p>
<p>SOME TYPO3 SOLUTIONS<br />------------------------</p>
<p>Some time in the past I've written "cron_rte_cleanenc", which will remap those characters from the RTE into proper numerical entities (which is what the article [2] suggests as the most widely used method). This is nice, but later I figured out that these characters can also be pasted into fields that are not RTE-enabled (e.g. Title, Subtitle, etc), so my processing also works on some cases.</p>
<p>Later versions of qcom_htmlcleaner include the switch "Remap illegal chars" (clean_chars), which will translation any "high ASCII" character to a proper entity. Two problems I see with the current approach:</p>
<p>1. it only applies to XHTML_clean(), while the problem also exists in<br /> HTML mode. <br />2. it translates <strong>all</strong> characters >127 into entities, which is not<br /> needed. The range 128-159 is sufficient here, as Ä can be<br /> represented by a proper ISO-Latin-1 character already.</p>
<p>MY GOAL/AIM<br />--------------</p>
<p>I want this translation to happen in TYPO3-core, without needing any extention. Our goal has been XHTML-validity, and this is a major issue in this commitment. This is not a "xhtml_cleaning" problem, but a generic charset problem. We have proven solutions to the problem, we just need to see if they are generic enough not to hurt and add them in a meaningful way to the core.</p>
<p>HOW TO PROCEED<br />-----------------</p>
<p>We need to find out in which character sets this is a problem. If I set my site to "forceCharSet=utf-8", the problem doesn't exist, because all pasted input will have corresponding UTF-8 entities which are valid. So maybe some charset expert around could tell us a bit about it, and if noone is available, I would do some research on it. I suspect every ISO-Latin-x variant has this problem.</p>
<p>Then we need to create some patches to correct the situation.</p>
<p>[1] <a class="external" href="http://www.htmlhelp.com/reference/charset/">http://www.htmlhelp.com/reference/charset/</a><br />[2] <a class="external" href="http://www.cs.tut.fi/~jkorpela/www/windows-chars.html">http://www.cs.tut.fi/~jkorpela/www/windows-chars.html</a></p>
<p>(issue imported from #M2048)</p> TYPO3 Core - Bug #14914 (Closed): config.disableImgBorderAttr should override anythinghttp://forge.typo3.org/issues/149142005-08-08T14:32:13ZErnesto Baschnyeb@cron.eu
<p>The fix added to 3.8.0 for <a class="external" href="http://bugs.typo3.org/view.php?id=797">http://bugs.typo3.org/view.php?id=797</a> had a bug in that the disableImgBorderAttr was checked wrongly. Now there is a fix for it in CVS, but it still isn't right:</p>
<p>class.tslib_content.php, line 2518:</p>
<pre><code>if (!t3lib_div::inList('xhtml_strict,xhtml_11,xhtml_2',$GLOBALS['TSFE']->config['config']['doctype']) || !$GLOBALS['TSFE']->config['config']['disableImgBorderAttr']) {<br /> return $borderAttr;<br /> }</code></pre>
<p>I would like the disableImgBorderAttr attribute to override any other setting, so that I could turn off the border-tags even if my doctype is xhtml_trans. This is not possible. A simple solution would be to change the logic in the test from OR (||) to AND (&&).</p>
<p>(issue imported from #M1360)</p>