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 - 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> TYPO3 Core - Bug #53975 (Closed): BeLog: Exception when time input fields are emptyhttp://forge.typo3.org/issues/539752013-11-26T11:20:41ZErnesto Baschnyeb@cron.eu
<p>If you go to "Info>Log" or "Admin>Log" and select "Userdefined" time range and then leave one of the input fields (start or stop) empty and click "Set", you end up with this exception:</p>
<p>Exception while property mapping at property path "":PHP Catchable Fatal Error: Argument 1 passed to TYPO3\CMS\Belog\Domain\Model\Constraint::setManualDateStop() must be an instance of DateTime, null given, called in .../html/typo3_src/typo3/sysext/extbase/Classes/Reflection/ObjectAccess.php on line 215 and defined in .../html/typo3_src/typo3/sysext/belog/Classes/Domain/Model/Constraint.php line 273</p>
<p>When you are in this situation and go to the module again, even changing the Time Select Box to "Undefined" you still get this error (probably because the empty input fields are hidden but submitted again).</p>
<p>And empty input field in start/stop should remove this specific limit.</p>