TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692023-08-09T17:07:24ZTYPO3 Forge
Redmine 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 #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 - Bug #45834 (Closed): Detection of curlProxyServer settings buggy on upgrade to 6.0http://forge.typo3.org/issues/458342013-02-25T19:24:39ZErnesto Baschnyeb@cron.eu
<p>In <a class="issue tracker-2 status-5 priority-3 priority-lowest closed behind-schedule" title="Feature: Include HTTP Request2 for better HTTP handling (Closed)" href="http://forge.typo3.org/issues/28344">#28344</a> "HTTP Request2" API was included. It supports detecting old school "curlProxyServer" settings and transfer these to the "new" setting under HTTP:</p>
<pre>
$proxyParts = explode(':', $GLOBALS['TYPO3_CONF_VARS']['SYS']['curlProxyServer'], 2);
$GLOBALS['TYPO3_CONF_VARS']['HTTP']['proxy_host'] = $proxyParts[0];
$GLOBALS['TYPO3_CONF_VARS']['HTTP']['proxy_port'] = $proxyParts[1];
</pre>
<p>This code ended up in Core/Bootstrap::transferDeprecatedCurlSettings() after namespace and bootstrapification.</p>
<p>I have always set up this setting like this:</p>
<pre>
$GLOBALS['TYPO3_CONF_VARS']['SYS']['curlProxyServer'] = 'http://proxy:3128';
</pre>
<p>I guess the implementator of the transferDeprecatedCurlSettings was only thinking about the "proxy:3128" kind of syntax. I end up with:</p>
<pre>
$GLOBALS['TYPO3_CONF_VARS']['HTTP']['proxy_host'] = 'http'
$GLOBALS['TYPO3_CONF_VARS']['HTTP']['proxy_port'] = '//proxy:3128;
</pre>
<p>Other than that, I would also auto-set ['HTTP']['adapter'] to 'curl' if legacy 'curlUse' = TRUE.</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 #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 #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 #24914 (Closed): Upgrade Wizard "Install Outsourced System Extensions" should on...http://forge.typo3.org/issues/249142011-02-01T12:11:22ZErnesto Baschnyeb@cron.eu
<p>The Upgrade Wizard "Install Outsourced System Extensions" (tx_coreupdates_installsysexts) suggests the user to install all system extensions, even those which are already installed. This is confusing to the user that is doing a "new installation" based on the intro package for example, where all those extensions are already installed by default.</p>
<p>Solution would be to do the same logic as we have in "tx_coreupdates_installnewsysexts", which checks every extension if they are installed (and if all are installed, don't present the wizard at all!).</p>
<p>(issue imported from #M17429)</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>