TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692012-03-27T13:25:09ZTYPO3 Forge
Redmine TYPO3 Core - Feature #35273 (Closed): l10n_mode option mergeIfNotBlank should handle empty ids co...http://forge.typo3.org/issues/352732012-03-27T13:25:09ZChristopher Hlubekhlubek@networkteam.com
<p>In <code>t3lib_pageSelect->getRecordOverlay</code> the <code>10n_mode</code> option <code>mergeIfNotBlank</code> disables an overlay for a field of a record if the value is the empty string. For records with relations and a <code>0</code> as default value this causes problems when translating these records. Using <code>exclude</code> as <code>l10n_mode</code> is not always possible since this disables the fields in backend forms.</p>
<p>We should introduce a new option that allows to skip the overlay of a field if the value is <code>0</code>.</p> TYPO3 Core - Bug #28948 (Closed): Session is always startedhttp://forge.typo3.org/issues/289482011-08-12T13:39:48ZChristopher Hlubekhlubek@networkteam.com
<p>We have severe problems with <code>fb_magento</code> after a recent change in TYPO3 4.5.4. The problem is, that the session is started before Magento is initialized.</p>
<p>I don't see any option in TYPO3 to disable the call to session_start or the FE user initialization at all.</p>
<p>I consider this as a bug, since in some setups you don't want a PHP session (e.g. websites without FE users and session storage) for performance reasons.</p> TYPO3 Core - Feature #20242 (Closed): Implement wrapper mysql_fetch_field in t3lib_dbhttp://forge.typo3.org/issues/202422009-03-26T17:00:36ZChristopher Hlubekhlubek@networkteam.com
<p>For the upcoming extbase object relational mapping we need the mysql_fetch_field method to fetch column information for a result set. There should be a wrapper for mysql_fetch_field in the t3lib_db class.</p>
<p>(issue imported from #M10786)</p> TYPO3 Core - Bug #25538 (Closed): On Mac Os X the key combination CMD+LEFT will close the editorhttp://forge.typo3.org/issues/255382008-07-25T17:25:33ZChristopher Hlubekhlubek@networkteam.com
<p>On Mac Os the key code CMD+LEFT will normally jump to the beginning of a line. If the keys are pressed in the editor (by habit), the editor will be closed and changes are lost, because this is the key combination for going back. The normal textarea doesn't have this problem, so for all Mac people this should be tweaked.</p>
<p>(issue imported from #M9051)</p> TYPO3 Core - Bug #19149 (Closed): Inter domain linking with typolinkEnableLinksAcrossDomains does...http://forge.typo3.org/issues/191492008-07-25T10:50:17ZChristopher Hlubekhlubek@networkteam.com
<p>Considering the following setup with multiple domains:</p>
<p>+ root (domain A, siteroot)
|<br /><ins>--</ins> Subsite (domain B, siteroot)
| |
| <ins>--</ins> Subpage
|<br /><ins>--</ins> Some Page
|<br /><ins>--</ins> Other Page</p>
<p>Even with typolinkEnableLinksAcrossDomains enabled, the links from the Subsite (domain B) back to domain A don't work.</p>
<p>In class.tslib_content.php (5324) there is a check, if the linked page shares a root page with the current page. It does! The newly added if for is_siteroot is not considered, because it is checked after the rootline. So the domain record for domain A will not be used!</p>
<p>I think a setup like the one mentioned above is quite common and desirable. Swapping the two if-statements solves the problem. But now for every link from a page in domain A to another page in domain A the domain record will be found, so it must be checked if adding the domain is necessary in the URL.</p>
<p>class.tslib_content.php (5324):</p>
<p>if ($tCR_data['is_siteroot']) {<br /> // Possibly subdomain inside main domain. In any case we must stop now because site root is reached.<br /> break;<br />}<br />if ($tCR_data['uid'] == $GLOBALS['TSFE']->tmpl->rootLine<sup><a href="#fn0">0</a></sup>['uid']) {<br /> $tCR_flag = 1; // OK, it was in rootline!<br /> break;<br />}</p>
<p>Don't generate unnecessary absolute urls:</p>
<p>class.tslib_content.php (5364):</p>
<p>if ($urlParts['host'] == '' && (t3lib_div::getIndpEnv('HTTP_HOST') != $tCR_domain)) {<br /> $LD['totalURL'] = 'http://' . $tCR_domain . ($LD['totalURL']{0} == '/' ? '' : '/') . $LD['totalURL'];<br />}</p>
<p>(issue imported from #M9046)</p> TYPO3 Core - Bug #25535 (Closed): On Mac OS the save action should be triggered by Cmd+shttp://forge.typo3.org/issues/255352008-05-28T16:58:01ZChristopher Hlubekhlubek@networkteam.com
<p>Currently the editor content can only be saved by the Ctrl+s keyboard shortcut. On Mac OS X it is common to use the Cmd+s shortcut (aka Apple+s) for saving.</p>
<p>(issue imported from #M8540)</p> TYPO3 Core - Bug #17351 (Closed): Backend forms show value "XX" in empty select lists in Firefox ...http://forge.typo3.org/issues/173512007-06-01T14:44:28ZChristopher Hlubekhlubek@networkteam.com
<p>Empty select lists (not drop-down) print the value "XX" after mouseover. This issue appeared in all of our independent installations (>4.1) after Firefox update to version 2.0.4, it doesn't appear in IE.</p>
<p>(issue imported from #M5728)</p> TYPO3 Core - Bug #17215 (Closed): Port number in lockSSL redirect is not configurablehttp://forge.typo3.org/issues/172152007-04-17T18:08:28ZChristopher Hlubekhlubek@networkteam.com
<p>Shared hosting environments often have limited ip addresses and name based virtual hosting is not an option for HTTPS webs.</p>
<p>Securing multiple TYPO3 webs (e.g. BE access) with SSL in virtual hosting environments with limited ip addresses is only possible using different HTTPS ports.</p>
<p>But the lockSSL option itself does only a redirect from <a class="external" href="http://{$url">http://{$url</a>} to <a class="external" href="https://{$url">https://{$url</a>} , which doesn't allow to change the port during redirect.</p>
<p>It would be nice to add a feature to configure the port in a configuration option like ($TYPO3_CONF_VARS['BE']['lockSSLPort'] and to append / exchange it in the hostname part of the url.</p>
<p>(issue imported from #M5442)</p> TYPO3 Core - Bug #17213 (Closed): Storing ENABLE_INSTALL_TOOL in typo3conf is possibly insecurehttp://forge.typo3.org/issues/172132007-04-17T16:22:51ZChristopher Hlubekhlubek@networkteam.com
<p>Since TYPO3 Version 4.1 the install tool can be enabled by placing an empty file ENABLE_INSTALL_TOOL in the typo3conf folder.</p>
<p>The directory typo3conf itself has to be writeable for the webserver (temp files, extensions, etc.). A possible attack would utilize an insecure extension or user generated php-code etc. to create this file, since the webserver has sufficient rights to do so!</p>
<p>The functionality in earlier versions was more secure concerning this attack, since the install tools index.php itself had to be changed and is not webserver writeable by default. But the old behaviour is not desireable in any way, because it was not possible to selectively enable the install tool on a single site.</p>
<p>Fixing this issue would mean to store the file in a folder that is not writeable for the webserver (needless to say, this depends on individual file permissions), e.g. htdocs or even some other directory outside htdocs.</p>
<p>Change<br />-------------------------------------------<br />$enableInstallToolFile = dirname(dirname(dirname($PATH_thisScript))).'/typo3conf/ENABLE_INSTALL_TOOL';<br />----------------- to ----------------------<br />$enableInstallToolFile = dirname(dirname(dirname($PATH_thisScript))).'/ENABLE_INSTALL_TOOL';</p>
<p>(issue imported from #M5440)</p> TYPO3 Core - Bug #17195 (Closed): Creation of multiple folders in filelist module results in blan...http://forge.typo3.org/issues/171952007-04-10T10:25:04ZChristopher Hlubekhlubek@networkteam.com
<p>In the filelist module, the creation of more than one new folder returns a blank page. The folders are created though.</p>
<p>This bug is reproducible in TYPO3 Versions 4.0.3 (maybe since 4.0) and 4.1.x too.</p>
<p>How to reproduce the bug:</p>
<p>Filelist Module -> New</p>
<p>Select 2 or more folders, name them e.g. "a","b". Click "Create folders".</p>
<p>-> Blank page!</p>
<p>(issue imported from #M5387)</p> TYPO3 Core - Feature #16615 (Closed): Add the ability to set a pid for logouthttp://forge.typo3.org/issues/166152006-10-02T13:30:01ZChristopher Hlubekhlubek@networkteam.com
<p>If the user logs out in a secured area of the site he will get a 404, cause after logging out the user isn't allowed to see the page.</p>
<p>This especially for sites that are using the more advanced 404 features of TYPO3 4.0.1, which is IMHO very good style to use (regarding search engine optimization, Google Sitemap, etc.).</p>
<p>An easy fix for this would be to set an optional configuration value for a logout pid, that's used as action for the logout form.</p>
<p>e.g.</p>
<hr />
<p>if ($GLOBALS['TSFE']->loginUser) {<br /> if ($logintype == 'login') {<br /> ...<br /> $action_pid = $GLOBALS['TSFE']->id;<br /> } else {<br /> ...<br /> $action_pid = isset($this->conf['logoutPid']) ? isset($conf['logoutPid']) : $GLOBALS['TSFE']->id;<br /> }<br /> ...<br /> $markerArray['###ACTION_URI###'] = htmlspecialchars($this->pi_getPageLink($action_pid, '_top'));<br /> ...<br />}<br />(issue imported from #M4318)</p>