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 #101443 (Closed): Exception 'Undefined array key "pid"' after moving content in ...http://forge.typo3.org/issues/1014432023-07-25T18:53:46ZErnesto Baschnyeb@cron.eu
<a name="Preconditions"></a>
<h2 >Preconditions:<a href="#Preconditions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Any TYPO3 v11 (or later) installation</li>
<li>PHP 8.x</li>
<li>Workspaces extension enabled</li>
<li>no further extensions or configuration required</li>
</ul>
<a name="How-to-reproduce"></a>
<h2 >How to reproduce:<a href="#How-to-reproduce" class="wiki-anchor">¶</a></h2>
<ul>
<li>Create a Workspace</li>
<li>Create a page</li>
<li>Add two content elements (in LIVE mode)</li>
<li>Switch to the workspace</li>
<li>Drag & drop the first element after the second element - page will be marked as "modified" in the page tree</li>
<li>Try to add a new content element between or after these elements</li>
</ul>
<p>You get this exception:</p>
<pre><code>PHP Warning: Undefined array key "pid" in /app/packages/typo3/typo3/sysext/backend/Classes/Utility/BackendUtility.php line 3445</code></pre>
<a name="Background"></a>
<h2 >Background<a href="#Background" class="wiki-anchor">¶</a></h2>
<p>This bug was introduced with <a class="external" href="https://review.typo3.org/c/Packages/TYPO3.CMS/+/65797">https://review.typo3.org/c/Packages/TYPO3.CMS/+/65797</a></p>
<p>A potential workaround is to add the "pid" field to the list of `BackendUtilities::getCommonSelectFields` (see attached patch, which we will deploy in production to our customer to get around the problem for now). But maybe this is just hiding the real "problem". The @todos in `BackendUtilities::workspaceOL` give me a vibe that something could be fishy around here.</p> 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 #57262 (Closed): Install Tool: getFolderStatus ajax also being called in Step In...http://forge.typo3.org/issues/572622014-03-25T01:23:42ZErnesto Baschnyeb@cron.eu
<p>The Ajax calls to getFolderStatus and getEnvironmentStatus are useful to add the badges in the left menu of the Install Tool.</p>
<p>But they are also being fired when the Step Installer is running (no Left Menu).</p>
<p>It would be more stable if we would only fire these ajax calls when the Left Menu is indeed loaded and not regardless of the page you are in.</p> TYPO3 Core - Bug #56951 (Closed): New page wizard broken tree lineshttp://forge.typo3.org/issues/569512014-03-16T02:16:07ZErnesto Baschnyeb@cron.eu
<p>The new page wizard (URL like /typo3/db_new.php?id=xx&pagesOnly=1) looks ugly.</p>
<p>Reas is because there is a mix of new styled t3-tree 30px high tree lines, and not yet reworked "halfline.gif".</p>
<p>Solution would be to include also a higher "halfline.gif" in the new t3-treeline sprite (typo3/sysext/t3skin/images/icons/treeline/) and make use of this new markup in this wizard.</p> TYPO3 Core - Bug #54510 (Closed): phpunit run in Travis: Detect and fix memory leakshttp://forge.typo3.org/issues/545102013-12-19T13:55:22ZErnesto Baschnyeb@cron.eu
<p>Travis with PHP 5.3 is requiring more than 1 GB of RAM in one run since some merge and then the PHP run fails.</p>
<p>Instead of constantly increase the memory_limit when this occurs, we should investigate what exactly takes so much memory and limit that so that the test-run scales better.</p> TYPO3 Core - Bug #53891 (Closed): Upgrade Wizard "Migrate file relations" should hide itselfhttp://forge.typo3.org/issues/538912013-11-22T21:18:22ZErnesto Baschnyeb@cron.eu
<p>If there are nothing left to migrate, the Upgrade Wizard "Migrate all file relations from tt_content.image and pages.media" should hide itself. Currently this is the only Upgrade Wizard which is always shown, and this is confusing to the user.</p> TYPO3 Core - Bug #51698 (Closed): Delete sys_file entry when a file is deletedhttp://forge.typo3.org/issues/516982013-09-03T22:22:40ZErnesto Baschnyeb@cron.eu
<p>In order to keep sys_file as much in sync with the real file system as possible we should delete the relevant sys_file entry as soon as a file is deleted.</p>
<p>This is part of the "plan" in <a class="issue tracker-4 status-5 priority-4 priority-default closed parent" title="Task: Handling of deleted files in FAL (Closed)" href="http://forge.typo3.org/issues/50876">#50876</a> and should also be backported to 6.0/6.1 to keep the API straight and uniform throughout the releases.</p> TYPO3 Core - Bug #45834 (Closed): Detection of curlProxyServer settings buggy on upgrade to 6.0http://forge.typo3.org/issues/458342013-02-25T19:24:39ZErnesto Baschnyeb@cron.eu
<p>In <a class="issue tracker-2 status-5 priority-3 priority-lowest closed behind-schedule" title="Feature: Include HTTP Request2 for better HTTP handling (Closed)" href="http://forge.typo3.org/issues/28344">#28344</a> "HTTP Request2" API was included. It supports detecting old school "curlProxyServer" settings and transfer these to the "new" setting under HTTP:</p>
<pre>
$proxyParts = explode(':', $GLOBALS['TYPO3_CONF_VARS']['SYS']['curlProxyServer'], 2);
$GLOBALS['TYPO3_CONF_VARS']['HTTP']['proxy_host'] = $proxyParts[0];
$GLOBALS['TYPO3_CONF_VARS']['HTTP']['proxy_port'] = $proxyParts[1];
</pre>
<p>This code ended up in Core/Bootstrap::transferDeprecatedCurlSettings() after namespace and bootstrapification.</p>
<p>I have always set up this setting like this:</p>
<pre>
$GLOBALS['TYPO3_CONF_VARS']['SYS']['curlProxyServer'] = 'http://proxy:3128';
</pre>
<p>I guess the implementator of the transferDeprecatedCurlSettings was only thinking about the "proxy:3128" kind of syntax. I end up with:</p>
<pre>
$GLOBALS['TYPO3_CONF_VARS']['HTTP']['proxy_host'] = 'http'
$GLOBALS['TYPO3_CONF_VARS']['HTTP']['proxy_port'] = '//proxy:3128;
</pre>
<p>Other than that, I would also auto-set ['HTTP']['adapter'] to 'curl' if legacy 'curlUse' = TRUE.</p> TYPO3 Core - Bug #30636 (Closed): TCA: subtypes_addlist not being processed if the subtype_value_...http://forge.typo3.org/issues/306362011-10-07T17:32:47ZErnesto Baschnyeb@cron.eu
<a name="How-to-reproduce"></a>
<h2 >How to reproduce:<a href="#How-to-reproduce" class="wiki-anchor">¶</a></h2>
<p>Install mc_googlesitemap in TYPO3 4.5 and wonder where the referred fields from the documentation are: they are not rendered. They are supposed to appear in the content element of type "Menu/Sitemap" when you choose one of the newly introduced Subtypes "Sitemaps for Contents" or "Sitemaps for Pages".</p>
<p><img src="http://forge.typo3.org/attachments/download/19013/subtype_addlist-bug.png" title="Bug in action (extension mc_googlesitemap)" alt="Bug in action (extension mc_googlesitemap)" loading="lazy" /></p>
<a name="Background"></a>
<h2 >Background:<a href="#Background" class="wiki-anchor">¶</a></h2>
<p>Extensions can add fields to an existing table depending on a certain "subtype". E.g. Content Element of type "menu" has subtype stored in "menu_type". Extension mc_googlesitemap wants to add fields depending on the menu_type:</p>
<p>$TCA["tt_content"]["types"]["menu"]["subtype_value_field"]="menu_type";<br />$TCA["tt_content"]["types"]["menu"]["subtypes_addlist"][$_EXTKEY."_pi1"]= ...</p>
<p>This used to work fine since 4.4, but in 4.5 the "menu_type" field is now inside a palette, so the new fields have <strong>no</strong> place to be positioned and so they are not rendered at all.</p>
<a name="Solution"></a>
<h2 >Solution:<a href="#Solution" class="wiki-anchor">¶</a></h2>
<p>Go through the palettes too, and add the new fields right after the palette where the field resides in. Now it looks like this:</p>
<p><img src="http://forge.typo3.org/attachments/download/19014/subtype_addlist-correct.png" title="How it looks with the proposed fix" alt="How it looks with the proposed fix" loading="lazy" /></p> TYPO3 Core - Bug #26995 (Closed): Merge CGL changes from 4.5.3http://forge.typo3.org/issues/269952011-05-23T22:11:16ZErnesto Baschnyeb@cron.eu
<p>Hi,</p>
<p>in patchset 4 of <a class="external" href="https://review.typo3.org/2288">https://review.typo3.org/2288</a> I applied CGL fixes to the <strong>new</strong> code that was changed since 4.5.2. Please consider applying that to the external repository's version also (maybe after we move to GIT).</p>
<p>There are other CGL issues in the extension still, but at least I wanted to make sure no new issues are introduced.</p> TYPO3 Core - Bug #24914 (Closed): Upgrade Wizard "Install Outsourced System Extensions" should on...http://forge.typo3.org/issues/249142011-02-01T12:11:22ZErnesto Baschnyeb@cron.eu
<p>The Upgrade Wizard "Install Outsourced System Extensions" (tx_coreupdates_installsysexts) suggests the user to install all system extensions, even those which are already installed. This is confusing to the user that is doing a "new installation" based on the intro package for example, where all those extensions are already installed by default.</p>
<p>Solution would be to do the same logic as we have in "tx_coreupdates_installnewsysexts", which checks every extension if they are installed (and if all are installed, don't present the wizard at all!).</p>
<p>(issue imported from #M17429)</p> TYPO3 Core - Bug #23798 (Closed): Add new API t3lib_befunc::helpTextArray and use it in the ExtDi...http://forge.typo3.org/issues/237982010-10-20T09:30:50ZErnesto Baschnyeb@cron.eu
<p>Currently the ExtDirect which fetches the tooltip fetches the information on its own from the $TCA_DESCR array. It will also render "TYPO3 Inline Help" as a default header if none is given and will not render an "arrow" which used to symbolize a link to a popup in its content.</p>
<p>This patch adds a new API function t3lib_befunc::helpTextArray which is then used by t3lib_befunc::helpText and also the new ExtDirect call to fetch the information. The tooltips now won't have a title anymore if there is no "alttitle" defined.</p>
<p>Almost none CSH uses "alttile", so usually you won't see any. There are some examples in the Extension manager (e.g. the main titles "Loaded Extensions" etc).<br />(issue imported from #M16074)</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 #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>