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 #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 - Bug #53940 (Rejected): Extension name is not case insensitive in anymorehttp://forge.typo3.org/issues/539402013-11-25T15:30:01ZErnesto Baschnyeb@cron.eu
<p>The extension "abaticker" for example contains something like:</p>
<pre>
t3lib_extMgm::addPlugin(Array("LLL:EXT:abaTicker/locallang_db.php:tt_content.list_type_pi1", $_EXTKEY."_pi1"),"list_type");
</pre>
<p>In 6.2 this now fails with:</p>
<p>"TYPO3 Fatal Error: Extension key "abaTicker" is NOT loaded" (Exception 1365429656)</p>
<p>So the ExtensionManagementUtil API doesn't seem to be backwards compatible yet (i.e. extPath() etc), as it doesn't seem to expect different CaSe for the passed extension key.</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 - Bug #52812 (Rejected): Installing extension bringes 'Package "xy" is not available'http://forge.typo3.org/issues/528122013-10-14T19:09:26ZErnesto Baschnyeb@cron.eu
<p>If I copy an extension directory to typo3conf/ext/ and try to install it using the Extension Manager (it is listed already), I get:</p>
<pre><code>#1166546734: Package "xy" is not available. Please check if the package exists and that the package key is correct (package keys are case sensitive). (More information)</code></pre>
<p>The problem is that the PackageStates file is not up-to-date: it does not include this new package which was just copied there without the knowledge of the Package Management.</p>
<p>Since this is not so uncommon, I would propose to re-create the PackageStates.php file as soon as the Extension Manager tries to do something with packages to make sure it is in sync with the reality - just like it behaved before.</p> TYPO3 Core - Feature #51538 (Rejected): Move old css_styled_content static templates to own exten...http://forge.typo3.org/issues/515382013-08-29T18:13:37ZErnesto Baschnyeb@cron.eu
<p>css_styled_content provides several static templates that enable to render the frontend in the same way as some older TYPO3 version. We currently ship static templates as old as TYPO3 3.8. The whole list appears in the "Include Template from Extension" list and the list is getting longer each release.</p>
<p>To make it clearer that these templates are not maintained anymore, and new installations should be given these by default, we decided to move these over to a new System Extension which is not installed by default, but can be installed through the Upgrade Wizard if someone decides to stay with older compatibility version.</p>
<p>Proposal for new extension name: csc_oldtemplates</p>
<p>We decided to keep the extension in the core thou so that potential changes and fixes could be more easily be done by the core team itself directly in the core.</p> TYPO3 Core - Bug #42890 (Rejected): Regression: Javascript error in Backend (jumpToUrl)http://forge.typo3.org/issues/428902012-11-12T17:50:56ZErnesto Baschnyeb@cron.eu
<p>All checkboxes in the Backend that contain a "onclick" pointing to "jumpToUrl" seem to be broken in the latest release of TYPO3. The Javascript pops up an error:</p>
<p>Uncaught ReferenceError: Invalid left-hand side in assignment</p>
<p>To test, go to the list module and try to select "Extended View" or "Localization View" from the options beneath the list.</p>
<p>Or in Extension Manager (the old-old one), try to select "Display shy extensions"</p>
<p>Tested on 4.5.x, but should affect also the latest security releases of the other branches as well.</p> TYPO3 Core - Bug #24873 (Closed): Open forms cannot be saved after "Relogin" (Security Token errors)http://forge.typo3.org/issues/248732011-01-28T11:17:58ZErnesto Baschnyeb@cron.eu
<p>If you have an open form (e.g. editing a content element) and you leave your browser unattended until "session expires", you can relogin with the popup window (or the JS overlay).</p>
<p>After this relogin, if you try to save your work, you will get security token errors.</p>
<p>The CSRF protection token is in a hidden field, and if the session has expired in the meantime, the session data (including the original tokens) are gone, so when saving that form after the relogin won't be able to validate them. Different potential solutions:</p>
<p>a) go through the DOM and manipulate all hidden fields with a token and change them with a new valid token. doable, but will require some work<br />b) allow "one save without token check" right after the relogin, so that this form can be finally saved, and after that things continue as usual.</p>
<p>(issue imported from #M17383)</p> TYPO3 Core - Feature #24850 (Rejected): After the last Upgrade Wizard, a link to "COMPARE" should...http://forge.typo3.org/issues/248502011-01-27T11:27:34ZErnesto Baschnyeb@cron.eu
<p>After the last Upgrade Wizard is through, we should present a last Next button which links to the "COMPARE" screen.</p>
<p>This could even be integrated in a standalone "Wizard" so that the DB compare is done cleanly in the Upgrade Wizard path, so that after that the user is presented with a "Congratulation" message and some other nice words.</p>
<p>(issue imported from #M17354)</p> TYPO3 Core - Bug #12000 (Closed): Topbar: Cache and Favorites submenus shifts when in Workspaceshttp://forge.typo3.org/issues/120002011-01-07T18:44:03ZErnesto Baschnyeb@cron.eu
<p>Hi,</p>
<p>in Live mode, the Cache (and Favorites) submenu is positioned correctly:</p>
<p><img src="http://forge.typo3.org/attachments/download/4885/clear-cache-live-position.png" alt="" loading="lazy" /></p>
<p>As soon as you switch to a Draft Workspace (thus getting the dashed top bar), the position of the submenu is wrong:</p>
<p><img src="http://forge.typo3.org/attachments/download/4886/clear-cache-ws-position.png" alt="" loading="lazy" /></p>
<p>It seems that it shifts exactly the size of the Workspace name which is added on the top bar:</p>
<p><img src="http://forge.typo3.org/attachments/download/4887/clear-cache-ws-position-2.png" alt="" loading="lazy" /></p> TYPO3 Core - Bug #24268 (Closed): Install Tool is unuseable with newest DBALhttp://forge.typo3.org/issues/242682010-12-01T20:56:46ZErnesto Baschnyeb@cron.eu
<p>See <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Install Tool is unuseable since DBAL merge (switches to a very ugly "123" mode) (Closed)" href="http://forge.typo3.org/issues/24267">#24267</a>, has been fixed in core's trunk already. Please port the fix to the extension!</p>
<p>(issue imported from #M16640)</p> TYPO3 Core - Feature #24145 (Closed): Provide a pass-through flag for sql_exec() which goes direc...http://forge.typo3.org/issues/241452010-11-20T17:45:45ZErnesto Baschnyeb@cron.eu
<p>DBAL currently tries to parse queries passed to it via sql_exec(). This is marked as "experimental" in 4.4 but brings lots of troubles on complex queries, for example the queries generated by Extbase.</p>
<p>The idea of parsing the queries is that DBAL also has to handle "mappings" for tables.</p>
<p>A new feature proposed by Xavier would enable the caller to "pass-through" the sql_exec() directly to the underlying MySQL native driver, meaning no parsing at all in DBAL. This would allow running Extbase <strong>only</strong> on MySQL but at least work even if DBAL is active.</p>
<p>This is an intermediate fix which should be added to 4.5 to rise the usage of both DBAL and Extbase at the same time. Keep in mind that with this change, Extbase will work <strong>only</strong> on MySQL (as it currently does anyway).</p>
<p>In future release of TYPO3, this problem might be solved already, as soon as their is either a query-generation API in DBAL and/or some enhancements on the Extbase side of query generation.</p>
<p>(issue imported from #M16491)</p> TYPO3 Core - Bug #24057 (Closed): Install tool cannot compare "ENGINE" of MySQL Tables when DBAL ...http://forge.typo3.org/issues/240572010-11-15T11:23:11ZErnesto Baschnyeb@cron.eu
<p>In core rev. 3365 (2008, was included in 4.2beta3), Stucki implemented a way of the Install Tool "COMPARE DATABASE" to change the Engine of a database. This does not work with DBAL enabled, because that change in t3lib_db was not ported to DBAL.</p>
<p>You end up with the same suggestions over and over again (to change Engine to "InnoDB" while the tables are already InnoDB).</p>
<p>(issue imported from #M16392)</p> TYPO3 Core - Bug #23383 (Closed): Not able to select multiple records in recycler since refactoringhttp://forge.typo3.org/issues/233832010-08-16T13:40:00ZErnesto Baschnyeb@cron.eu
<p>Since issue <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Refactor of recycler (Closed)" href="http://forge.typo3.org/issues/20967">#20967</a> was commited (rev. 8606), we are no longer able to select multiple records on the left side (checkboxes).</p>
<p>(issue imported from #M15467)</p> TYPO3 Core - Feature #14894 (Closed): stdWrap.age should differenciate between singular/pluralhttp://forge.typo3.org/issues/148942005-08-02T13:39:17ZErnesto Baschnyeb@cron.eu
<p>The .age stdWrap parameter currently only allows us to specify " min| hrs| days| yrs", which will also show plural text if we have a quantity of "1". The attached patch (for typo3/sysext/cms/tslib/class.tslib_content.php) changes the possible value of the .age setting to allow 8 values:</p>
<p>" min| hrs| days| yrs| min| hour| day| year"</p>
<p>The second set is the singular variant. So we can have outputs like "1 hour" and "1 year". It remains backwards compatible, in that older TYPO3 (with newer TypoScript) will still show the "good-old" plural variants.</p>
<p>In a remote future this text should become language-dependent, so that we have different outputs depending on the language of the site. This should also be prepared for situations where not always is the "1" unit singular and all others plural. There are languages where there are other rules for plurals (see gettext, PO-setting "Plural-Forms").<br />(issue imported from #M1333)</p>