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 - Task #60622 (Rejected): Deprecate getUrl, curlProxyServer and encourage usage of HTT...http://forge.typo3.org/issues/606222014-07-27T15:34:20ZErnesto Baschnyeb@cron.eu
<p>The SYS.curl* settings are being used by GeneralUtility::getUrl and openid. And probably other extensions are using that too.</p>
<p>Since 6.0 we have the nice HttpRequest adapter for the PEAR HTTP_Request2 component, which is a full replacement of what our old getUrl does.</p>
<p>So we want to deprecate getUrl along with the curl* settings.</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 - Task #57209 (Closed): Remove deprecation of BasicFileUtility::init until core stops ...http://forge.typo3.org/issues/572092014-03-23T17:58:02ZErnesto Baschnyeb@cron.eu
<p>Until we fully remove usage of BasicFileUtility throughout the core (i.e. DataHandler, Import/Export module, ElementBrowser and others), the core should not pollute the deprecation log with it.</p> TYPO3 Core - Bug #57008 (Closed): New Installation: Could not acquire lock for ClassLoaderhttp://forge.typo3.org/issues/570082014-03-17T22:25:13ZErnesto Baschnyeb@cron.eu
<p>With the Class Loader Locking patch applied (see <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: PHP Warnings after clearing configuration cache in BE (Closed)" href="http://forge.typo3.org/issues/55099">#55099</a>) when installing a fresh new TYPO3 installation (no typo3temp directory present), I get:</p>
<p>( ! ) Fatal error: Uncaught exception 'RuntimeException' with message 'Could not acquire lock for ClassLoader cache creation.' in /www/sites/typo3-62/html/typo3_src/typo3/sysext/core/Classes/Core/ClassLoader.php on line 704<br />( ! ) RuntimeException: Could not acquire lock for ClassLoader cache creation. in /www/sites/typo3-62/html/typo3_src/typo3/sysext/core/Classes/Core/ClassLoader.php on line 704</p>
<p>This should be handled somehow.</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 - Task #56497 (Closed): Install Tool order of menu itemshttp://forge.typo3.org/issues/564972014-03-03T15:52:16ZErnesto Baschnyeb@cron.eu
<p>According to feedback from the UX team, we should reorder the menu items of the install tool:</p>
<p><a class="external" href="https://projects.invisionapp.com/share/H2IU7YVE#/screens/12116399/comments/7066513">https://projects.invisionapp.com/share/H2IU7YVE#/screens/12116399/comments/7066513</a></p>
<p>(and here a screen in case the above link is not working anymore):</p>
<p><img src="http://forge.typo3.org/attachments/download/26168/install-tool-order.png" alt="" loading="lazy" /></p>
<p>Current Order:</p>
<ul>
<li>Welcome</li>
<li>Important actions</li>
<li>System environment</li>
<li>Configuration Presets</li>
<li>Folder structure</li>
<li>Test setup</li>
<li>Upgrade Wizard</li>
<li>All configuration</li>
<li>Clean up</li>
<li>Logout from Install Tool</li>
</ul>
<p>New proposed order:</p>
<ul>
<li>Important Actions</li>
<li>Configuration Presets</li>
<li>All Configuration</li>
<li>Upgrade Wizard</li>
<li>System environment</li>
<li>Folder Structure</li>
<li>Test Setup</li>
<li>Cleanup</li>
</ul>
<p>"Logout" is put below the menu as a link and "Welcome" is just the first screen but without any menu item for it.</p> TYPO3 Core - Task #55464 (Closed): Install Tool Lock Screen (Backend Mode) Stylinghttp://forge.typo3.org/issues/554642014-01-30T15:09:52ZErnesto Baschnyeb@cron.eu
<p>Warning icon misplaced in the Alert to "Unlock Install Tool" when called as a Backend Module. Fix it.</p> TYPO3 Core - Task #55453 (Closed): Install Tool > All Configuration "Expand All" functionalityhttp://forge.typo3.org/issues/554532014-01-30T12:32:56ZErnesto Baschnyeb@cron.eu
<p>To ease finding settings in the new Install Tool "All Configuration", we want to have an "Expand all" feature to expand (and collapse) all accordions at the same time.</p> TYPO3 Core - Task #54511 (Closed): Travis increase PHP memory_limit to 1280mhttp://forge.typo3.org/issues/545112013-12-19T13:56:58ZErnesto Baschnyeb@cron.eu
<p>Currently travis is failing due to exploded memory_limit (>1024m). Why it takes so much needs to be investigated and is planned here: <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: phpunit run in Travis: Detect and fix memory leaks (Closed)" href="http://forge.typo3.org/issues/54510">#54510</a></p>
<p>While this is not tackled, we should increase memory_limit for phpunit run a bit so that it at least works again. I.e. to 1280M.</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 - Epic #54260 (Closed): WP: FAL Missing Issues / Features / APIhttp://forge.typo3.org/issues/542602013-12-07T14:56:05ZErnesto Baschnyeb@cron.euTYPO3 Core - Task #53988 (Closed): First Time Installation doesn't need a "beforePackageStatesMig...http://forge.typo3.org/issues/539882013-11-26T18:10:24ZErnesto Baschnyeb@cron.eu
<p>For a dummy blank new installation the Installer creates a LocalConfiguration.php in "old-school" way (with extList) and then converts that to PackageStates and moves the old file to LocalConfiguration.beforePackageStatesMigration.php.</p>
<p>This is ugly, as you find yourself with "old files" while you are just installing it for the first time.</p>
<p>Could be streamlined, so that the first time installation activates the packages automatically.</p>