TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692014-06-23T17:07:20ZTYPO3 Forge
Redmine TYPO3 Core - Task #59820 (Closed): Re-sync Extbase with TYPO3 Flow wherever possiblehttp://forge.typo3.org/issues/598202014-06-23T17:07:20ZMathias Brodalambrodala@pagemachine.de
<p>From time to time I stumble upon bugs in Extbase which apparently where fixed in TYPO3 Flow already. These fixes should have been backported to Extbase to keep it in sync.</p>
<p>Thus I'd like to request a re-sync of Extbase with TYPO3 Flow wherever it is possible.</p> TYPO3 Core - Bug #59324 (Closed): CLI command drops last line of method descriptionhttp://forge.typo3.org/issues/593242014-06-04T09:59:28ZMathias Brodalambrodala@pagemachine.de
<p>The CLI command drops the last line of method descriptions. Thus given the following doc comment:</p>
<pre>
/**
* My method
*
* My longer description for this method:
* it can span multiple lines.
*
* @param string $argument
* @return void
*/
</pre>
<p>The description ends up like this:</p>
<blockquote>
<p>My method</p>
<p>My longer description for this method:</p>
</blockquote>
<p>The actual wanted description is this:</p>
<blockquote>
<p>My longer description for this method:</p>
<p>it can span multiple lines.</p>
</blockquote>
<p>The issue seems to be an error while porting the <code>Mvc\Cli\Command::getDescription</code> method from TYPO3 Flow. While TYPO3 Flow uses <code>array_shift</code> to drop the first line of the description (as stated with <code>... except for the first line ...</code>), Extbase uses <code>array_pop</code> which obviously removes the last line instead.</p>
<p>The fix is replacing <code>array_pop</code> with <code>array_shift</code>.</p>
<p>The bug can be seen in action easily by executing <code>./typo3/cli_dispatch.phpsh help help</code>.</p> TYPO3 Core - Bug #58719 (Closed): Invalid form/module token in wizardhttp://forge.typo3.org/issues/587192014-05-12T14:39:34ZMathias Brodalambrodala@pagemachine.de
<p>The OpenID wizard ("Add OpenID" next to the "OpenID identifier" backend user field) yields the following error upon submission of an OpenID identifier:</p>
<blockquote>
<p>#1392409507: Invalid form/module token detected. Access Denied!</p>
</blockquote>
<p>The issue occcurs due to an unnecessary `htmlspecialchars()` call in the `Wizard` class which yields an URL like this:</p>
<blockquote>
<p><a class="external" href="http://.../typo3/mod.php?M=wizard_openid&amp;moduleToken=">http://.../typo3/mod.php?M=wizard_openid&amp;moduleToken=</a>...</p>
</blockquote> TYPO3 Core - Bug #57289 (Closed): Respect additional configuration file for silent configuration ...http://forge.typo3.org/issues/572892014-03-25T14:44:38ZMathias Brodalambrodala@pagemachine.de
<p>The <code>SilentConfigurationUpgradeService</code> only uses values from the <code>LocalConfiguration.php</code> due to using <code>\TYPO3\CMS\Core\Configuration\ConfigurationManager::getLocalConfigurationValueByPath()</code>.</p>
<p>However, the <code>AdditionalConfiguration.php</code> may also contain user values for configuration settings which should be respected.</p>
<p>An example: if you move <code>SYS/encryptionKey</code> from <code>LocalConfiguration.php</code> to <code>AdditionalConfiguration.php</code> (e.g. to keep it out of a VCS), a new encryption key is generated in <code>SilentConfigurationUpgradeService::generateEncryptionKeyIfNeeded()</code> and stored every time the installation tool is accessed. The value from the <code>AdditionalConfiguration.php</code> should be considered instead. If the value is present in the <code>AdditionalConfiguration.php</code> but not in the <code>LocalConfiguration.php</code>, the value should not be written to the <code>LocalConfiguration.php</code>, of course.</p> TYPO3 Core - Bug #56812 (New): TCA fields without positioning added to last tab, not "Extended" tabhttp://forge.typo3.org/issues/568122014-03-12T12:59:26ZMathias Brodalambrodala@pagemachine.de
<p>TCA fields added via <code>ExtensionManagementUtility::addToAllTCAtypes</code> are appended to the <code>showitem</code> list of all types if no explicit positioning (e.g. <code>after:title</code>) has been requested.</p>
<p>By default this appends the fields to the "Extended" tab which is present by default and ready to receive all fields which are simply appended.</p>
<p>However, if one adds a new tab via <code>--div--</code> without explicit positioning with some fields, all unrelated fields without explicit positioning are now appended to this tab instead. The resulting <code>showitem</code> portion which makes the issue clear:</p>
<blockquote>
<p>--div--;LLL:EXT:cms/locallang_ttc.xlf:tabs.extended, --div--;LLL:EXT:myext/locallang_db.xml:mytab, tx_myext_myfield;;;;1-1-1, unrelated_field</p>
</blockquote>
<p>The new tab with the field <code>tx_myext_myfield</code> was simply appended to the <code>showitem</code> list, thus preventing the "Extended" tab from being the last. The <code>unrelated_field</code> is now placed in the new tab.</p>
<p>A temporary fix is to set a explicit position for the newly added tab; this ensures that the tab and its fields are not simply appended and leaves the "Extended" tab on the last position.</p>
<p>The real fix however would involve explicitely placing all fields without explicit positioning in the "Extended" tab. This way arbitrary tabs could be appended without unrelated fields showing up in them.</p>
<p>This issue affects all TYPO3 CMS versions.</p> TYPO3 Core - Bug #56160 (Closed): Exception in listQuery in DatabaseConnection never thrown (TYPO...http://forge.typo3.org/issues/561602014-02-20T17:17:10ZMathias Brodalambrodala@pagemachine.de
<p>The fix from <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Exception in listQuery in DatabaseConnection never thrown (Closed)" href="http://forge.typo3.org/issues/56135">#56135</a> needs to be applied to TYPO3 4.7 and 4.5 too.</p> TYPO3 Core - Task #56063 (Closed): Format new content element wizard links as inline-blockhttp://forge.typo3.org/issues/560632014-02-18T09:01:38ZMathias Brodalambrodala@pagemachine.de
<p>The links within the new content element wizard are currently rendered as default inline elements which allows only clicking on the actual text. Even clicking between title and description does not work.</p>
<p>The solution is simple: format these links as inline-block to make the whole link clickable.</p> TYPO3 Core - Feature #55757 (Closed): Add PageTSconfig analyzerhttp://forge.typo3.org/issues/557572014-02-07T12:26:47ZMathias Brodalambrodala@pagemachine.de
<p>Similar to what the Template Analyzer does for the TypoScript Object Browser an additional mod function for analyzing PageTS would be useful.</p>
<p>ATM one can only see the currently parsed PageTS for pages. It is impossible to find out where and how this configuration was set which makes debugging for larger sites harder than it should be.</p>
<p>A PageTSconfig analyzer could help here by showing the content of added PageTS files and dynamically added sections like <code>defaultPageTSconfig</code>.</p> TYPO3 Core - Bug #55153 (Closed): Duplicated translation entry for clear cache menu pageshttp://forge.typo3.org/issues/551532014-01-20T09:20:06ZMathias Brodalambrodala@pagemachine.de
<p>With <a class="changeset" title="[TASK] Cache menu needs clear namings and permissions With the introduction of the grouping mech..." href="http://forge.typo3.org/projects/typo3cms-core/repository/1749/revisions/1b83cad80a4cffe054faea3ec1f30d7b18389942">1b83cad</a> the clear cache menu items where reworked. This however introduced a duplicated translation entry for the "pages" item. (<code>rm.clearCacheMenu_pages</code>)</p> TYPO3 Core - Bug #53974 (Closed): Environment variables prefixed with REDIRECT_ ignoredhttp://forge.typo3.org/issues/539742013-11-26T11:16:07ZMathias Brodalambrodala@pagemachine.de
<p>Using Apache mod_rewrite in certain setups (mostly PHP in CGI mode) makes environment variables from original requests available in the target request as <code>REDIRECT_<envvar></code>, thus e.g. setting <code>TYPO3_DISABLED_CORE_UPDATER</code> becomes <code>REDIRECT_TYPO3_DISABLED_CORE_UPDATER</code>.</p>
<p>This should be handled transparently by <code>GeneralUtility::getIndpEnv()</code> and relevant locations be updated (e.g. <code>TYPO3_CONTEXT</code>, <code>TYPO3_DISABLE_CORE_UPDATER</code>).</p> TYPO3 Core - Task #53455 (Closed): Update backend page titlehttp://forge.typo3.org/issues/534552013-11-08T15:22:28ZMathias Brodalambrodala@pagemachine.de
<p>Since the introduction text of the install tool has been updated recently for 6.2 I think it is about time the page title of the backend is also updated to reflect the brand change. Thus "TYPO3 <version>" becomes "TYPO3 CMS <version>".</p> TYPO3 Core - Bug #53188 (Closed): REDIRECT_TYPO3_DISABLE_CORE_UPDATER ignoredhttp://forge.typo3.org/issues/531882013-10-29T08:38:13ZMathias Brodalambrodala@pagemachine.de
<p>Using Apache mod_rewrite in certain setups makes environment variables from original requests available in the target request as <code>REDIRECT_<envvar></code>, thus setting <code>TYPO3_DISABLE_CORE_UPDATER</code> becomes <code>REDIRECT_TYPO3_DISABLE_CORE_UPDATER</code>.</p>
<p>The latter is currently not considered by TYPO3, thus the core updater cannot be disabled via the environment variable and the mentioned setup.</p>
<p>See <a href="http://stackoverflow.com/a/9406994" class="external">this Stackoverflow</a> post for an explanation and <a href="https://github.com/apache/httpd/blob/e1fac1db26/modules/http/http_request.c#L389" class="external">link to the Apache source code</a>.</p> TYPO3 Core - Bug #52888 (Rejected): FIRST_INSTALL file is ignoredhttp://forge.typo3.org/issues/528882013-10-16T13:40:24ZMathias Brodalambrodala@pagemachine.de
<p>The <code>FIRST_INSTALL</code> file which may be used to have the TYPO3 installer automatically create the <code>ENABLE_INSTALL_TOOL</code> file is completely ignored in the new installer. In fact, a file search yields nothing.</p> TYPO3 Core - Bug #52880 (Closed): Class "\extDirect_DataProvider_BackenduserSettings" not foundhttp://forge.typo3.org/issues/528802013-10-16T10:00:20ZMathias Brodalambrodala@pagemachine.de
<p>Trying to create a template record on a fresh 6.2 beta1 installation fails:</p>
<pre>
Fatal error: Class '\extDirect_DataProvider_BackenduserSettings' not found in .../typo3/sysext/core/Classes/Utility/GeneralUtility.php on line 4149
</pre>
<p>A file search for this class name yields two <code>makeInstance</code> calls:</p>
<ul>
<li>typo3\sysext\backend\Classes\InterfaceState\ExtDirect\DataProvider.php:46 (<code>__construct()</code>)</li>
<li>typo3\sysext\backend\Classes\Tree\Pagetree\ExtdirectTreeCommands.php:361 (<code>addRootlineOfNodeToStateHash()</code>)</li>
</ul>
<p>It seems like the correct path is <code>\TYPO3\CMS\Backend\User\ExtDirect\BackendUserSettingsDataProvider</code> instead.</p> TYPO3 Core - Feature #51556 (Closed): Add custom data to errors in validatorshttp://forge.typo3.org/issues/515562013-08-30T11:16:05ZMathias Brodalambrodala@pagemachine.de
<p>It would be useful if validators could add custom data to errors which can be used to give additional hints to the user.</p>
<p>This could for example be the specific article name and amount missing until its minimum order amount is fulfilled. Error messages outputted in the form then could use this additional data to be as specific as possible.</p>