TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692023-07-25T18:53:46ZTYPO3 Forge
Redmine 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 - Task #77787 (Closed): Optimize rendering of Changelogs for docs.typo3.orghttp://forge.typo3.org/issues/777872016-09-02T15:20:47ZErnesto Baschnyeb@cron.eu
<p>The rendering of the TYPO3 Core Changelog's is currently suboptimal. The result:</p>
<p><a class="external" href="https://docs.typo3.org/typo3cms/extensions/core/latest/Index.html">https://docs.typo3.org/typo3cms/extensions/core/latest/Index.html</a></p>
<p>The rendering produces tons of warnings, the structure is not up to date with the latest theme, and there are several syntax errors with our Rest files.</p>
<p>Solution: Fix it all.</p> TYPO3 Core - Bug #65646 (Closed): Scheduler misses the "stop" icon when a task is running (6.2 only)http://forge.typo3.org/issues/656462015-03-10T20:21:27ZErnesto Baschnyeb@cron.eu
<p>Since <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: Deleted scheduler task groups selectable (Closed)" href="http://forge.typo3.org/issues/63973">#63973</a> was backported to 6.2 the "stop.png" icon is missing when a task is running and therefor a "broken image" appears in the scheduler instead.</p>
<p>The path of the stop.png changed from 6.2 to master and this was not considered in the backport.</p>
<p>Solution is to fix the backport with a follow-up.</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 - 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> TYPO3 Core - Bug #53940 (Rejected): Extension name is not case insensitive in anymorehttp://forge.typo3.org/issues/539402013-11-25T15:30:01ZErnesto Baschnyeb@cron.eu
<p>The extension "abaticker" for example contains something like:</p>
<pre>
t3lib_extMgm::addPlugin(Array("LLL:EXT:abaTicker/locallang_db.php:tt_content.list_type_pi1", $_EXTKEY."_pi1"),"list_type");
</pre>
<p>In 6.2 this now fails with:</p>
<p>"TYPO3 Fatal Error: Extension key "abaTicker" is NOT loaded" (Exception 1365429656)</p>
<p>So the ExtensionManagementUtil API doesn't seem to be backwards compatible yet (i.e. extPath() etc), as it doesn't seem to expect different CaSe for the passed extension key.</p> TYPO3 Core - Feature #53666 (Closed): One search box onlyhttp://forge.typo3.org/issues/536662013-11-15T14:39:26ZErnesto Baschnyeb@cron.eu
<p>During the UXW09 it was defined that we only want to end up with one single "search box" (the one at the top right). So the "search" below the List-module should be gone too.</p>
<p>The idea was that the "global search" and the "page specific search" should be done from this central area, and the different search results grouped in separate tabs.</p>
<p>See this screen from back then:</p>
<p><img src="http://forge.typo3.org/attachments/download/25503/typo3-search-global-uxw09.png" alt="" loading="lazy" /></p>
<p>This implementation seem to be missing or gone. Screenshot is grabbed from this page:</p>
<p><a class="external" href="http://forge.typo3.org/projects/usability/wiki/T3UXW09-Team4#The-search-result-list">http://forge.typo3.org/projects/usability/wiki/T3UXW09-Team4#The-search-result-list</a></p>
<p>Maybe you find other interesting details from the concept back then.</p> TYPO3 Core - Bug #52812 (Rejected): Installing extension bringes 'Package "xy" is not available'http://forge.typo3.org/issues/528122013-10-14T19:09:26ZErnesto Baschnyeb@cron.eu
<p>If I copy an extension directory to typo3conf/ext/ and try to install it using the Extension Manager (it is listed already), I get:</p>
<pre><code>#1166546734: Package "xy" is not available. Please check if the package exists and that the package key is correct (package keys are case sensitive). (More information)</code></pre>
<p>The problem is that the PackageStates file is not up-to-date: it does not include this new package which was just copied there without the knowledge of the Package Management.</p>
<p>Since this is not so uncommon, I would propose to re-create the PackageStates.php file as soon as the Extension Manager tries to do something with packages to make sure it is in sync with the reality - just like it behaved before.</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 - Feature #51538 (Rejected): Move old css_styled_content static templates to own exten...http://forge.typo3.org/issues/515382013-08-29T18:13:37ZErnesto Baschnyeb@cron.eu
<p>css_styled_content provides several static templates that enable to render the frontend in the same way as some older TYPO3 version. We currently ship static templates as old as TYPO3 3.8. The whole list appears in the "Include Template from Extension" list and the list is getting longer each release.</p>
<p>To make it clearer that these templates are not maintained anymore, and new installations should be given these by default, we decided to move these over to a new System Extension which is not installed by default, but can be installed through the Upgrade Wizard if someone decides to stay with older compatibility version.</p>
<p>Proposal for new extension name: csc_oldtemplates</p>
<p>We decided to keep the extension in the core thou so that potential changes and fixes could be more easily be done by the core team itself directly in the core.</p> TYPO3 Core - Bug #50803 (Closed): Fatal error: "enableFields on non-object" in extension managerhttp://forge.typo3.org/issues/508032013-08-05T22:25:44ZErnesto Baschnyeb@cron.eu
<p>Extbase extensions might fail with:</p>
<p>Fatal error: Call to a member function enableFields() on a non-object in .../typo3_src/typo3/sysext/core/Classes/Resource/StorageRepository.php on line 211</p>
<p>The problem was "uncovered" with the <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Find best-matching local storage instead of default-storage (Closed)" href="http://forge.typo3.org/issues/45498">#45498</a> (the new EM fatals with this error since this patch), but could happen in other situations too.</p>
<p>Reason is that Extbase in certain situations will try to create a dummy simulated "TSFE" object to be able to use cObject stdWrap's in the backend context.</p>
<p>Now this is not a "complete TSFE" and doesn't for example include a proper sys_page property.</p>
<p>So to make sure we are in a proper FE context, we shouldn't rely on "is_object($TSFE)" but instead check if TYPO3_MODE==FE like it is done throughout other places in the core.</p> TYPO3 Core - Bug #42890 (Rejected): Regression: Javascript error in Backend (jumpToUrl)http://forge.typo3.org/issues/428902012-11-12T17:50:56ZErnesto Baschnyeb@cron.eu
<p>All checkboxes in the Backend that contain a "onclick" pointing to "jumpToUrl" seem to be broken in the latest release of TYPO3. The Javascript pops up an error:</p>
<p>Uncaught ReferenceError: Invalid left-hand side in assignment</p>
<p>To test, go to the list module and try to select "Extended View" or "Localization View" from the options beneath the list.</p>
<p>Or in Extension Manager (the old-old one), try to select "Display shy extensions"</p>
<p>Tested on 4.5.x, but should affect also the latest security releases of the other branches as well.</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 - Feature #24850 (Rejected): After the last Upgrade Wizard, a link to "COMPARE" should...http://forge.typo3.org/issues/248502011-01-27T11:27:34ZErnesto Baschnyeb@cron.eu
<p>After the last Upgrade Wizard is through, we should present a last Next button which links to the "COMPARE" screen.</p>
<p>This could even be integrated in a standalone "Wizard" so that the DB compare is done cleanly in the Upgrade Wizard path, so that after that the user is presented with a "Congratulation" message and some other nice words.</p>
<p>(issue imported from #M17354)</p>