TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692015-03-30T07:18:22ZTYPO3 Forge
Redmine TYPO3 Core - Bug #66129 (Closed): ViewModuleController.php assumes wrong protocol when using $pag...http://forge.typo3.org/issues/661292015-03-30T07:18:22ZChristian Nöllechristian.noelle@typo3.org
<p>At line 78 in ViewModuleController.php the url_scheme 2 AND 0 interpreted as https - why is default (0) set to SSL?</p>
<pre>
if ($page['url_scheme'] == 2 || $page['url_scheme'] == 0 && \TYPO3\CMS\Core\Utility\GeneralUtility::getIndpEnv('TYPO3_SSL')) {
$protocol = 'https';
}
</pre> TYPO3 Core - Bug #34820 (Closed): t3lib_befunc::getViewDomain does not respect http/https schemehttp://forge.typo3.org/issues/348202012-03-14T09:46:03ZChristian Nöllechristian.noelle@typo3.org
<p>After yesterdays update bug <a class="external" href="http://forge.typo3.org/issues/30892">http://forge.typo3.org/issues/30892</a> was fixed. But that introduced a problem for us:</p>
<p>We have a https BE, which uses a non public domain on a custom port, which serves a multidomain setup. After introduction of this bugfix page previews are rendered using the correct domain name for this particular page. BUT: the call is using the https scheme used in the backend and not http. There is no valid certificate for the public domains, only for the non public be domain, so this results in an error for the user with untrusted certificate.</p> TYPO3 Core - Feature #33703 (Closed): Auto deactivation of scheduler task for saltedpasswordshttp://forge.typo3.org/issues/337032012-02-06T10:50:38ZChristian Nöllechristian.noelle@typo3.org
<p>As we all know, the scheduler task for saltedpasswords has a built in auto deactivation, which jumps in, when no more password updates are neccessary. In class.tx_saltedpasswords_tasks_bulkupdate.php one can find</p>
<pre>
/**
* @var boolean Whether or not the task is allowed to deactivate itself after processing all existing user records.
* @TODO: This could be set with an additional field later on.
* The idea is to not disable the task after all initial users where handled.
* This could be handy for example if new users are imported regularily from some external source.
*/
protected $canDeactivateSelf = TRUE;
</pre>
<p>which would be very handy to have. So I would like to make a request to make this configurable via em for saltedpasswords.</p> TYPO3 Core - Bug #25385 (Closed): Uploader is not replacing "Umlaute"http://forge.typo3.org/issues/253852011-03-24T13:19:29ZChristian Nöllechristian.noelle@typo3.org
<p>The upload routine in TYPO3 is not replacing the german Umlaute any more. This occurs with the flash but also for the old fashioned upload routine. <br />Once a file is uploaded it is stored with all the Umlaute and this is resulting in errors accessing this file for the users. Furthermore GM is failing to provide a thumbnail - if the file is a picture or a pdf.</p>
<p>If you try to rename that file, the rename routine is properly replacing those characters.</p>
<p>(issue imported from #M18026)</p> TYPO3 Core - Bug #24927 (Closed): Some css declarations for mime types in fileadmin missinghttp://forge.typo3.org/issues/249272011-02-02T10:08:25ZChristian Nöllechristian.noelle@typo3.org
<p>After switching to sprites in the fileadmin, I recognized that some filetypes are showing just an "x", where there should be a proper icon.</p>
<p>For example, .doc files are properly declared with the style "t3-icon-word", but there is no such class in the css. Hence the sprite is not getting properly addressed and the default of the sprite table - upper left icon - is shown.</p>
<p>(issue imported from #M17442)</p> TYPO3 Core - Bug #24916 (Closed): "Show Page" in contextmenu results in new browser windowhttp://forge.typo3.org/issues/249162011-02-01T14:15:32ZChristian Nöllechristian.noelle@typo3.org
<p>The link "show page" in the right-click menu of the pagetree is resulting in a new browser window beeing opened up. The "show page" button aside the other buttons in a page detail view is opening up a new tab in the browser.</p>
<p>User could find that inconsistent, two behaviours for the same thing.</p>
<p>Futhermore the pop-up blocker of the browser will prevent that windows from opening. The new tab will mostly work without adding the BE domain to a whitelist. <br />(issue imported from #M17431)</p>