TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692014-03-17T22:25:13ZTYPO3 Forge
Redmine 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 #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 - Bug #53692 (Closed): Backend background color is limited to height:100%http://forge.typo3.org/issues/536922013-11-16T13:27:25ZErnesto Baschnyeb@cron.eu
<p>In several backend screens where there is need to scroll, the background color stops at 100% height. This can be seen for example in the Login screen (dark gray ends abruptly when scrolling down), the Element browser (gray background) and others.</p>
<p>This is a regression introduced with <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Integrate normalize css reset (Closed)" href="http://forge.typo3.org/issues/47920">#47920</a> (adding the normalizer.css) and needs to be fixed until 6.2 release.</p>
<p>The UX team noted that also: <a class="external" href="https://projects.invisionapp.com/share/H2IU7YVE#/screens/10263303/comments/6159625">https://projects.invisionapp.com/share/H2IU7YVE#/screens/10263303/comments/6159625</a></p> TYPO3 Core - Bug #53683 (Closed): Don't underline the whole preview text in Web>Page content elem...http://forge.typo3.org/issues/536832013-11-15T21:55:21ZErnesto Baschnyeb@cron.eu
<p>Since we underline links in the backend, the Web>Page also renders all preview text inside content element boxes in underline on mouse over, because those are also links (to the edit windows). This is cluttery and ugly. So get rid of the underline of the preview text!</p>
<p>Reported and wished by the UX team.</p> TYPO3 Core - Bug #53652 (Closed): New element wizard broken tree lineshttp://forge.typo3.org/issues/536522013-11-15T00:24:08ZErnesto Baschnyeb@cron.eu
<p>In <a class="issue tracker-4 status-5 priority-4 priority-default closed child" title="Task: Replace table structure in new element wizard (Closed)" href="http://forge.typo3.org/issues/49603">#49603</a> the html and css of the "new element wizard" was refactored (Web>List, "Create New Record"). This broke the tree lines layout because it added some gaps between the segments.</p>
<p>Before:</p>
<p><img src="http://forge.typo3.org/attachments/download/25500/db_new-tree-orig.png" alt="" loading="lazy" /></p>
<p>Now:</p>
<p><img src="http://forge.typo3.org/attachments/download/25501/db_new-tree-buggy.png" alt="" loading="lazy" /></p>
<p>This needs to be fixed</p> TYPO3 Core - Task #52814 (Closed): Don't throw Exception if "/Packages" cannot be created in Doc-...http://forge.typo3.org/issues/528142013-10-14T20:59:31ZErnesto Baschnyeb@cron.eu
<p>When the new package management takes over throught the Install Tool it tries to create a "Packages" subdirectory directly in PATH_site. This might fail due to no writing rights on this level.</p>
<p>This is not unusual, as TYPO3 never really needed to write anything here, so many installations have hardened their instances by not allowing doc-root-writing.</p>
<p>So we should instead not fatal with an exception, but accept that it wasn't created and not bother about it.</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 #52338 (Closed): Silent configuration generates endless redirect loophttp://forge.typo3.org/issues/523382013-09-27T17:46:02ZErnesto Baschnyeb@cron.eu
<p>If I have some setting in my AdditionalConfiguration like:</p>
<pre>
$GLOBALS['TYPO3_CONF_VARS']['GFX']['im_v5effects'] = '1';
</pre>
<p>this will be always overwride whatever I have in my LocalConfiguration. Now the Install Tool has a "Auto-Configuration" which will try to set this setting to "-1" (in LocalConfiguration). And after doing that, it will redirect to itself. But then the AdditionalConfiguration will override this again and the game restarts.</p>
<p>Result is an endless loop.</p>
<p>This has to be detected somehow, because the current behavior is very touchy and you end up in an endless loop very easily.</p> TYPO3 Core - Bug #52261 (Closed): Bad position of eval=>null checkbox http://forge.typo3.org/issues/522612013-09-25T14:24:41ZErnesto Baschnyeb@cron.eu
<p>The new TCA feature "eval=>null" places a new checkbox as a wizard besides your input field. This seem to look "ok" in the sys_file_reference case (which uses the "useOrOverridePlaceholder" mode), but it looks ugly in case you have regular (non-palette) field:</p>
<p><img src="http://forge.typo3.org/attachments/download/25063/eval-null-checkbox.png" alt="" loading="lazy" /></p>
<p>Also note that a potential "options-palette" icon is misplaced too.</p>
<p>The checkbox must be placed nearer to the input field itself.</p> TYPO3 Core - Task #51435 (Closed): Document css_styled_content rendering changes in compat_versionhttp://forge.typo3.org/issues/514352013-08-28T12:01:16ZErnesto Baschnyeb@cron.eu
<p>We have an array in css_styled_content in ext_localconf.php (compat_version) which is used by the Upgrade Wizard to inform the user of what has changed in the FE-rendering if he "upgrades" his compat version to the latest version (which is recommended).</p>
<p>The rule in the Core has been to add an entry for every change that was made to the rendering in css_styled_content. This hasn't been done since 4.5 as it seems, which then results in the upgrader not getting any info at all at this point of the wizard what has been changed.</p>
<p>In the sense of Smooth migration we should at least document the major changes since 4.5 to the 6.2 version. I would propose not to backport these back to 4.6 .. 6.1 as it is not worth it. And we don't need to document every individual step but instead could summarize the major changes that happened between the versions instead.</p> TYPO3 Core - Bug #43466 (Closed): Drag&Drop in page module broken in Chromehttp://forge.typo3.org/issues/434662012-11-29T22:45:19ZErnesto Baschnyeb@cron.eu
<p>In current master (and branch 6.0) the drag&drop functionality is broken in Chrome (and potentially also Safari?).</p>
<p>This used to work on 6.0.0 release.</p>
<p>Using git bisect I was able to identify the change that broke it: <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: BE login shows unaesthetic scrollbars (Closed)" href="http://forge.typo3.org/issues/43330">#43330</a>. Looks harmless, but reverting it makes drag&drop work again.</p>
<p>Any candidates to explain that? :)</p> TYPO3 Core - Bug #25772 (Closed): Resizeable textareas: scrollbar sticks to mousehttp://forge.typo3.org/issues/257722011-04-05T17:05:00ZErnesto Baschnyeb@cron.eu
<p>If you have resizeable textareas enabled and you try to use the scrollbar to scroll in your content with Internet Explorer 8, the re-sizing feature "sticks" to your mouse pointer (even after releasing the mouse button).</p>
<p>You can try it out with PageTS field in Page properties.</p> TYPO3 Core - Bug #25771 (Closed): Resizeable textareas with Internet Explorer (IE8): random jumps...http://forge.typo3.org/issues/257712011-04-05T17:03:08ZErnesto Baschnyeb@cron.eu
<p>Since 4.4 (?) textareas (e.g. PageTS field in the Page settings) are resizeable. With Internet Explorer there are some problems with it:</p>
<p>If in the user settings you disable the entry "Make Textareas Resizeable", you are not able to click on any line without causing the scrollbar to randomly jump around the content, thus making it very difficult to edit content in these fields.</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>