TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692008-01-21T09:33:31ZTYPO3 Forge
Redmine TYPO3 Core - Bug #18034 (Closed): Selecting words with CTRL+SHIFT+Left doesn't activate "link" bu...http://forge.typo3.org/issues/180342008-01-21T09:33:31ZErnesto Baschnyeb@cron.eu
<p>I usually select words with the keyboard using the CTRL+SHIFT+Cursor-right (or left). This jumps the cursor to the next word boundary, and also selects it.</p>
<p>Unfortunately this doesn't activate the "link" button in the toolbar. Only when I then stop pressing CTRL and move cursor left or right (with just SHIFT pressed) the link button is activated. It also happens when I choose a second word (e.g. two times CTRL+SHIFT+RIGHT).</p>
<p>(issue imported from #M7232)</p> TYPO3 Core - Bug #17653 (Closed): Palettes are not rendered correctly on nesting records using th...http://forge.typo3.org/issues/176532007-10-04T21:17:51ZErnesto Baschnyeb@cron.eu
<p>I don't know what exactly makes this happen, but at least it is reproducible:</p>
<p>For some strange reason we needed to order news in a parent / child way. Nothing better than IRRE to do that:</p>
<p>- added two fields to tt_news, one for the "inline" type holding the children and one to hold the uid of the "parent" news</p>
<p>Now here comes the bug:</p>
<p>- Whenever there are children records in my tt_news record, the "keyword" pallete is empty! If "show secondary palettes" is enabled, I don't see the keywords at all (should be directly below bodytext). If I disable that option I get the icon for "secondary palette", but clicking on it gives me an empty palette.</p>
<p>To make it easier to test (go, Oliver, go!), I've made a little extension that just adds that inline fields needed to test this behaviour.</p>
<p>I also had some other "palette" related trouble in the course of our developement with this constelation (parent / child tt_news records), but this "keywords" thing is the only thing I could reproduce. Maybe fixing this fixes all related problems. :)<br />(issue imported from #M6456)</p> TYPO3 Core - Feature #17568 (Closed): Hook request for Web>Page plugin "additional info" displayhttp://forge.typo3.org/issues/175682007-08-30T10:24:00ZErnesto Baschnyeb@cron.eu
<p>In the Web>Page, Columns view, each tt_content element of type "list" (plugins) are displayed with the text:</p>
<p>Extension: <plugin name><br />CODE: <select_key field content></p>
<p>The select_key is not being used anymore by the majority of extensions, which now usually opt to use pi_flexform for storing setup configuration. So it would be nice to be able to display some other information instead of "CODE:".</p>
<p>The proposed hook provides enough flexibility so that extensions can display whatever they want on that place for their plugins (some setup from flexform, maybe even a list of records which will be displayed, or whatever else might be interesting in this overview).</p>
<p>(issue imported from #M6237)</p> TYPO3 Core - Bug #17531 (Closed): Offered AllowClipboard helper doesn't work with 2.0.0.x Firefoxhttp://forge.typo3.org/issues/175312007-08-15T10:06:32ZErnesto Baschnyeb@cron.eu
<p>When trying to copy some text from rtehtmlarea in Firefox, the browsers security policy by default doesn't allow it. rtehtmlarea can trigger the installation of a plugin which enables allowing this behaviour for certain domains (e.g. TYPO3 backends).</p>
<p>The current offered version is 0.5.3, which works only with Firefox until version 1.5.x. The "new" 0.5.5 also works with Firefox 2.0.0.x.</p>
<p>The add-on is on <a class="external" href="https://addons.mozilla.org/en-US/firefox/addon/852">https://addons.mozilla.org/en-US/firefox/addon/852</a><br />Old version is 0.5.3. New version is 0.5.5. The default URL has to be changed in ext_conf_template.txt and ext_localconf.php<br />(issue imported from #M6152)</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 #16514 (Closed): Respect label_alt setting in some more places (group with forei...http://forge.typo3.org/issues/165142006-08-31T12:42:54ZErnesto Baschnyeb@cron.eu
<p>A table in $TCA can have a 'label', 'label_alt' and 'label_alt_force'<br />settings [1], which configure a representative label for a single row in<br />this table. This is useful for example if you have fields "last_name" <br />and "first_name" but "last_name" alone isn't enough to represent the row<br />(e.g. "Müller" in Germany).</p>
<p>This is used in many places in the Core already, and the API to get this<br />done is t3lib_BEfunc::getRecordTitle(). But there are still some places<br />where this isn't being used.</p>
<p>Solution:</p>
<p>Calling the API to get the label instead of getting it from the field<br />'label' alone. Also we have to make sure we have the 'label' and<br />'label_alt' fields in the $row record before calling the API, else it<br />won't work.</p>
<p>Attached patch fixes the following places:</p>
<p>a) A field of type 'group' that points to a 'foreign_table'. In the<br />select-box only the 'label' of the pointed to records is displayed<br />(t3lib/class.t3lib_tceforms.php)</p>
<p>b) When adding more elements to such a 'group' field, the new labels<br />also doesn't respect the label_alt stuff (typo3/class.browse_links.php)</p>
<p>c) In Web>List, displaying a field that is configured as "MM" and points<br />to a table that has label_alt/label_alt_force settings.<br />(t3lib/class.t3lib_befunc.php). The patch also changes the separator<br />between record-labels from "," to ";", because a "," will be used to<br />separate a potential multi-field label_alt setting.</p>
<p>d) The patch also fixes the label generated by<br />t3lib/class.t3lib_loaddbgroup.php, which I thought was used in the<br />'group' field, but later found out that it wasn't. But I don't think it<br />will harm to have that fixed too.</p>
<p>How to test:</p>
<p>Easiest way is to add label_alt settings to existing tables. E.g.<br />install tt_news and add in exTables.php:</p>
<p>$GLOBALS['TCA']['tt_news_cat']['ctrl']['label_alt'] = 'description';<br />$GLOBALS['TCA']['tt_news_cat']['ctrl']['label_alt_force'] = TRUE;</p>
<p>Then add a news category with some description. Then add a news that<br />points to such a category and you can see a)b)c) in action (try with and<br />without the patch).<br />(issue imported from #M4131)</p> TYPO3 Core - Bug #16464 (Closed): Error message when uploading one or two files in file-browser (BE)http://forge.typo3.org/issues/164642006-08-13T11:36:52ZErnesto Baschnyeb@cron.eu
<p>Reproduce in 4.0.1 with:</p>
<p>- Create a "Text w/ images" <br />- Open the "File browser" in the field "Images:" <br />- In the file browser popup, enter exactly one or two images in "Upload Image:" (leaving at least one upload-field empty)<br />- File is uploaded, but error message appears: "No file was uploaded!"</p>
<p>This was not a problem in 4.0.0, but introduced with 4.0.1. It happens in all file-upload forms.</p>
<p>We expect an error just in case no file was uploaded at all.<br />(issue imported from #M4035)</p> TYPO3 Core - Bug #15902 (Closed): Calling PHP5-only iconv functions in PHP4http://forge.typo3.org/issues/159022006-03-27T10:58:03ZErnesto Baschnyeb@cron.eu
<p>A change in t3lib_cs that made it into RC2 (cvs diff -r 1.53 -r 1.54 t3lib/class.t3lib_cs.php) added some functions that are only available on PHP5 if the user chooses "iconv" (iconv_substr, iconv_strlen, iconv_strpos, iconv_strrpos). If using PHP4 with iconv support, I will get lots of errors:</p>
<p>Fatal error: Call to undefined function: iconv_strlen() in ....t3lib/class.t3lib_cs.php on line 1388</p>
<p>Attached patch checks if the functions are available before calling them.<br />(issue imported from #M2994)</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 - Feature #15324 (Closed): Clean-up in mailform code: more TypoScript flexibilityhttp://forge.typo3.org/issues/153242005-12-29T00:28:50ZErnesto Baschnyeb@cron.eu
<p>This relates to the changes applied by <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: XHTML and accessibility of FORM cObj (Closed)" href="http://forge.typo3.org/issues/14921">#14921</a>. This new patch enhances the features that have already been integrated into 4.0beta1 with the following:</p>
<p>The admin now can configure all tags from a mailform via TypoScript. There are now just very few tags hardcoded into PHP, mainly the tags that represent the fields for the FORM. The TypoScript code has been reorganized to be easier to understand and to adapt. The static TypoScript that comes with css_styled_content has been adapted for this.</p>
<p>- no more "accessibility=1" setting. All "accessible" settings are done just by configuring the tags and parameters in TypoScript itself. The default included TypoScript is now accessible out-of-the-box.<br />- all settings that are related to a specific element type (e.g. RADIO, SELECT, etc) are now organized into respective setting groups. See the new default static TypoScript to see what it means. But all "old" settings are still valid for backwards compatibility.<br />- the hardcoded "<label>" in accessibility-mode is now part of the TypoScript setup (labelWrap.wrap with ###ID### that gets replaced with appropriate ID). The user can override this per element-type (e.g. for LABEL type there is no <label>|</label> wrapping.<br />- labelWrap.wrap and REQ.labelWrap.wrap can now both be overridden in a specific element-type</p>
<p>Specific for RADIO-element:</p>
<p>- the user is now free to layout the radio-items appearance (used to be hardcoded to "[radio][label][br/]")<br />- static TypoScript used to have a "testform_radio" id for all radio-fieldsets, this was not only wrong, but also invalid if you have more than one radio-fieldset. Now the ID gets set correctly ("###ID###") according to the field-name.<br />- also the hardcoded "<legend>" is now part of the TypoScript setup, so it can be removed/changed/etc.</p>
<p>New settings (where XXX is the name of the element-type in UPPER-case):</p>
<p>- RADIO.item.layout with markers ###RADIO### (the radio-button) and ###RADIO_LABEL### (the corresponding label, stdWrapped in RADIO.item.labelWrap)<br />- RADIO.item.addParams with marker ###RADIO_ID### (the id of this specific item)<br />- RADIO.item.labelWrap with marker ###RADIO_ID### (the id of this specific item)<br />- XXX.addParams with marker ###ID### (the id of this field). This are attributes that will get added to the tag (input, select, textarea, ...) for this field in the FORM.<br />- XXX.labelWrap.wrap with marker ###ID### (the id of this field)<br />- XXX.REQ.labelWrap.wrap with marker ###ID### (the id of this field)</p>
<p>Obsolete (but still supported) settings and new equivalents:</p>
<p>params.xxx = XXX.addParams<br />radioWrap = RADIO.item.labelWrap<br />accessibility=1 = all accessible stuff can now be done directly in TypoScript</p>
<p>(issue imported from #M2119)</p> TYPO3 Core - Bug #15310 (Closed): PHP-Warning in shortcut-bar before DB-upgrade in 4.0beta1http://forge.typo3.org/issues/153102005-12-28T11:24:59ZErnesto Baschnyeb@cron.eu
<p>After updating the src from 3.8.1 to 4.0beta1 and just logging into the backend, I get the following warning in the alt_shortcut bar:</p>
<p>Warning: Invalid argument supplied for foreach() in /srv/www/shared/TYPO3core.CVS/typo3/alt_shortcut.php on line 630</p>
<p>because the sys_workspaces table isn't there yet.</p>
<p>The following patch avoids the warning.</p>
<p>(issue imported from #M2102)</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 - Feature #15150 (Closed): Get list of content elements for "new content" wizard from TCAhttp://forge.typo3.org/issues/151502005-10-24T23:14:28ZErnesto Baschnyeb@cron.eu
<p>We could remove the "hard-coded" content types from the "new content" wizard (cms/layout/db_new_content_el.php) and have the information about the CTypes come directly from the TCA. So we could add other CTypes to the wizard through extentions.</p>
<p>This means adding more parameters to TCA and have them being evaluated by the wizard.</p>
<p>Relates to 0001628.<br />(issue imported from #M1723)</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 - Feature #14889 (Closed): Place ADMINPANEL where I want tohttp://forge.typo3.org/issues/148892005-07-29T17:14:28ZErnesto Baschnyeb@cron.eu
<p>Currently the ADMIN-PANEL is just appended to the webpages output (even after the closing </html>. Usually this is ok, but sometimes not: Especially if we have XHTML-strict pages where layouting is controlled by CSS, the admin-panel might appear "who knows where", while also destroying the XHTML-validity, making browsers render the page "who knows how".</p>
<p>My feature-request would be a way to place the ADMIN PANEL wherever I want through TypoScript, maybe having it as a cObject, e.g.</p>
<p>page.10.marks.PANEL = ADMINPANEL</p>
<p>and then maybe have some ways to configure the admin panel in this object.</p>
<p>Good? Bad? Any objection?</p>
<p>(issue imported from #M1323)</p>