TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692011-10-07T16:38:07ZTYPO3 Forge
Redmine TYPO3 Core - Bug #30631 (Closed): RTE doesn't allow to create links around images in IE8http://forge.typo3.org/issues/306312011-10-07T16:38:07ZErnesto Baschnyeb@cron.eu
<p>If you have images in your RTE, IE8 users cannot link this image to other pages. The browse_links popup opens up, but when clicking on any page in the tree, the tree just reloads and we have javascript error in the console (property or method not supported), pointing to the range.getBookmark() method here:</p>
<pre><code>HTMLArea.Editor.prototype.getBookmark = function (range) {<br /> return range.getBookmark();<br /> };</code></pre> TYPO3 Core - Bug #29234 (Closed): RTE only loads TD styles from external css file on reloadhttp://forge.typo3.org/issues/292342011-08-24T21:23:35ZErnesto Baschnyeb@cron.eu
<p>Hi,</p>
<p>I want to enable Table-Cell styles in RTEhtmlarea. It works great, but I have problems with IE8. Here's the setup:</p>
<p>TYPO3 4.5.5<br />PageTS:</p>
<pre><code>RTE.default {<br /> contentCSS = fileadmin/contentRTE.css<br /> classesTD := addToList(highlight-blue)<br />}</code></pre>
<p>fileadmin/contentRTE.css contains:</p>
<pre><code>TD.highlight-blue { background-color: #003399; color: #ffffff; font-weight: bold; }<br />TD.align-left { text-align: left; }<br />TD.align-center { text-align: center; }<br />TD.align-right { text-align: right; }</code></pre>
<p>Now everything works as expected in FF and Chrome. In IE8, on first loading of an editing Form, I get these CSS loaded (shown in the F12 - developer tools):</p>
<p><img src="http://forge.typo3.org/attachments/download/18493/rte-table-styles-01-first-load.png" alt="" loading="lazy" /></p>
<p>The RTE displays the list of available TD classes like this. Not even "Justify Left" etc are shown!</p>
<p><img src="http://forge.typo3.org/attachments/download/18494/rte-table-styles-02-first-load-rte.png" alt="" loading="lazy" /></p>
<p>Then I simply <strong>reload</strong> the frame where the RTE is located. The CSS list is now this:</p>
<p><img src="http://forge.typo3.org/attachments/download/18495/rte-table-styles-03-reload.png" alt="" loading="lazy" /></p>
<p>And the RTE works as expected:</p>
<p><img src="http://forge.typo3.org/attachments/download/18496/rte-table-styles-04-reload-rte.png" alt="" loading="lazy" /></p>
<p>Of course I cannot tell the editor to keep reloading the editing frame before beginning, so I would love to see this fixed.</p>
<p>If an environment is required to reproduce, please let me know. I was able to transfer the above scenario from one very complex installation to a simple and and reduced the test-bed to simple the above shown, so it should be simple to test.</p> TYPO3 Core - Bug #24873 (Closed): Open forms cannot be saved after "Relogin" (Security Token errors)http://forge.typo3.org/issues/248732011-01-28T11:17:58ZErnesto Baschnyeb@cron.eu
<p>If you have an open form (e.g. editing a content element) and you leave your browser unattended until "session expires", you can relogin with the popup window (or the JS overlay).</p>
<p>After this relogin, if you try to save your work, you will get security token errors.</p>
<p>The CSRF protection token is in a hidden field, and if the session has expired in the meantime, the session data (including the original tokens) are gone, so when saving that form after the relogin won't be able to validate them. Different potential solutions:</p>
<p>a) go through the DOM and manipulate all hidden fields with a token and change them with a new valid token. doable, but will require some work<br />b) allow "one save without token check" right after the relogin, so that this form can be finally saved, and after that things continue as usual.</p>
<p>(issue imported from #M17383)</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 #24268 (Closed): Install Tool is unuseable with newest DBALhttp://forge.typo3.org/issues/242682010-12-01T20:56:46ZErnesto Baschnyeb@cron.eu
<p>See <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Install Tool is unuseable since DBAL merge (switches to a very ugly "123" mode) (Closed)" href="http://forge.typo3.org/issues/24267">#24267</a>, has been fixed in core's trunk already. Please port the fix to the extension!</p>
<p>(issue imported from #M16640)</p> TYPO3 Core - Bug #24057 (Closed): Install tool cannot compare "ENGINE" of MySQL Tables when DBAL ...http://forge.typo3.org/issues/240572010-11-15T11:23:11ZErnesto Baschnyeb@cron.eu
<p>In core rev. 3365 (2008, was included in 4.2beta3), Stucki implemented a way of the Install Tool "COMPARE DATABASE" to change the Engine of a database. This does not work with DBAL enabled, because that change in t3lib_db was not ported to DBAL.</p>
<p>You end up with the same suggestions over and over again (to change Engine to "InnoDB" while the tables are already InnoDB).</p>
<p>(issue imported from #M16392)</p> TYPO3 Core - Bug #23383 (Closed): Not able to select multiple records in recycler since refactoringhttp://forge.typo3.org/issues/233832010-08-16T13:40:00ZErnesto Baschnyeb@cron.eu
<p>Since issue <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Refactor of recycler (Closed)" href="http://forge.typo3.org/issues/20967">#20967</a> was commited (rev. 8606), we are no longer able to select multiple records on the left side (checkboxes).</p>
<p>(issue imported from #M15467)</p> TYPO3 Core - Bug #22780 (Closed): Web>List: Turning "Extended view" on makes rows growhttp://forge.typo3.org/issues/227802010-05-31T18:43:29ZErnesto Baschnyeb@cron.eu
<p>When turning "Extended view" on in list view will change the height of the individual data rows. Thus the icon that you just clicked to turn Extended view on is shifted downwards and more space is consumed on the screen.</p>
<p>My idea would be to leave the row height as it was before. An padding:2px around the div.typo3-DBctrl caused the grown.</p>
<p>Solution is to remove this padding. :)</p>
<p>See attached screenshots before and after the patch<br />(issue imported from #M14559)</p> TYPO3 Core - Bug #22651 (Closed): phtml is also PHP extension and should be denied editing / uplo...http://forge.typo3.org/issues/226512010-05-14T21:00:35ZErnesto Baschnyeb@cron.eu
<p>Most Linux distributions with PHP enabled will add handling of .phtml files through PHP module:</p>
<pre><code>AddType application/x-httpd-php .php .phtml .php3</code></pre>
<p>This is currently not in the list of denied files (in PHP_EXTENSIONS_DEFAULT of t3lib/config_default.php).</p>
<p>This means uploading a .phtml file through File manager will make it executeable.</p>
<p>Solution is to add this extension to the list.</p>
<p>Same applies to v4.2 and v4.3.<br />(issue imported from #M14389)</p> 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 - 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 #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 #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 #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>