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 - Epic #54542 (Closed): WP: Importer / Exporter with relations MM/IRRE/FALhttp://forge.typo3.org/issues/545422013-12-20T21:49:35ZErnesto Baschnyeb@cron.eu
<p>The import and export functionality is available since the beginning of TYPO3 CMS. This backend module mostly relies on the internal DataHandler/TCEMain system of TYPO3. For TYPO3 6.2 LTS, the Core Team needs to improve the handling of the IRRE and MM relations within the import and export process.<br />Additionally, the import / export module must be able to handle exports which were generated in a pre-FAL-version of TYPO3 (e.g. like the last LTS Version 4.5) in order to be able to import directly to the FAL.<br />Since importing and exporting large sites via a web-backend leads to problems in runtime and memory limits, a CLI Module must be added.</p>
<p>Epic for the work-package dealing with fixes in the Importer/Exporter module for inclusion in TYPO3 6.2 LTS.</p>
<p>Please do not add sub-tasks to this on your own, instead contact the release manager (Ernesto) before.</p> TYPO3 Core - Epic #54260 (Closed): WP: FAL Missing Issues / Features / APIhttp://forge.typo3.org/issues/542602013-12-07T14:56:05ZErnesto Baschnyeb@cron.euTYPO3 Core - Bug #24784 (Closed): Workspaces module get place on "top" of all moduleshttp://forge.typo3.org/issues/247842011-01-25T01:12:26ZErnesto Baschnyeb@cron.eu
<p>After uninstalling the new sysext "info", the Workspaces module is on the first position of the modules menu (even before "Web>Page").</p>
<p>Since we moved several old hardcoded modules to sysext, they can also be uninstalled. Some extensions place their backend modules using the t3lib_extMgm::addModule() call and setting the $position parameter to one of these old hardcoded extensions.</p>
<p>E.g. the workspaces module registers himself for "before:info". So if "info" is not installed, the default would be to be placed "at the end". This is even documented in the method addModule(), but it doesn't work.</p>
<p>This is related to <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: New sysext modules are placed incorrectly in the Web> module menu (Closed)" href="http://forge.typo3.org/issues/24271">#24271</a> and a follow-up after this fix was applied: <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: New sysext modules are placed incorrectly in the Web> module menu (Closed)" href="http://forge.typo3.org/issues/24271">#24271</a><br />(issue imported from #M17282)</p> TYPO3 Core - Bug #24115 (Closed): When dbal is activated, styles.content.get (and others) doesn't...http://forge.typo3.org/issues/241152010-11-18T01:30:11ZErnesto Baschnyeb@cron.eu
<p>tslib_content was using the method ->sql_query, which is only supported experimentally by dbal. Get rid of it!</p>
<p>(issue imported from #M16456)</p> TYPO3 Core - Bug #23499 (Closed): XHTML validity of backend when sys_action is loadedhttp://forge.typo3.org/issues/234992010-09-03T19:51:05ZErnesto Baschnyeb@cron.eu
<p>sys_action is able to generate links for the backend.php toolbar. The links with a href and "&" parameters, but this is not properly escaped (htmlspecialchars missing).</p>
<p>Solution is to escape the links, so that that part gets XHTML valid.</p>
<p>Problem is there since 4.3 where the toolbar was added.<br />(issue imported from #M15635)</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 #21332 (Closed): XSS in alt_palettehttp://forge.typo3.org/issues/213322009-10-22T10:28:47ZErnesto Baschnyeb@cron.eu
<p>BE authentication required to exploit the vulnerability</p>
<p>TYPO3 Security Team OTRS reference: #2009061610000068<br />(issue imported from #M12307)</p> TYPO3 Core - Bug #21331 (Closed): XSS in module dispatcherhttp://forge.typo3.org/issues/213312009-10-22T10:21:39ZErnesto Baschnyeb@cron.eu
<p>BE authentication required to exploit the vulnerability</p>
<p>TYPO3 Security Team OTRS reference: #2009061610000068<br />(issue imported from #M12306)</p> TYPO3 Core - Bug #21329 (Closed): XSS in alt_mod_framesethttp://forge.typo3.org/issues/213292009-10-22T10:08:40ZErnesto Baschnyeb@cron.eu
<p>BE authentication required to exploit the vulnerability</p>
<p>TYPO3 Security Team OTRS reference: #2009061610000068 <br />(issue imported from #M12304)</p> TYPO3 Core - Bug #21328 (Closed): XSS vulnerability due to not proper sanitizing in function t3li...http://forge.typo3.org/issues/213282009-10-22T09:56:11ZErnesto Baschnyeb@cron.eu
<p>Reported by Andreas Schnapp.</p>
<p>Added missing escaping of the first parameter. Better description (and name) of the usage of parameter #2.</p>
<p>Reported by Andreas Schnapp</p>
<p>Security Team OTRS reference: 2009060910000027 <br />(issue imported from #M12303)</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 #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> 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>