TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692014-07-27T15:34:20ZTYPO3 Forge
Redmine TYPO3 Core - Task #60622 (Rejected): Deprecate getUrl, curlProxyServer and encourage usage of HTT...http://forge.typo3.org/issues/606222014-07-27T15:34:20ZErnesto Baschnyeb@cron.eu
<p>The SYS.curl* settings are being used by GeneralUtility::getUrl and openid. And probably other extensions are using that too.</p>
<p>Since 6.0 we have the nice HttpRequest adapter for the PEAR HTTP_Request2 component, which is a full replacement of what our old getUrl does.</p>
<p>So we want to deprecate getUrl along with the curl* settings.</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 #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 - 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>