TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692023-10-13T16:22:35ZTYPO3 Forge
Redmine TYPO3 Core - Bug #102167 (Resolved): Workspace Module: Icon Overlay not being displayed in table ...http://forge.typo3.org/issues/1021672023-10-13T16:22:35ZErnesto Baschnyeb@cron.eu
<p>Until TYPO3 v11 the table of the workspace module showing the changes made to tables also reflected the status of the page with it's icon.</p>
<p>Since change <a class="issue tracker-4 status-5 priority-4 priority-default closed" title="Task: Use native icons for workspaces element (Closed)" href="http://forge.typo3.org/issues/94977">#94977</a>, you only see the icon based on the page type, so it does not reflect anymore any status changes (i.e. from Shortcut to normal page, from hidden to non-hidden, etc).</p>
<p><strong>In TYPO3 v10:</strong><br /><img src="http://forge.typo3.org/attachments/download/38016/workspace-v10.png" loading="lazy" style="width:600px;" alt="" /></p>
<p><strong>Since TYPO3 v11:</strong><br /><img src="http://forge.typo3.org/attachments/download/38017/workspace-v11.png" loading="lazy" style="width:600px;" alt="" /></p> 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 #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 #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 #12385 (Closed): Conflict scheduler:testtask with linkvalidator::taskhttp://forge.typo3.org/issues/123852011-01-20T00:58:01ZErnesto Baschnyeb@cron.eu
<p>Please consider this report, and check if its really valid. If so, please rename the field, would be the easiest option:</p>
<p><a class="external" href="http://bugs.typo3.org/view.php?id=17152">http://bugs.typo3.org/view.php?id=17152</a></p> TYPO3 Core - Bug #12079 (Closed): Not possible to reactivate t3editor after deactivationhttp://forge.typo3.org/issues/120792011-01-10T22:21:26ZErnesto Baschnyeb@cron.eu
<p>When I de-select the checkbox "Deactivate t3editor" which is shown below the Info/Modify form of SETUP (or CONSTANT), there is no way of getting it back "active". If I unselect that checkbox again and SAVE, it is again activated as soon as I enter that form again.</p>
<p>This happens on 4.4 and current trunk. Would be cool to have that fixed for the 4.5.0 final release.</p> TYPO3 Core - Bug #12000 (Closed): Topbar: Cache and Favorites submenus shifts when in Workspaceshttp://forge.typo3.org/issues/120002011-01-07T18:44:03ZErnesto Baschnyeb@cron.eu
<p>Hi,</p>
<p>in Live mode, the Cache (and Favorites) submenu is positioned correctly:</p>
<p><img src="http://forge.typo3.org/attachments/download/4885/clear-cache-live-position.png" alt="" loading="lazy" /></p>
<p>As soon as you switch to a Draft Workspace (thus getting the dashed top bar), the position of the submenu is wrong:</p>
<p><img src="http://forge.typo3.org/attachments/download/4886/clear-cache-ws-position.png" alt="" loading="lazy" /></p>
<p>It seems that it shifts exactly the size of the Workspace name which is added on the top bar:</p>
<p><img src="http://forge.typo3.org/attachments/download/4887/clear-cache-ws-position-2.png" alt="" loading="lazy" /></p> TYPO3 Core - Bug #15305 (Closed): RemoveFormat destroys the HTML sometimeshttp://forge.typo3.org/issues/153052005-12-22T15:49:37ZErnesto Baschnyeb@cron.eu
<p>Due to a bug in a RegExp, sometimes applying the RemoveFormat to remove HTML- or Word-formatting you end up with non-valid HTML code.</p>
<p>The attached patch (rtehtmlarea-eb.diff) corrects this issues and additionally also removes cellpadding, cellspacing, frame and bgcolor attributes, which are used to style tables (I expect them to disappear if I choose to "remove formatting" so that I can style them in CSS or using classes provided by the RTE).</p>
<p>Try the attached HTML fragment (rtehtmlarea-removeformatbug.html) in a rtehtmlarea (paste it in "text" mode). You will see the problem "in action". Just remove format and select HTML-formatting and Word-Formatting. You end up with "<tdspan3>" tags and other bizarre things).</p>
<p>After applying the patch, you will get a "clean" output after using the removeformat function, as expected.<br />(issue imported from #M2084)</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 #15197 (Closed): XHTML compliance of indexed_searchhttp://forge.typo3.org/issues/151972005-11-10T19:04:29ZErnesto Baschnyeb@cron.eu
<p>In CVS indexed_search now has templating support, which is very powerful. There is an example pi/template_css.tmpl included, which says in the headers to be "XHTML 1.0 Transitional", but its not even that. Its probably just HTML 4 Trans, with some minor bugs.</p>
<p>As we want TYPO3 4.0 (where this will be included) to be as much XHTML-compliant as possible, I have created a patch to this template file to add full XHTML 1.1 compliancy for indexed_search. This includes some minor patches to the class file as well.</p>
<p>Attached patch is for current CVS version of indexed_search with changes up to 2005-10-28.</p>
<p>Note that accessibility is not yet being considered here, as its still all constructed with tables. Later an accessible template should be created.</p>
<p>Also note that all this obsoletes bug report <a class="external" href="http://bugs.typo3.org/view.php?id=619">http://bugs.typo3.org/view.php?id=619</a>, as that issue is no longer relevant, as far as I can see.<br />(issue imported from #M1830)</p> TYPO3 Core - Bug #14984 (Closed): Editpanel confirm dialogs (del/hide) don't display umlauts/etchttp://forge.typo3.org/issues/149842005-09-21T12:57:08ZErnesto Baschnyeb@cron.eu
<p>The edit panel has a hide and delete buttons that open a javascript confirmation dialog. This works nice in englisch, but if the user has set the BE-language to a language that uses non-ascii chars in these strings (e.g. german), the confirmation dialogs appear with these characters displayed as URL-encoded UTF-8 entities.</p>
<p>The problem is that javascript dialogs doesn't support URL-encoded strings and not even UTF-8 entities.</p>
<p>The attached patch solves the problem, and allows us to display the confirmation prompts with umlauts etc. The solution is:</p>
<p>1) t3lib_tsfebeuserauth::extGetLL has a new parameter, allowing us to return the string in the default charset that the BE-user is using (instead of UTF-8 entities)<br />2) In tslib_content::editPanel we now get the strings for "hideConfirm" and "deleteConfirm" using this new parameter<br />3) In tslib_content::editPanelLinkWrap the $confirm parameter goes through $GLOBALS['LANG']->JScharCode() to get properly encoded and displayed in the dialog.</p>
<p>The attached patch was created for current CVS-head, but also applies to TYPO3 3.8.0 nicely.<br />(issue imported from #M1472)</p> TYPO3 Core - Bug #14921 (Closed): XHTML and accessibility of FORM cObjhttp://forge.typo3.org/issues/149212005-08-11T18:06:39ZErnesto Baschnyeb@cron.eu
<p>The cObj FORM currently doesn't render accessible mailforms, even if setting "accessible=1" in its conf. In a discussion in TYPO3-content-rendering mailing list (6.6.2005), ben van't ende proposed a patch, which can be found here:</p>
<p><a class="external" href="http://typo3.org/teams/content-rendering/get-the-x-into-html/">http://typo3.org/teams/content-rendering/get-the-x-into-html/</a></p>
<p>This hasn't been incorporated into CVS yet. I found some bugs in this implementation and added some enhancements, so we could apply it to CVS and have it included in 3.8.1.</p>
<p>What ben's patch solve:</p>
<p>- Added: FORM conf variable: fieldPrefix where we can set a prefix to use for all fields in this form (instead of the default "formName", which is probably an unique-hash).<br />- Added: FORM conf variable: dontMd5FieldNames where we can decide not to md5 the field names in the id fields.<br />- Fixed: generates one ID for each option on radio-fields, instead of reusing the same ID (generating invalid XHTML).<br />- Fixed: In strict XHTML mode, set the FORM ID instead of the NAME attribute.</p>
<p>My additions to ben's patch were:</p>
<p>- Added: In "accessibility" mode, we need to create a <fieldset> for the radio-buttons, so we have an ID to which the LABEL refers to. Else we end up with invalid XHTML (reference to unknown id). This is also the most "accessible" way (the field-label refers to the whole group of radio-buttons).<br />- Added: In radio-buttons, the descriptive text after the radio-button is the LABEL for this specific button. So this will now wrap a <LABEL> tag around the text with the correct ID (so one can click on the text next to the radio-buttons to activate them). Only in accessibilty=1.<br />- Fixed: Check for ctype_digit in formname before generating the prefix, else we might end up having a digit as the first character of the prefix.<br />- Fixed: ben's patch wouldn't work with accessible=0 (generates invalid XHTML).<br />- Fixed: On form elements of type "label", there is no element with an ID, so we should not create a LABEL-tag pointing to an ID that does not exist (generates invalid XHTML).</p>
<p>Attached is a patch that includes ben's and my additions. Read to be included in CVS for 3.8.1 (no change in features, just adds options).</p>
<p>This patch also applies to 3.8.0, for the interested reader! :)</p>
<p>(issue imported from #M1369)</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> TYPO3 Core - Bug #14601 (Closed): XHTML compliance of GMENU with onmouseover imageshttp://forge.typo3.org/issues/146012005-03-08T13:11:59ZErnesto Baschnyeb@cron.eu
<p>Currently a GMENU is transformed into links like:</p>
<p><a onmouseover="over('...')" onmouseout="over('...')" href="..."><img name="..." .../></a></p>
<p>The problem is the "name" attribute in the <img> tag, which is not allowed in XHTML 1.1. The proper replacement is the "id" attribute.</p>
<p>But replacing this breaks the over() and out() JavaScript functions (at least on IE).</p>
<p>So the solution is to:</p>
<p>- use 'id' instead of 'name' in tslib/class.tslib_menu.php<br />- fallback to getElementById(name) in the generated javascript, so that IE will find the img we are referring to</p>
<p>Attached is a patch on the current (8.3.2005) CVS HEAD with these changes.</p>
<p>(issue imported from #M874)</p> TYPO3 Core - Bug #14491 (Closed): XHTML 1.0 strict compliance of FORM objects (hidden fields)http://forge.typo3.org/issues/144912005-01-13T13:41:15ZErnesto Baschnyeb@cron.eu
<p>FORM objects generate hidden fields that are not enclosed by any other block-level tags. This is not legal according to XHTML 1.0 strict, so e.g. pages with a mailform content object fail to validate. Attached is a patch to solve this problem (it just adds a <div> around the hidden fields block).</p>
<p>(issue imported from #M678)</p>