TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692013-02-25T19:24:39ZTYPO3 Forge
Redmine 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 #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 #24681 (Closed): CSH tooltips should be placed nearer to the texthttp://forge.typo3.org/issues/246812011-01-20T13:39:57ZErnesto Baschnyeb@cron.eu
<p>Since <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: CSH tooltip often gets in the way of the field it is supposed to provide help for (Closed)" href="http://forge.typo3.org/issues/24578">#24578</a> the tooltips are on top of the labels, improving the usability. But they are some px too far away. Also the (?) icon in the docheader, the arrow pointing out to the tooltip is not placed aligned with the icon.</p>
<p>Solution is to offset the pointer -10px and also move the tooltip closer with some ExtJS magic.</p>
<p>(issue imported from #M17163)</p> TYPO3 Core - Bug #24571 (Closed): Backend search throws Exceptions / SQL errors when running as n...http://forge.typo3.org/issues/245712011-01-14T15:05:39ZErnesto Baschnyeb@cron.eu
<p>When a non-admin tries the BE live search, SQL errors are thrown (and you see them in the debug console if this is active). Only happens for non-admin users.</p>
<p>(issue imported from #M17032)</p> TYPO3 Core - Bug #23799 (Closed): Add IfModule mod_rewrite.c to misc/advanced.htaccesshttp://forge.typo3.org/issues/237992010-10-20T09:42:15ZErnesto Baschnyeb@cron.eu
<p>The introduction package creates its own .htaccess file which contains <IfModule mod_rewrite.c>.</p>
<p>I would like to have that IfModule in misc/advanced.htaccess so that the introduction package could ship with our misc/advanced.htaccess, instead of creating its own .htaccess file.</p>
<p>The usage of misc/advanced.htaccess will be then added to the intro-package packaging script.</p>
<p>I would like to commit this also for 4.4, so that we can also use this in the 4.4 introduction packaging script.<br />(issue imported from #M16075)</p> TYPO3 Core - Bug #23798 (Closed): Add new API t3lib_befunc::helpTextArray and use it in the ExtDi...http://forge.typo3.org/issues/237982010-10-20T09:30:50ZErnesto Baschnyeb@cron.eu
<p>Currently the ExtDirect which fetches the tooltip fetches the information on its own from the $TCA_DESCR array. It will also render "TYPO3 Inline Help" as a default header if none is given and will not render an "arrow" which used to symbolize a link to a popup in its content.</p>
<p>This patch adds a new API function t3lib_befunc::helpTextArray which is then used by t3lib_befunc::helpText and also the new ExtDirect call to fetch the information. The tooltips now won't have a title anymore if there is no "alttitle" defined.</p>
<p>Almost none CSH uses "alttile", so usually you won't see any. There are some examples in the Extension manager (e.g. the main titles "Loaded Extensions" etc).<br />(issue imported from #M16074)</p> TYPO3 Core - Bug #23482 (Closed): Change all core PHP files to UTF8 encodinghttp://forge.typo3.org/issues/234822010-08-30T20:48:59ZErnesto Baschnyeb@cron.eu
<p>We want to have UTF8 PHP files in order to give proper credit to authors containing non-ASCII characters in their names. This mostly affects PHP comments.</p>
<p>(issue imported from #M15601)</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 #22235 (Closed): "Show" clickmenu in page tree generates wrong URLhttp://forge.typo3.org/issues/222352010-03-04T09:19:32ZErnesto Baschnyeb@cron.eu
<p>If we don't have any sys_domain record in our page tree, the clickmenu "Show" will generate a link like:</p>
<p><a class="external" href="http://example.com//index.php?id=xx">http://example.com//index.php?id=xx</a></p>
<p>Note the double "//" before index.php. This won't work if you have realurl installed (it doesn't even need to be enabled for your site):</p>
<p>"Error!</p>
<p>Reason: "index.php" could not be found, closest page matching is<br />"</p>
<p>(issue imported from #M13740)</p> TYPO3 Core - Bug #22234 (Closed): "Show" clickmenu in page tree does not work for mount pageshttp://forge.typo3.org/issues/222342010-03-04T09:08:14ZErnesto Baschnyeb@cron.eu
<p>Clicking the "Show" on a page which is a mount point to somewhere else brings the error:</p>
<p>"The requested page didn't have a proper connection to the tree-root! (Illegal Mount Point found in rootline)"</p>
<p>(issue imported from #M13739)</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 #16464 (Closed): Error message when uploading one or two files in file-browser (BE)http://forge.typo3.org/issues/164642006-08-13T11:36:52ZErnesto Baschnyeb@cron.eu
<p>Reproduce in 4.0.1 with:</p>
<p>- Create a "Text w/ images" <br />- Open the "File browser" in the field "Images:" <br />- In the file browser popup, enter exactly one or two images in "Upload Image:" (leaving at least one upload-field empty)<br />- File is uploaded, but error message appears: "No file was uploaded!"</p>
<p>This was not a problem in 4.0.0, but introduced with 4.0.1. It happens in all file-upload forms.</p>
<p>We expect an error just in case no file was uploaded at all.<br />(issue imported from #M4035)</p> TYPO3 Core - Bug #15902 (Closed): Calling PHP5-only iconv functions in PHP4http://forge.typo3.org/issues/159022006-03-27T10:58:03ZErnesto Baschnyeb@cron.eu
<p>A change in t3lib_cs that made it into RC2 (cvs diff -r 1.53 -r 1.54 t3lib/class.t3lib_cs.php) added some functions that are only available on PHP5 if the user chooses "iconv" (iconv_substr, iconv_strlen, iconv_strpos, iconv_strrpos). If using PHP4 with iconv support, I will get lots of errors:</p>
<p>Fatal error: Call to undefined function: iconv_strlen() in ....t3lib/class.t3lib_cs.php on line 1388</p>
<p>Attached patch checks if the functions are available before calling them.<br />(issue imported from #M2994)</p> TYPO3 Core - Bug #14984 (Closed): Editpanel confirm dialogs (del/hide) don't display umlauts/etchttp://forge.typo3.org/issues/149842005-09-21T12:57:08ZErnesto Baschnyeb@cron.eu
<p>The edit panel has a hide and delete buttons that open a javascript confirmation dialog. This works nice in englisch, but if the user has set the BE-language to a language that uses non-ascii chars in these strings (e.g. german), the confirmation dialogs appear with these characters displayed as URL-encoded UTF-8 entities.</p>
<p>The problem is that javascript dialogs doesn't support URL-encoded strings and not even UTF-8 entities.</p>
<p>The attached patch solves the problem, and allows us to display the confirmation prompts with umlauts etc. The solution is:</p>
<p>1) t3lib_tsfebeuserauth::extGetLL has a new parameter, allowing us to return the string in the default charset that the BE-user is using (instead of UTF-8 entities)<br />2) In tslib_content::editPanel we now get the strings for "hideConfirm" and "deleteConfirm" using this new parameter<br />3) In tslib_content::editPanelLinkWrap the $confirm parameter goes through $GLOBALS['LANG']->JScharCode() to get properly encoded and displayed in the dialog.</p>
<p>The attached patch was created for current CVS-head, but also applies to TYPO3 3.8.0 nicely.<br />(issue imported from #M1472)</p>