TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692017-09-05T15:00:28ZTYPO3 Forge
Redmine TYPO3 Core - Bug #82304 (Closed): ConfigurationManager::writeLocalConfiguration breaks log writer...http://forge.typo3.org/issues/823042017-09-05T15:00:28ZThorsten Kahler
<p>Method <code>\TYPO3\CMS\Core\Configuration\ConfigurationManager::writeLocalConfiguration()</code> cleans up <code>$TYPO3_CONF_VARS</code> before writing to <code>typo3conf/LocalConfiguration.php</code>. It uses the cleanup method <code>ArrayUtility::renumberKeysToAvoidLeapsIfKeysAreAllNumeric()</code> which rewrites the indices of numerically indexed arrays.</p>
<p>This cleanup breaks <code>$TYPO3_CONF_VARS['LOG']['writerConfiguration']</code> because the configuration uses log level constants which represent integers (see class <code>\TYPO3\CMS\Core\Log\LogLevel</code>) as indices.</p>
<p>Either exceptions for those cleanups must be configurable or (better) this optimization attempt should be dropped at all.</p> TYPO3 Core - Bug #55768 (Closed): Drag & drop in Workspaces moves live pagehttp://forge.typo3.org/issues/557682014-02-07T16:56:09ZThorsten Kahler
<p><code>\TYPO3\CMS\Backend\Tree\Pagetree\Commands::createNode()</code> unnecessarily triggers a move operation when creating a new page. This already lead to following bugs:</p>
<ul>
<li><a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: create/move initial-placeholder page behind move-placeholder page broken. (Closed)" href="http://forge.typo3.org/issues/33104">#33104</a> (creating page after moved page)</li>
<li><a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: unnecessary moveNode in class.t3lib_tree_pagetree_commands.php createNode() (Closed)" href="http://forge.typo3.org/issues/39820">#39820</a> (comparison ignoring datatype)</li>
</ul>
<p>The "solution" for <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: create/move initial-placeholder page behind move-placeholder page broken. (Closed)" href="http://forge.typo3.org/issues/33104">#33104</a> caused this new bug when moving pages in a workspace via drag & drop: pages, which are positioned below a page that has been moved in that workspace before, cause their live versions to be moved, too.</p>
<p>The move operation in <code>\TYPO3\CMS\Backend\Tree\Pagetree\Commands::createNode()</code> can be dropped completely, because <code>DataHandler</code> does all necessary steps when using a negative pid in the datamap.</p> TYPO3 Core - Bug #55698 (Closed): Wrong and missing label in EXT:beloghttp://forge.typo3.org/issues/556982014-02-05T16:05:57ZThorsten Kahler
<p>The label <code>action_1_5</code> is missing in the <code>locallang.xlf</code> file of system extension belog. It has been mixed up with <code>action_1_4</code>.</p>
<p>IS:</p>
<ul>
<li>action_1_4: "Check" </li>
<li>action_1_5: missing</li>
</ul>
<p>SHOULD:</p>
<ul>
<li>action_1_4: "Move" </li>
<li>action_1_5: "Check"</li>
</ul>
<p>See labels <code>msg_1_4_x</code> and <code>msg_1_5_x</code> for reference.</p> TYPO3 Core - Bug #52848 (Rejected): ClassLoader fails when typo3temp is symlinkhttp://forge.typo3.org/issues/528482013-10-15T15:06:51ZThorsten Kahler
<p>Method <code>\TYPO3\CMS\Core\Cache\Backend\ClassLoaderBackend::setLinkToPhpFile()</code> uses <code>__DIR__</code> to construct the path to the file to be included. This fails when folder <code>typo3temp</code> is symlinked.</p>
<p>Quick fix: use <code>getcwd()</code> instead of <code>__DIR__</code>. But since the constructed files are caches for path resolving (as far as I understand) the absolute path should be written to the cache (= PHP file) instead of being calculated there.</p> TYPO3 Core - Bug #52700 (Closed): Change delete icon in context menu if record is deletedhttp://forge.typo3.org/issues/527002013-10-11T13:52:24ZThorsten Kahler
<p>If a record is deleted in a workspace the delete icon in the context menu of the <em>list module</em> is still displayed but the function is different. If you click on the delete icon of a deleted record you will "restore" the record (remove the deleted flag).<br />So the icon should change if record is marked as deleted.</p> TYPO3 Core - Task #52463 (Closed): Don't register destructor as shutdown functionhttp://forge.typo3.org/issues/524632013-10-02T12:13:58ZThorsten Kahler
<p>PHP knows the destructor method <code>__destruct()</code> since PHP 5.0 (July 2004).</p>
<p>In <code>\TYPO3\CMS\Core\Utility\GeneralUtility::makeInstanceService()</code> the method <code>__destruct()</code> is still registered as shutdown function. This requirement prevents classes without destructor method to be registered as TYPO3 service.</p>
<p>This workaround for PHP 4.x can be removed since 5.2 is required for many years now.</p> TYPO3 Core - Feature #51731 (Closed): Store sessions outside DBhttp://forge.typo3.org/issues/517312013-09-04T16:46:10ZThorsten Kahler
<p>On high traffic sites it's sometimes necessary to store session records outside the main database because of a high rate of <code>update</code> queries on the FE session tables. This issue becomes even more pressing when using DB replication or remote database servers.</p>
<p>I suggest to add a session storage service so it can be implemented to use different storage backends. These storage backend implementations can be based on caching backends or totally unrelated to the core.</p> TYPO3 Core - Task #45937 (Closed): Deprecate class FE_loadDBGrouphttp://forge.typo3.org/issues/459372013-03-01T12:16:26ZThorsten Kahler
<p>Class <code>FE_loadDBGroup</code> only changes a single attribute in comparison to its parent class <code>\TYPO3\CMS\Core\Database\RelationHandler</code>. This can easily be set after instantiation.</p>
<p>So I suggest to mark this class as deprecated in TYPO3 6.1 and drop it in TYPO3 6.3.</p>
<p>Additionally the mentioned attribute <code>\TYPO3\CMS\Core\Database\RelationHandler::$fromTC</code> should be renamed to make its purpose clearer.</p> TYPO3 Core - Bug #37611 (Closed): Current page has to be checked when changing workspaceshttp://forge.typo3.org/issues/376112012-05-30T15:23:34ZThorsten Kahler
<p>IS:<br />When switching to another workspace there's no check if the current page is available in that workspace. This leads to nonsense output in most submodules of the web module.</p>
<p>SHOULD:<br />When switching to another workspace it should be checked if the current page is available in the target workspace. If not the next available page in the rootline should be selected.</p> TYPO3 Core - Bug #37209 (Closed): Workspace preview shows pages changes from all workspaceshttp://forge.typo3.org/issues/372092012-05-16T12:21:23ZThorsten Kahler
<p>When working with more than one workspace (besides LIVE) the preview shows changes in the table <code>pages</code> from all workspaces.</p>
<p>This can be solved by enhancing the condition in <code>t3lib_pageSelect::init()</code> to select only pages from current workspace and workspace 0 (LIVE).</p> TYPO3 Core - Bug #37065 (Closed): Workspace preview (FE) shows duplicate recordshttp://forge.typo3.org/issues/370652012-05-10T14:37:56ZThorsten Kahler
<p>When in workspace preview versioned records, which are selected by any relation (except <code>uid</code> or <code>pid</code>) are shown twice: the original record and the versioned record.</p>
<p>This is caused by a wrong condition in <code>t3lib_pageSelect::enableFields()</code>: the selection on <code>pid<>-1</code> should only be added if parameter <code>$noVersionPreview</code> is false. The parameter is only set to true to retrieve version overlays of specific records (see <code>t3lib_pageSelect::getWorkspaceVersionOfRecord()</code>).</p>
<p>Steps to reproduce:</p>
<ol>
<li>Install (and configure) EXT:blog_example</li>
<li>create blog record (live)</li>
<li>create blog post record (live)</li>
<li>switch to any workspace</li>
<li>edit blog post (workspace)</li>
<li>open preview of page containing "list of blogs" plugin</li>
</ol>
<p>This shows the blog created above containing two blog posts (in workspace frame).</p> TYPO3 Core - Story #28743 (Rejected): Add method to send no-cache HTTP headershttp://forge.typo3.org/issues/287432011-08-04T10:47:10ZThorsten Kahler
<p>In <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: jumpurl secure links over HTTPS fail in Internet Explorer when BE user logged in (Closed)" href="http://forge.typo3.org/issues/24125">#24125</a> the sending of HTTP <code>Cache-Control</code> and <code>Pragma</code> headers which disable caching is fixed for logged in FE and BE users using IE.</p>
<p>The same code should be available for all places that trigger disabling of client side caches.</p>
<p>Suggestion: add new method <code>sendNoCacheHeaders()</code> to class <code>t3lib_utility_Http</code> and use it everywhere in the core where applicable.</p> TYPO3 Core - Bug #28700 (Closed): cli_dispatch.phpsh does not return error codehttp://forge.typo3.org/issues/287002011-08-03T15:30:16ZThorsten Kahler
<p>IS: cli_dispatch.phpsh always exits with exit status 0.</p>
<p>SHOULD: Failed CLI runs should return an exit status != 0 so success of CLI run can be checked in automated scripts.</p> TYPO3 Core - Bug #24958 (Closed): BE forms: language selector show superfluous recordshttp://forge.typo3.org/issues/249582011-02-04T16:30:52ZThorsten Kahler
<p>The language selector in the top of BE forms is intended to show (and switch between) all translations of a certain record.</p>
<p>If there are records in non-default languages, that are not bound to a record in the default language, they are shown as different translations of each other.</p>
<p>1) Create two records of the same kind (tt_content, tt_news, ...) on the same page and associate them to different languages.<br />2) Open one of them in the edit form.<br />3) Selecting the other language in the language select box at the top will open the absolutely unrelated other record.</p>
<p>The reason is that it's not checked in SC_alt_doc::languageSwitch() if there's any value set in $transOrigPointerField (usually: l18n_parent) at all.<br />(issue imported from #M17486)</p> TYPO3 Core - Bug #17310 (Closed): Wrong quoted-printable encoding of email headershttp://forge.typo3.org/issues/173102007-05-14T18:11:12ZThorsten Kahler
<p>For email header lines there are some special conditions. E.g. quotation marks are used to denote the transfer encoding (quoted-printable or base64).</p>
<p>The attached patch adds a distinction to t3lib_div::quoted_printable() to respect these cases.</p>
<p>Send an email (either with t3lib_htmlmail or t3lib_div::plainMailEncoded()) that has a quotation mark in the subject line.</p>
<p>(issue imported from #M5633)</p>