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 - 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 #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 #23581 (Closed): Module menu and content area are empty after upgrade to 4.5.0al...http://forge.typo3.org/issues/235812010-09-23T09:16:56ZErnesto Baschnyeb@cron.eu
<p>With the new viewpanel the backend is empty. No modules to click on. This message in the debug console: "help_aboutmodules was not found in modules".</p>
<p>It comes from installed extensions that register only a top level module, e.g. llxmltranslate.</p>
<p>(issue imported from #M15770)</p> TYPO3 Core - Bug #23383 (Closed): Not able to select multiple records in recycler since refactoringhttp://forge.typo3.org/issues/233832010-08-16T13:40:00ZErnesto Baschnyeb@cron.eu
<p>Since issue <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Refactor of recycler (Closed)" href="http://forge.typo3.org/issues/20967">#20967</a> was commited (rev. 8606), we are no longer able to select multiple records on the left side (checkboxes).</p>
<p>(issue imported from #M15467)</p> TYPO3 Core - Bug #23281 (Closed): Backend shortcut cannot be set in IE8http://forge.typo3.org/issues/232812010-07-27T20:39:25ZErnesto Baschnyeb@cron.eu
<p>When you add any item in backend as a shortcut (using the "star with a +") using IE8, the shortcut icon disappears and a JS error occurs. The current module is <strong>not</strong> added to the shortcut list</p>
<p>(issue imported from #M15252)</p> TYPO3 Core - Bug #21336 (Closed): Encryption key can be recalculated when using normal mailform w...http://forge.typo3.org/issues/213362009-10-22T11:11:35ZErnesto Baschnyeb@cron.eu
<p>These settings required for being exploitable:<br />['TYPO3_CONF_VARS']['FE']['secureFormmail'] 0<br />['TYPO3_CONF_VARS']['FE']['strictFormmail'] 0</p>
<p>Reported by Stefan Schuler.</p>
<p>Security Team OTRS reference: 2009021010000086 <br />(issue imported from #M12310)</p> TYPO3 Core - Bug #21335 (Closed): Knowing the md5 hash of the password, it is possible to gain ac...http://forge.typo3.org/issues/213352009-10-22T10:49:53ZErnesto Baschnyeb@cron.eu
<p>Solution is to use PHP sessions instead and make these "secure".</p>
<p>Reported by: Bernhard Kraft<br />Security Team OTRS reference: 2009050410000038 <br />(issue imported from #M12309)</p> TYPO3 Core - Bug #20428 (Closed): maxWInText setting is never used, because of missing "textPos" ...http://forge.typo3.org/issues/204282009-05-15T14:37:57ZErnesto Baschnyeb@cron.eu
<p>In the work of rearranging the TypoScript of css_styled_content (now split up into different versions), a bug was introduced in that the "textPos" property was forgotten.</p>
<p>This setting is used in css_styled_content's PHP code to decide if maxW or maxWInText is to be used (usually half the width).</p>
<p>To reproduce the problem:</p>
<p>1) set the constant to styles.content.imgtext.maxWInText to 300 (default)<br />2) insert a content element with images to the "left of text". <br />3) see how they get rendered 600px wide in current trunk</p>
<p>Now apply the patch:<br />Re-render the page, and now the 300px correct setting is applied to the image.</p>
<p>This is pretty critical as it will break several site layouts.</p>
<p>(issue imported from #M11094)</p>