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 #56554 (Closed): OpCache XCACHE cannot be cleared if xcache.admin.enable_auth is...http://forge.typo3.org/issues/565542014-03-04T21:15:10ZErnesto Baschnyeb@cron.eu
<p>Error:</p>
<pre>
Fatal error: xcache_clear_cache(): xcache.admin.user and/or xcache.admin.pass settings is not configured. Make sure you've modified the correct php ini file for your php used in webserver. in /var/www/git/master/typo3/sysext/core/Classes/Utility/OpcodeCacheUtility.php on line 123
[21:02:00] Christian Kuhn: calling install toll on fresh instance
</pre>
<p>Solution is to check for xcache.admin.enable_auth.</p>
<p>References in other projects:</p>
<p><a class="external" href="https://github.com/owncloud/core/blob/master/lib/private/util.php#L1103">https://github.com/owncloud/core/blob/master/lib/private/util.php#L1103</a><br /><a class="external" href="https://github.com/sugarcrm/sugarcrm_dev/blob/master/include/SugarCache/SugarCache.php#L124">https://github.com/sugarcrm/sugarcrm_dev/blob/master/include/SugarCache/SugarCache.php#L124</a></p>
<p>We then should add a hint in the install tool about this.</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 #43331 (Closed): "Strict standards: Declaration of "CompatbilityClassLoaderPhpBe...http://forge.typo3.org/issues/433312012-11-27T09:27:34ZErnesto Baschnyeb@cron.eu
<p>On PHP < 5.3 I get this warning on top of the login screen (and also in the whole backend, making it completely unusable):</p>
<p>Strict standards: Declaration of TYPO3\CMS\Core\Compatibility\CompatbilityClassLoaderPhpBelow50307::requireClassFileOnce() should be compatible with that of TYPO3\CMS\Core\Core\ClassLoader::requireClassFileOnce() in /.../typo3_src/typo3/sysext/core/Classes/Core/SystemEnvironmentBuilder.php on line 239</p>
<p>Acording to git bisect this got broken with change <a class="issue tracker-4 status-5 priority-3 priority-lowest closed" title="Task: Protect bootstrap methods (Closed)" href="http://forge.typo3.org/issues/43285">#43285</a>.</p>
<p>Indeed the declaration of the methods differ:</p>
<pre>
class ClassLoader {
...
static protected function requireClassFileOnce($classPath) {
...
</pre>
<pre>
class CompatbilityClassLoaderPhpBelow50307 extends \TYPO3\CMS\Core\Core\ClassLoader {
...
static public function requireClassFileOnce($classPath, $className) {
...
</pre>
<p>And by the way, the classname CompatbilityClassLoaderPhpBelow50307 is misspelled (misses an "i" in Compat*i*bility).</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 - Feature #24813 (Closed): Since using new flags from sprites (famfam), the sys_langua...http://forge.typo3.org/issues/248132011-01-25T20:48:58ZErnesto Baschnyeb@cron.eu
<p>Selicons are missing for the flag selector box in sys_language.</p>
<p>Get them back, for now (4.5) without using sprites.</p>
<p>In future (4.6) the selicon interface should also allow flags, buts its too late now to introduce yet another API.</p>
<p>(issue imported from #M17313)</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>