TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692014-07-27T15:34:20ZTYPO3 Forge
Redmine TYPO3 Core - Task #60622 (Rejected): Deprecate getUrl, curlProxyServer and encourage usage of HTT...http://forge.typo3.org/issues/606222014-07-27T15:34:20ZErnesto Baschnyeb@cron.eu
<p>The SYS.curl* settings are being used by GeneralUtility::getUrl and openid. And probably other extensions are using that too.</p>
<p>Since 6.0 we have the nice HttpRequest adapter for the PEAR HTTP_Request2 component, which is a full replacement of what our old getUrl does.</p>
<p>So we want to deprecate getUrl along with the curl* settings.</p> TYPO3 Core - Task #56960 (Closed): Adjust sys_notes styling according to UX teamhttp://forge.typo3.org/issues/569602014-03-16T14:41:36ZErnesto Baschnyeb@cron.eu
<p>Adjust CSS and styling of sys notes according to the definitions of the UX team. See #26796.</p> TYPO3 Core - Task #56538 (Closed): Cache the $GLOBALS['TYPO3_LOADED_EXT'] as an arrayhttp://forge.typo3.org/issues/565382014-03-04T15:28:03ZErnesto Baschnyeb@cron.eu
<p>Several core components still access $GLOBALS['TYPO3_LOADED_EXT'] directly. Basically it's used to loop through the activated extensions and also to check if some extension is installed.</p>
<p>Since the Package Management, this array is being simulated by an object (LoadedExtensionsArray). Plan was to be able to add deprecation messages for accessing this array in future.</p>
<p>When accessing a FE with one USER_INT, accessing this object takes about 10% of the time.</p>
<p>It should be considered if we cannot generate the original array on first request, cache it, and then make the GLOBAL array available again to whoever uses it. It's just a list of extensions. The gain of the future possibility of throwing a deprecation message opposed to simply having this array as an array and be fast is probably not worth it.</p> TYPO3 Core - Task #54883 (Closed): Document that TYPO3 CMS is not compatible with MySQL strict modeshttp://forge.typo3.org/issues/548832014-01-09T18:00:11ZErnesto Baschnyeb@cron.eu
<p>TYPO3 is not currently compatible with MySQL configured with "STRICT_TRANS_TABLES" or "STRICT_ALL_TABLES" enabled.</p>
<p>There are currently several issues with this: <a class="issue tracker-1 status-6 priority-4 priority-default closed child" title="Bug: SQL error: 'Incorrect integer value: '' for column 'storage_pid' at row 1' (pages:NEW499d21cdec168) (Rejected)" href="http://forge.typo3.org/issues/20052">#20052</a>, <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Unable to create a page (Closed)" href="http://forge.typo3.org/issues/21212">#21212</a>, <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Unable to login into BE when using MySQL 5+ (Closed)" href="http://forge.typo3.org/issues/15295">#15295</a>, <a class="issue tracker-1 status-5 priority-4 priority-default closed child" title="Bug: Installer will not create any be_users if unsupported sql_mode is used (Closed)" href="http://forge.typo3.org/issues/18821">#18821</a> and probably many more.</p>
<p>So while this is not solved (if even possible...) we should document how to configure MySQL to avoid this situation, because several "mysql installation documentation" (i.e. on Windows) recommend setting "STRICT_ALL_TABLES" by default.</p> TYPO3 Core - Epic #54542 (Closed): WP: Importer / Exporter with relations MM/IRRE/FALhttp://forge.typo3.org/issues/545422013-12-20T21:49:35ZErnesto Baschnyeb@cron.eu
<p>The import and export functionality is available since the beginning of TYPO3 CMS. This backend module mostly relies on the internal DataHandler/TCEMain system of TYPO3. For TYPO3 6.2 LTS, the Core Team needs to improve the handling of the IRRE and MM relations within the import and export process.<br />Additionally, the import / export module must be able to handle exports which were generated in a pre-FAL-version of TYPO3 (e.g. like the last LTS Version 4.5) in order to be able to import directly to the FAL.<br />Since importing and exporting large sites via a web-backend leads to problems in runtime and memory limits, a CLI Module must be added.</p>
<p>Epic for the work-package dealing with fixes in the Importer/Exporter module for inclusion in TYPO3 6.2 LTS.</p>
<p>Please do not add sub-tasks to this on your own, instead contact the release manager (Ernesto) before.</p> TYPO3 Core - Epic #54260 (Closed): WP: FAL Missing Issues / Features / APIhttp://forge.typo3.org/issues/542602013-12-07T14:56:05ZErnesto Baschnyeb@cron.euTYPO3 Core - Epic #53915 (Closed): Usability and timing issues in Pagetreehttp://forge.typo3.org/issues/539152013-11-25T00:37:06ZErnesto Baschnyeb@cron.eu
<p>The page tree has some problems when it has to deal with long running tasks:</p>
<p>- delete whole tree<br />- copy tree with lots of childs<br />- etc...</p>
<p>This umbrella-issue should try to collect these so that they can be tackled at once.</p> TYPO3 Core - Task #53814 (Closed): Doc-Module: Unclear different between "Manage" and "Show" Docu...http://forge.typo3.org/issues/538142013-11-20T21:33:43ZErnesto Baschnyeb@cron.eu
<p>As noted by the UX team, the selector between "Show" and "Manage" is confusing, as the difference is not quite clear at first.</p>
<p>See this comment:</p>
<p><a class="external" href="https://projects.invisionapp.com/share/H2IU7YVE#/screens/10260005/comments/6168385">https://projects.invisionapp.com/share/H2IU7YVE#/screens/10260005/comments/6168385</a></p>
<p>Not even to me it is clear what view is showing me what, and what exactly the "Download" does (because as an user, I expect to be able to "Download" the documentation myself.</p>
<p>Maybe rephrasing the menu items would be a better fit, or even merge the functionality in a single view? Why would I want to differentiate between "showing" or "managing"? We could display the whole list and then provide according actions depending if it has already been fetched locally or not.</p>
<p>@Xavier, would be great to have some input from you on that matter. Thanks!</p> TYPO3 Core - Task #53681 (Closed): Change wording for User Settings "Reset Configuration and Clea...http://forge.typo3.org/issues/536812013-11-15T19:45:26ZErnesto Baschnyeb@cron.eu
<p>In #632 it was proposed to change the text of the User Settings, Admin, "Reset Configuration and Clear Temporary Data" and "Clear Temporary Data".</p>
<p>Moreover both button labels point to the same CSH, and for an user its not really clear what the difference is at all.</p>
<p>Suggestions from Jens (<a class="external" href="http://forge.typo3.org/issues/632#note-15">http://forge.typo3.org/issues/632#note-15</a>):</p>
<blockquote>
<ul>
<li>Reset Configuration and clear temporary data
<ul>
<li>= Reset user settings</li>
</ul>
</li>
<li>Clear Temporary data
<ul>
<li>= Reset backend states</li>
<li>= Clear backend caching</li>
<li>= Remove Temporary Settings</li>
<li>= Reset interface states</li>
<li>.. other Ideas?</li>
</ul></li>
</ul>
</blockquote>
<p>Suggestions from Steffen R:</p>
<blockquote>
<ul>
<li>"Reset your backend status (open folders, list setting, tree collapse states, last open tabs..." </li>
<li>"Restore this form to default" :)</li>
</ul>
</blockquote> TYPO3 Core - Task #53651 (Closed): Bring back module menu accordionshttp://forge.typo3.org/issues/536512013-11-14T23:56:08ZErnesto Baschnyeb@cron.eu
<p>The accordion arrows (down and to the right) were dropped during the "become spacious" patch (<a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Follow-up: Docheader fall-back become spacious (Closed)" href="http://forge.typo3.org/issues/49735">#49735</a>).</p>
<p>The missing accordion arrows were missed by some and also the UX team noted that its not clear anymore that those sections can be expanded and collapsed for a new user.</p>
<p>See also comments here:<br /><a class="external" href="https://projects.invisionapp.com/d/main#/console/481308/10259949/comments/6159633">https://projects.invisionapp.com/d/main#/console/481308/10259949/comments/6159633</a></p>
<p>So we should bring back the accordion arrows.</p> TYPO3 Core - Task #51435 (Closed): Document css_styled_content rendering changes in compat_versionhttp://forge.typo3.org/issues/514352013-08-28T12:01:16ZErnesto Baschnyeb@cron.eu
<p>We have an array in css_styled_content in ext_localconf.php (compat_version) which is used by the Upgrade Wizard to inform the user of what has changed in the FE-rendering if he "upgrades" his compat version to the latest version (which is recommended).</p>
<p>The rule in the Core has been to add an entry for every change that was made to the rendering in css_styled_content. This hasn't been done since 4.5 as it seems, which then results in the upgrader not getting any info at all at this point of the wizard what has been changed.</p>
<p>In the sense of Smooth migration we should at least document the major changes since 4.5 to the 6.2 version. I would propose not to backport these back to 4.6 .. 6.1 as it is not worth it. And we don't need to document every individual step but instead could summarize the major changes that happened between the versions instead.</p> TYPO3 Core - Task #49110 (Closed): Cleanup ChangeLoghttp://forge.typo3.org/issues/491102013-06-13T23:10:22ZErnesto Baschnyeb@cron.eu
<p>On release of 6.2.0alpha1 the ChangeLog was automatically filled in with the history of the changes since 6.1.0.</p>
<p>Since during that time also the submodules were integrated into our git repositories. also the whole history of the former submodules now appear at this position of the ChangeLog.</p>
<p>Remove it and keep only the Core history again.</p>
<p>Will work out correctly on alpha2 again, when changes of all sysext will be included in the main ChangeLog.</p> TYPO3 Core - Task #29802 (Closed): Add SwiftMailer license exception to be included in TYPO3v4http://forge.typo3.org/issues/298022011-09-15T11:58:51ZErnesto Baschnyeb@cron.eu
<p>SwiftMailer Library, which is included since TYPO3v4 as the engine behind "t3lib_mail" in typo3/contrib/swiftmailer is licensed LGPLv3. This is not per-se includeable in a GPLv2 product as TYPO3v4 is.</p>
<p>So we've got an exception from the SwiftMailer author, which will be included in typo3/contrib/swiftmailer/LICENSE.TYPO3v4-Exception.</p> TYPO3 Core - Task #24900 (Closed): "Version Compatibility" Upgrade Wizard should not be displayed...http://forge.typo3.org/issues/249002011-01-31T10:47:55ZErnesto Baschnyeb@cron.eu
<p>The "Version Compatibility" wizard will always show up, even if nothing was changed to the FE rendering. So the user is left with a dialog which is pretty confusing (see screenshot upgrade-wizard-compatVersion.png).</p>
<p>Solution: only call this wizard if there is there is something to do.<br />(issue imported from #M17415)</p> TYPO3 Core - Epic #24849 (Closed): Upgrade Wizard Usabilityhttp://forge.typo3.org/issues/248492011-01-27T11:06:34ZErnesto Baschnyeb@cron.eu
<p>The Upgrade Wizard of TYPO3 still lacks a better usability.</p>
<p>This is an umbrella-issue to collect the issues which we should solve in future TYPO3 versions.</p>
<p>Please add other issues which describe bugs, issues and problems with the Upgrade Wizard as a <strong>child</strong> of this issue. Thanks!</p>
<p>(issue imported from #M17353)</p>