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 #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 #56538 (Closed): Cache the $GLOBALS['TYPO3_LOADED_EXT'] as an arrayhttp://forge.typo3.org/issues/565382014-03-04T15:28:03ZErnesto Baschnyeb@cron.eu
<p>Several core components still access $GLOBALS['TYPO3_LOADED_EXT'] directly. Basically it's used to loop through the activated extensions and also to check if some extension is installed.</p>
<p>Since the Package Management, this array is being simulated by an object (LoadedExtensionsArray). Plan was to be able to add deprecation messages for accessing this array in future.</p>
<p>When accessing a FE with one USER_INT, accessing this object takes about 10% of the time.</p>
<p>It should be considered if we cannot generate the original array on first request, cache it, and then make the GLOBAL array available again to whoever uses it. It's just a list of extensions. The gain of the future possibility of throwing a deprecation message opposed to simply having this array as an array and be fast is probably not worth it.</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 - 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 - Epic #53915 (Closed): Usability and timing issues in Pagetreehttp://forge.typo3.org/issues/539152013-11-25T00:37:06ZErnesto Baschnyeb@cron.eu
<p>The page tree has some problems when it has to deal with long running tasks:</p>
<p>- delete whole tree<br />- copy tree with lots of childs<br />- etc...</p>
<p>This umbrella-issue should try to collect these so that they can be tackled at once.</p> TYPO3 Core - Bug #30631 (Closed): RTE doesn't allow to create links around images in IE8http://forge.typo3.org/issues/306312011-10-07T16:38:07ZErnesto Baschnyeb@cron.eu
<p>If you have images in your RTE, IE8 users cannot link this image to other pages. The browse_links popup opens up, but when clicking on any page in the tree, the tree just reloads and we have javascript error in the console (property or method not supported), pointing to the range.getBookmark() method here:</p>
<pre><code>HTMLArea.Editor.prototype.getBookmark = function (range) {<br /> return range.getBookmark();<br /> };</code></pre> TYPO3 Core - Bug #29234 (Closed): RTE only loads TD styles from external css file on reloadhttp://forge.typo3.org/issues/292342011-08-24T21:23:35ZErnesto Baschnyeb@cron.eu
<p>Hi,</p>
<p>I want to enable Table-Cell styles in RTEhtmlarea. It works great, but I have problems with IE8. Here's the setup:</p>
<p>TYPO3 4.5.5<br />PageTS:</p>
<pre><code>RTE.default {<br /> contentCSS = fileadmin/contentRTE.css<br /> classesTD := addToList(highlight-blue)<br />}</code></pre>
<p>fileadmin/contentRTE.css contains:</p>
<pre><code>TD.highlight-blue { background-color: #003399; color: #ffffff; font-weight: bold; }<br />TD.align-left { text-align: left; }<br />TD.align-center { text-align: center; }<br />TD.align-right { text-align: right; }</code></pre>
<p>Now everything works as expected in FF and Chrome. In IE8, on first loading of an editing Form, I get these CSS loaded (shown in the F12 - developer tools):</p>
<p><img src="http://forge.typo3.org/attachments/download/18493/rte-table-styles-01-first-load.png" alt="" loading="lazy" /></p>
<p>The RTE displays the list of available TD classes like this. Not even "Justify Left" etc are shown!</p>
<p><img src="http://forge.typo3.org/attachments/download/18494/rte-table-styles-02-first-load-rte.png" alt="" loading="lazy" /></p>
<p>Then I simply <strong>reload</strong> the frame where the RTE is located. The CSS list is now this:</p>
<p><img src="http://forge.typo3.org/attachments/download/18495/rte-table-styles-03-reload.png" alt="" loading="lazy" /></p>
<p>And the RTE works as expected:</p>
<p><img src="http://forge.typo3.org/attachments/download/18496/rte-table-styles-04-reload-rte.png" alt="" loading="lazy" /></p>
<p>Of course I cannot tell the editor to keep reloading the editing frame before beginning, so I would love to see this fixed.</p>
<p>If an environment is required to reproduce, please let me know. I was able to transfer the above scenario from one very complex installation to a simple and and reduced the test-bed to simple the above shown, so it should be simple to test.</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 #25686 (Closed): Make scheduler sample use SwiftMailerhttp://forge.typo3.org/issues/256862011-01-18T09:40:30ZErnesto Baschnyeb@cron.eu
<p>We're deprecating t3lib_htmlmail, so stop using it also in the scheduler's sample task.</p>
<p>Attached patch does that. Francois, could you check that it works and commit FYI? Thanks!<br />(issue imported from #M17108)</p> TYPO3 Core - Bug #12079 (Closed): Not possible to reactivate t3editor after deactivationhttp://forge.typo3.org/issues/120792011-01-10T22:21:26ZErnesto Baschnyeb@cron.eu
<p>When I de-select the checkbox "Deactivate t3editor" which is shown below the Info/Modify form of SETUP (or CONSTANT), there is no way of getting it back "active". If I unselect that checkbox again and SAVE, it is again activated as soon as I enter that form again.</p>
<p>This happens on 4.4 and current trunk. Would be cool to have that fixed for the 4.5.0 final release.</p> TYPO3 Core - Bug #12000 (Closed): Topbar: Cache and Favorites submenus shifts when in Workspaceshttp://forge.typo3.org/issues/120002011-01-07T18:44:03ZErnesto Baschnyeb@cron.eu
<p>Hi,</p>
<p>in Live mode, the Cache (and Favorites) submenu is positioned correctly:</p>
<p><img src="http://forge.typo3.org/attachments/download/4885/clear-cache-live-position.png" alt="" loading="lazy" /></p>
<p>As soon as you switch to a Draft Workspace (thus getting the dashed top bar), the position of the submenu is wrong:</p>
<p><img src="http://forge.typo3.org/attachments/download/4886/clear-cache-ws-position.png" alt="" loading="lazy" /></p>
<p>It seems that it shifts exactly the size of the Workspace name which is added on the top bar:</p>
<p><img src="http://forge.typo3.org/attachments/download/4887/clear-cache-ws-position-2.png" alt="" loading="lazy" /></p> TYPO3 Core - Bug #25670 (Closed): Since new CSH handling, no icon in scheduler works anymorehttp://forge.typo3.org/issues/256702010-10-16T20:18:37ZErnesto Baschnyeb@cron.eu
<p>Scheduler adds a class="typo3-csh-link" to all A-tags around icons to have them styled like the CSH icons (without "underline").</p>
<p>Since rev.9081 (RFC <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Error in Result Processing lead to wrong result count and false paging. (Closed)" href="http://forge.typo3.org/issues/15990">#15990</a>), those classes will get some javascript "onclick" auto-added by the API. This makes all icons in the scheduler unuseable.</p>
<p>(issue imported from #M16016)</p> TYPO3 Core - Bug #15305 (Closed): RemoveFormat destroys the HTML sometimeshttp://forge.typo3.org/issues/153052005-12-22T15:49:37ZErnesto Baschnyeb@cron.eu
<p>Due to a bug in a RegExp, sometimes applying the RemoveFormat to remove HTML- or Word-formatting you end up with non-valid HTML code.</p>
<p>The attached patch (rtehtmlarea-eb.diff) corrects this issues and additionally also removes cellpadding, cellspacing, frame and bgcolor attributes, which are used to style tables (I expect them to disappear if I choose to "remove formatting" so that I can style them in CSS or using classes provided by the RTE).</p>
<p>Try the attached HTML fragment (rtehtmlarea-removeformatbug.html) in a rtehtmlarea (paste it in "text" mode). You will see the problem "in action". Just remove format and select HTML-formatting and Word-Formatting. You end up with "<tdspan3>" tags and other bizarre things).</p>
<p>After applying the patch, you will get a "clean" output after using the removeformat function, as expected.<br />(issue imported from #M2084)</p>