TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692023-04-21T14:27:30ZTYPO3 Forge
Redmine TYPO3 Core - Bug #100707 (New): Web>List only applies list_type restriction if this column is sho...http://forge.typo3.org/issues/1007072023-04-21T14:27:30ZErnesto Baschnyeb@cron.eu
<p>The ACL <code>explicit_allowdeny</code> allows to restrict an editor to certain plugin types (field <code>list_type</code>):</p>
<p><img src="http://forge.typo3.org/attachments/download/37635/acl-list-type.png" alt="" loading="lazy" /></p>
<p>If an admin creates a plugin of a certain list_type which is not allowed by the editor, in Web>List module the editor will still see the "controls" which would allow him to edit this content element:</p>
<p><img src="http://forge.typo3.org/attachments/download/37636/web-list-buggy.png" alt="" loading="lazy" /></p>
<p>As soon as the user also shows the column <code>list_type</code>, the permission check works and he does not see the icons anymore:</p>
<p><img src="http://forge.typo3.org/attachments/download/37637/web-list-ok.png" alt="" loading="lazy" /></p>
<p>The bug most probably came from the optimizations done in Web>List in <a class="external" href="https://review.typo3.org/c/Packages/TYPO3.CMS/+/68666">https://review.typo3.org/c/Packages/TYPO3.CMS/+/68666</a> - the $row which is passed on to DatabaseRecordList::makeControl and then later to BackendUserAuthentication::recordEditAccessInternals() no longer is the full row, but just a basic version of it + the fields select by the user in the backend. So <code>list_type</code> is missing, and this auth-check is then no longer performed.</p> TYPO3 Core - Bug #56951 (Closed): New page wizard broken tree lineshttp://forge.typo3.org/issues/569512014-03-16T02:16:07ZErnesto Baschnyeb@cron.eu
<p>The new page wizard (URL like /typo3/db_new.php?id=xx&pagesOnly=1) looks ugly.</p>
<p>Reas is because there is a mix of new styled t3-tree 30px high tree lines, and not yet reworked "halfline.gif".</p>
<p>Solution would be to include also a higher "halfline.gif" in the new t3-treeline sprite (typo3/sysext/t3skin/images/icons/treeline/) and make use of this new markup in this wizard.</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 #53652 (Closed): New element wizard broken tree lineshttp://forge.typo3.org/issues/536522013-11-15T00:24:08ZErnesto Baschnyeb@cron.eu
<p>In <a class="issue tracker-4 status-5 priority-4 priority-default closed child" title="Task: Replace table structure in new element wizard (Closed)" href="http://forge.typo3.org/issues/49603">#49603</a> the html and css of the "new element wizard" was refactored (Web>List, "Create New Record"). This broke the tree lines layout because it added some gaps between the segments.</p>
<p>Before:</p>
<p><img src="http://forge.typo3.org/attachments/download/25500/db_new-tree-orig.png" alt="" loading="lazy" /></p>
<p>Now:</p>
<p><img src="http://forge.typo3.org/attachments/download/25501/db_new-tree-buggy.png" alt="" loading="lazy" /></p>
<p>This needs to be fixed</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 #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 #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 #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 #17412 (Closed): parseFunc tags.XXX for single tags doesn't workhttp://forge.typo3.org/issues/174122007-06-22T16:58:39ZErnesto Baschnyeb@cron.eu
<p>parseFunc "tags" doesn't work if the tag is a single tag which has attributes. E.g. the following:</p>
<p>lib.parseFunc_RTE {<br /> tags.img = TEXT<br /> tags.img {<br /> current = 1<br /> case = upper<br /> }<br />}</p>
<p>Won't handle: <img src="..." ... /><br />Will handle: <img/><br />Will handle: <img src="..." ...></img></p>
<p>So currently one cannot write a parseFunc for such an img tag.</p>
<p>This can be used for example for the click-enlarge rendering of images embedded in RTE, as Stanislau alterady added to rtehtmlarea code a year ago, but marked as "EXPERIMENTAL" because of this core bug. See related bug report <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Click-enlarge for Images (Closed)" href="http://forge.typo3.org/issues/14605">#14605</a><br />(issue imported from #M5841)</p> TYPO3 Core - Bug #15510 (Closed): UTF-8 sites display garbled chars in select-fields (in BE)http://forge.typo3.org/issues/155102006-01-26T16:50:33ZErnesto Baschnyeb@cron.eu
<p>Steps to reproduce (TCEforms):</p>
<p>1) Set forceCharSet = utf-8.<br />2) Login to the backend, create a usergroup called "ÄÄÄ" (or any other non-ascii-char)<br />3) Create a user and add the group to the user (clicking on the right box). Upon adding, the group-name is add correctly to the left box.<br />4) Save the form and look at the result. Instead of "ÄÄÄ" you have a 6 bytes-string</p>
<p>Other place where it occurs (flexforms):</p>
<p>1) Set forceCharSet = utf-8.<br />2) Add tt_news extension<br />3) Create a News Category called "ÖÖÖ" <br />4) Add a News-Plugin as a content element, and tell it to display only elements in the category "ÖÖÖ".<br />5) Save and look at the displayed value in the left category box, its garbled again.</p>
<p>The attached minor patch (to latest 4.0-CVS) seems to solve it. But I think more thinking has to be done here.</p>
<p>The only change the patch does is that LANG->sL() won't try to convert from the encoding specified for the current users language (e.g. iso-latin-1) to UTF-8. In the case of values coming from the DB, they are already UTF-8, so this would cause double-encoding.</p>
<p>There might be side-effects, because sL() is also used for the "language-splitted" labels, but they are obsolete anyway. And I cannot imagine any latin-1 encoded string to enter this part of the function if the site is set to forceCharSet=utf8.</p>
<p>Non-forceCharSet-sites aren't affected by this change, because hscAndCharConv won't don anything other than htmlspecialchars, which I still do in my change.</p>
<p>Initially reported for TYPO3 4.0<br />(issue imported from #M2396)</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>