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 - Feature #12344 (Closed): Migrate to t3lib_htmlmail to SwiftMailerhttp://forge.typo3.org/issues/123442011-01-18T09:09:06ZErnesto Baschnyeb@cron.eu
<p>We have a new Mailer API in 4.5 based on SwiftMailer and we want to deprecate the use of t3lib_htmlmail. Which means we need to get rid of it all together.</p>
<p>Attached is an untested patch of what this would mean more or less for "linkvalidator". Please take a look at it, test it, and integrate that solution for the RC1 if possible.</p>
<p>See pending documentation at <a class="external" href="http://wiki.typo3.org/Pending_Documentation#t3lib_mail">http://wiki.typo3.org/Pending_Documentation#t3lib_mail</a></p>
<p>Thanks!</p> TYPO3 Core - Feature #12340 (Closed): Enhance the tx_linkvalidator_linkTypes_Interfacehttp://forge.typo3.org/issues/123402011-01-17T23:28:02ZErnesto Baschnyeb@cron.eu
<p>The tx_linkvalidator_linkTypes_Interface currently only requires the method "checkLink()".</p>
<p>But the processor and the module also calls these methods on the hook objects:</p>
<p>- getErrorParams()<br />- fetchType()<br />- getBrokenUrl()</p>
<p>So these need to be added to the interface to make sure they are available.</p>
<p>- setErrorParams() (from the abstract class) doesn't seem to be part of that interface, so make that method "protected"</p>
<p>Also make sure that all members of these subclasses are "protected" (i.e. in tx_linkvalidator_linktypes_external = $url_reports + $url_error_params and tx_linkvalidator_linkTypes_LinkHandler = $tsconfig).</p>
<p>That would be important to have a stable and reliable API!</p>
<p>Thanks!</p>
<p>Cheers,<br />Ernesto</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 #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 - Feature #14894 (Closed): stdWrap.age should differenciate between singular/pluralhttp://forge.typo3.org/issues/148942005-08-02T13:39:17ZErnesto Baschnyeb@cron.eu
<p>The .age stdWrap parameter currently only allows us to specify " min| hrs| days| yrs", which will also show plural text if we have a quantity of "1". The attached patch (for typo3/sysext/cms/tslib/class.tslib_content.php) changes the possible value of the .age setting to allow 8 values:</p>
<p>" min| hrs| days| yrs| min| hour| day| year"</p>
<p>The second set is the singular variant. So we can have outputs like "1 hour" and "1 year". It remains backwards compatible, in that older TYPO3 (with newer TypoScript) will still show the "good-old" plural variants.</p>
<p>In a remote future this text should become language-dependent, so that we have different outputs depending on the language of the site. This should also be prepared for situations where not always is the "1" unit singular and all others plural. There are languages where there are other rules for plurals (see gettext, PO-setting "Plural-Forms").<br />(issue imported from #M1333)</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> TYPO3 Core - Feature #14886 (Closed): stdWrap for TMENUITEM's ATagParamshttp://forge.typo3.org/issues/148862005-07-29T15:55:41ZErnesto Baschnyeb@cron.eu
<p>Currently the ATagParams of a TMENUITEM is just a string. But sometimes you want to do fancy stuff with this information, like e.g:</p>
<pre><code>ATagParams = accesskey="{field:tx_govaccesskey_accesskey}" tabindex="{field:tx_govaccesskey_tabindex}"</code></pre>
<p>This doesn't work right now, because the ATagParams is not going through stdWrap.</p>
<p>So this feature-request, which is already implemented using the attached patch (for 3.8-release), simply passes the ATagParam through stdWrap if there are stdWrap properties. With this patch applied, this would allow something like:</p>
<pre><code>ATagParams = accesskey="{field:tx_govaccesskey_accesskey}" tabindex="{field:tx_govaccesskey_tabindex}" <br /> ATagParams.insertData = 1</code></pre>
<p>(issue imported from #M1320)</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>