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 #101640 (Resolved): PHP Warning: Undefined array key "eval" in ...core/Classes/D...http://forge.typo3.org/issues/1016402023-08-09T17:07:24ZErnesto Baschnyeb@cron.eu
<p>In case I have a TCA "slug" field without a "eval" config, PHP 8 will bail out with this exception, for example when moving a page in the backend:</p>
<pre><code>PHP Warning: Undefined array key "eval" in /srv/www/www_dhbw_de/releases/60/private/typo3/sysext/core/Classes/DataHandling/DataHandler.php line 8390</code></pre> 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 #31309 (Closed): EM: Confusing error message when uploading an extension that is...http://forge.typo3.org/issues/313092011-10-26T12:13:32ZErnesto Baschnyeb@cron.eu
<p>When you try to upload an extension that is not registered on typo3.org, you end up with an error message like this:</p>
<p><img src="http://forge.typo3.org/attachments/download/19287/em-upload-invalid.png" title="Buggy error message" alt="Buggy error message" loading="lazy" /></p>
<p>What we would like to see is the real error coming from the TER server, like this:</p>
<p><img src="http://forge.typo3.org/attachments/download/19288/em-upload-invalid-enhanced.png" title="Complete error message" alt="Complete error message" loading="lazy" /></p>
<p>This issue fixes this.</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 #29274 (Closed): Regression on session handling for security fixhttp://forge.typo3.org/issues/292742011-08-26T13:59:59ZErnesto Baschnyeb@cron.eu
<p>After upgrading from 4.3.11 to 4.3.12, an embedded application (run as a TYPO3 extension) did not work anymore. After some research, I discovered it was due to the change introduced in <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: Information disclosure during backend login (Closed)" href="http://forge.typo3.org/issues/24456">#24456</a>, which moved the call of "session_start()" from a place where it was only called on demand (when doing a challenge/response login) to a place where it is <strong>always</strong> being called (even on the frontend).</p>
<p>Two issues with this changes:</p>
<p>1) My embedded application for a misfortune also does a session_start. But it also includes lots of Objects into this session. The classes for this objects are loaded by the application before calling session_start(), so PHP can build the objects just fine.</p>
<p>But now when TYPO3 calls a session_start on <strong>every hit</strong> and very early: the classes of my applications are not loaded yet! Thus the session is filled with "__PHP_Incomplete_Class" objects! The application no longer works.</p>
<p>2) Another issue which happened after this change is that several customer sites began running over quota, simply because every FE hit (even from Google & Co) created new PHP session (files in phptmp). This was not so before and will cause annoyances for bigger sites, which are tuned for fast FE rendering explicitly without Cookies / Sessions.</p>
<p>In my situation the result is worse than the "security gain" obtained by this change. So please consider either reverting it again (also in 4.4 and 4.5) or apply it somewhere else.</p> TYPO3 Core - Bug #25398 (Closed): TCEforms draws huge empty icon row which on select-fields, maki...http://forge.typo3.org/issues/253982011-03-25T20:18:25ZErnesto Baschnyeb@cron.eu
<p>Certain fields of type "select" which offer records from a "foreign_table" will contain a huge amount of t3-icon-empty icons just below the select box. If you have enough of them, you even get a horizotanl scrollbar.</p>
<p>See some screenshots here:<br /><a class="external" href="http://forge.typo3.org/issues/13422">http://forge.typo3.org/issues/13422</a></p>
<p>The issue is not a CSS issue, but a bug in the rendering of such a field.</p>
<p>See it in action in tt_content field "sys_language". Just create enough sys_language records so that you see the row of empty icons being created. This wasn't this way before.</p>
<p>(issue imported from #M18041)</p> TYPO3 Core - Bug #25150 (Closed): Fatal error when installing TYPO3 with PHP-APC (no session is s...http://forge.typo3.org/issues/251502011-02-24T09:09:21ZErnesto Baschnyeb@cron.eu
<p>When installing TYPO3 together on a system with loaded PHP-APC, e.g. the one that ships with Debian Squeeze (APC 3.1.3, but affected seems to be also 3.1.4-dev, 3.1.3p1, 3.1.2, 3.0.19) you get a Fatal error.</p>
<p>On the first step of the install tool:</p>
<p>Fatal error: Class 't3lib_div' not found in /../typo3/sysext/install/mod/class.tx_install_session.php on line 347</p>
<p>See screen in the attachment (Fatal Error on the bottom).</p>
<p>No further steps are then possible (you then get a login screen).</p>
<p>It turns out that the list of loaded classes is incomplete when PHP tries to write the session data. t3lib_div is not there anymore. This behaviour was introduced in <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: tx_install_session::write doesn't fix permissions (Closed)" href="http://forge.typo3.org/issues/24980">#24980</a>.</p>
<p>The PHP bug is already documented and acknoledged by PHP / APC authors:</p>
<p><a class="external" href="http://pecl.php.net/bugs/bug.php?id=16721">http://pecl.php.net/bugs/bug.php?id=16721</a></p>
<p>From the comment from Rasmus</p>
<blockquote>
<p>[2011-02-14 16:44 UTC] rasmus at php dot net</p>
<p>Once again, the fix is trivial. Put session_write_close() in <br />your script when you are done with the session.</p>
<p>We'll come up with a fix eventually, but it isn't a trivial <br />thing to fix.</p>
</blockquote>
<p>Calling session_write_close() at the destructor of the tx_install_session class seems to be the most easy solution.<br />(issue imported from #M17732)</p> TYPO3 Core - Bug #24873 (Closed): Open forms cannot be saved after "Relogin" (Security Token errors)http://forge.typo3.org/issues/248732011-01-28T11:17:58ZErnesto Baschnyeb@cron.eu
<p>If you have an open form (e.g. editing a content element) and you leave your browser unattended until "session expires", you can relogin with the popup window (or the JS overlay).</p>
<p>After this relogin, if you try to save your work, you will get security token errors.</p>
<p>The CSRF protection token is in a hidden field, and if the session has expired in the meantime, the session data (including the original tokens) are gone, so when saving that form after the relogin won't be able to validate them. Different potential solutions:</p>
<p>a) go through the DOM and manipulate all hidden fields with a token and change them with a new valid token. doable, but will require some work<br />b) allow "one save without token check" right after the relogin, so that this form can be finally saved, and after that things continue as usual.</p>
<p>(issue imported from #M17383)</p> TYPO3 Core - Bug #24870 (Closed): Regression: The ExtDirect token needs to be regenerated after r...http://forge.typo3.org/issues/248702011-01-28T10:34:44ZErnesto Baschnyeb@cron.eu
<p>After "relogin", all extdirect requests to the backend no longer work (context menus no loading, pagetree not responding and several errors popping up in the debug panel).</p>
<p>This had been fixed before (for RC1 = <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: The ExtDirect token needs to be regenerated after relogin by popup window (Closed)" href="http://forge.typo3.org/issues/24715">#24715</a>), but was later broken again (with the introduction of the performance improvements in RC2 = <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: The ExtDirect token needs to be regenerated after relogin by popup window (Closed)" href="http://forge.typo3.org/issues/24715">#24715</a>).</p>
<p>This fix doesn't help for any open FORM (no ExtDirect) that you have on the page. I.e. if you are editing a content element, and you "relogin" (with the popup or the dialog relogin), you won't be able to save your work. This will require some extra work.<br />(issue imported from #M17378)</p> TYPO3 Core - Bug #24829 (Closed): Rename "Update Wizard" into "Upgrade Wizard"http://forge.typo3.org/issues/248292011-01-26T12:18:50ZErnesto Baschnyeb@cron.eu
<p>1) When going from 4.4 to 4.5 people speak about "Upgrading".<br />2) When going from 4.5.0 to 4.5.1 people speak about "Updating".</p>
<p>Since the "Update Wizard" is only relevant for the first situation (as we don't do any breaking changes in between), rename it to "Upgrade Wizard".</p>
<p>(issue imported from #M17333)</p> TYPO3 Core - Bug #24816 (Closed): Flag sprites was not updated after renaming canada.gif back to ...http://forge.typo3.org/issues/248162011-01-25T22:07:38ZErnesto Baschnyeb@cron.eu
<p>In <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Catalan flag is replaced by Canadian flag (Closed)" href="http://forge.typo3.org/issues/24477">#24477</a> the canada / catalonian flags were exchanged and later rolled-back. But the sprite was not updated.</p>
<p>While updating the flags sprite I also noticed that the "multiple.gif" which represent "multiple languages" was not added as a sprite before. And also that it was called "multi-language.gif" before.</p>
<p>So this issue should fix these things:</p>
<p>1) new sprite containing the correct "ca" = canada and "catalonia" = Catalonian flag</p>
<p>2) using the existing array of "flags" (not languageCodes!!) to also make the sprites available, instead of listing them one by one in ext_tables.php.</p>
<p>3) update the Upgrade Wizard which should also convert the old-school "multi-languages.gif" to "multiple" sprite.</p>
<p>(issue imported from #M17316)</p> TYPO3 Core - Bug #24784 (Closed): Workspaces module get place on "top" of all moduleshttp://forge.typo3.org/issues/247842011-01-25T01:12:26ZErnesto Baschnyeb@cron.eu
<p>After uninstalling the new sysext "info", the Workspaces module is on the first position of the modules menu (even before "Web>Page").</p>
<p>Since we moved several old hardcoded modules to sysext, they can also be uninstalled. Some extensions place their backend modules using the t3lib_extMgm::addModule() call and setting the $position parameter to one of these old hardcoded extensions.</p>
<p>E.g. the workspaces module registers himself for "before:info". So if "info" is not installed, the default would be to be placed "at the end". This is even documented in the method addModule(), but it doesn't work.</p>
<p>This is related to <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: New sysext modules are placed incorrectly in the Web> module menu (Closed)" href="http://forge.typo3.org/issues/24271">#24271</a> and a follow-up after this fix was applied: <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: New sysext modules are placed incorrectly in the Web> module menu (Closed)" href="http://forge.typo3.org/issues/24271">#24271</a><br />(issue imported from #M17282)</p> TYPO3 Core - Bug #24710 (Closed): Introduce setting "defaultMailFromName" and move defaultMailFro...http://forge.typo3.org/issues/247102011-01-21T16:25:29ZErnesto Baschnyeb@cron.eu
<p>In <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: When sending mail, use TYPO3_CONF_VAR for default from address if no other address is provided (Closed)" href="http://forge.typo3.org/issues/22447">#22447</a> (rev. 10167) we introduced $GLOBALS['TYPO3_CONF_VARS']['SYS']['defaultMailFromAddress'].</p>
<p>Since we want all new mail related settings to be grouped, we decided to move that to $GLOBALS['TYPO3_CONF_VARS']['MAIL']['defaultMailFromAddress']. And then also introduce $GLOBALS['TYPO3_CONF_VARS']['SYS']['defaultMailFromName'] at the same time.</p>
<p>(issue imported from #M17198)</p> TYPO3 Core - Bug #24691 (Closed): Remove unnecessary comments and color profiles from all shipped...http://forge.typo3.org/issues/246912011-01-20T19:42:29ZErnesto Baschnyeb@cron.eu
<p>We want the backend to load faster. By stripping useless comments and profile information on the static images (icons, sprites, etc) we gain some speed and our typo3_src package gets smaller.</p>
<p>Using a tool like <a class="external" href="http://imageoptim.pornel.net/">http://imageoptim.pornel.net/</a> [^] automates this process. Steffen Gebert has pushed all images from our typo3_src through this tool and the result is here. The typo3_src directory went down from 70.9Mb to 68.6Mb (2.3Mb of extra-weight gone...)</p>
<p>Using a tool like <a class="external" href="http://imageoptim.pornel.net/">http://imageoptim.pornel.net/</a> automates this process.</p>
<p>Steffen Gebert has pushed all images from our typo3_src through this tool and the result is here.<br />(issue imported from #M17176)</p>