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 - 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 #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 #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>