TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692018-11-11T18:24:11ZTYPO3 Forge
Redmine TYPO3 Core - Bug #86909 (Closed): tt_content examples in "Page" module does not respect CTypes ad...http://forge.typo3.org/issues/869092018-11-11T18:24:11ZSoren Mallingsoren@meteko.dk
<a name="Case"></a>
<h2 >Case<a href="#Case" class="wiki-anchor">¶</a></h2>
<p>I've added a number of items to the tt_content field CType directly via Page TSconfig.</p>
<p>When I add a content element which is added via TSconfig, the backend print "INVALID VALUE (webability_[contentname])". This is due to the $CType_labels property being used for rendering is not taking what is added via TSconfig in to concern.</p>
<a name="Proposed-solution"></a>
<h2 >Proposed solution<a href="#Proposed-solution" class="wiki-anchor">¶</a></h2>
<p>I suggest that we streamline this access of content types, so changes made via tsconfig or any other condition is taken into account and returns a single point of getting these values.</p>
<p>Perhaps a more API-wise solution. A "Content Element Registry" of a kind.</p>
<p>Comments are welcome, I will love to put time into it.</p>
<p>This is finding and suggestion based on the work of EXT:autosite where TSconfig is playing a big part in keeping each pagetree/site clean.</p> TYPO3 Core - Bug #79128 (Closed): "Record history" is shown, even if hidden with TSConfighttp://forge.typo3.org/issues/791282017-01-01T22:50:26ZSoren Mallingsoren@meteko.dk
<p>The tsconfig</p>
<pre>options.showHistory = 0</pre>
<p>is not respected in TYPO3\CMS\Backend\Controller\EditDocumentController in the getButtons() method in the making of the buttonbar.</p>
<p>Actually, a "Record History" buttons is being rendered twice but the TSconfig condition is only checked once.</p>
<p>In the first case, a condition only checks if there is any history</p>
<p><a class="external" href="https://git.typo3.org/Packages/TYPO3.CMS.git/blob/HEAD:/typo3/sysext/backend/Classes/Controller/EditDocumentController.php#l1369">https://git.typo3.org/Packages/TYPO3.CMS.git/blob/HEAD:/typo3/sysext/backend/Classes/Controller/EditDocumentController.php#l1369</a></p>
<p>and then renders the button.</p>
<p>On line 1400</p>
<p><a class="external" href="https://git.typo3.org/Packages/TYPO3.CMS.git/blob/HEAD:/typo3/sysext/backend/Classes/Controller/EditDocumentController.php#l1369">https://git.typo3.org/Packages/TYPO3.CMS.git/blob/HEAD:/typo3/sysext/backend/Classes/Controller/EditDocumentController.php#l1369</a></p>
<p>the condition is checked with the "getNewIconMode" method and respect if it's hidden</p> TYPO3 Core - Bug #79127 (Needs Feedback): Responsive LiveSearch toolbar item is rendered no matte...http://forge.typo3.org/issues/791272017-01-01T20:11:56ZSoren Mallingsoren@meteko.dk
<p><em>This is a result of a rather large work on trying to make the TYPO3 backend custom for a project.</em></p>
<p>The backend layout file Main.html (EXT:backend/Resources/Private/Templates/Backend/Main.html) contains a rendering of a LiveSearchToolbarItem even though a person might not have access</p>
<pre>
<button class="topbar-button topbar-button-search t3js-topbar-button-search">
<core:icon identifier="actions-search" alternativeMarkupIdentifier="inline" />
</button>
</pre>
<p>This causes the search to be printed in responsive view. Since you don't have access to the toolbar item (checkAccess() method from ToolbarItemInterface) you don't get a printed LiveSearch to use.</p>
<p><strong>Solution suggestion</strong></p>
<p>This part of ToolbarItem rendering (including the User Settings wrench icon) could be grouped into a viewhelper to render avaialble toolbar items. Perhaps introduce a rendering API for such things (a section in Fluid, or whatever ways the rendering of the backend is going)</p> TYPO3 Core - Bug #52946 (Closed): ExtensionUtility::configurePlugin doesn't set typoscripthttp://forge.typo3.org/issues/529462013-10-18T11:47:06ZSoren Mallingsoren@meteko.dk
<p>Upgrading to 6.2 beta 1 I've experienced that</p>
<p>TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin -> \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addTypoScript doesn't register/writes the typoscript to the TypoScript Object Browser.</p>
<p>It writes it very well to $GLOBALS['TYPO3_CONF_VARS']['FE']['defaultTypoScript_' . $type . '.']</p>
<p>This seems to be a issue for Extbase only extension as EXT:gridelements got it's typoscript written as it used to</p> TYPO3 Core - Feature #50360 (Accepted): Having only one record type in "New record" should forwar...http://forge.typo3.org/issues/503602013-07-24T10:49:55ZSoren Mallingsoren@meteko.dk
<p>By using mod.web_list.allowedTables you can adjust the allowed tables. This is useful in storage folders, where you might only want one single record type.</p>
<p>The usability issue comes, when the editor has to click on that single record type. Instead we should forward the editor to the form for that specific record type allowed.</p>
<p>I suggest this being a core feature. In case of objection I suggest a hook, giving the possibility to introduce the functionality via a extension.</p> TYPO3 Core - Task #30920 (Closed): EXT:recycler: defaultTable should be configurablehttp://forge.typo3.org/issues/309202011-10-14T11:22:07ZSoren Mallingsoren@meteko.dk
<p>The default table for content elements, should be configurable on both User TSConfig and Page TSConfig level</p> TYPO3 Core - Task #29774 (Closed): Improve information in show_item.php http://forge.typo3.org/issues/297742011-09-14T14:10:08ZSoren Mallingsoren@meteko.dk
<p>Currently the "Info" popup (show_item.php) provides information with raw data from sys_refindex. A editor will get informations such as actual table name from the database and a uid - but no real hint to what records it's all about.</p>
<p>This patch provides information about table (name shown in list module), field name ( as shown in TCEforms) for both references tables</p> TYPO3 Core - Bug #25042 (Closed): options.moduleMenuCollapsable does not have any effect on extjs...http://forge.typo3.org/issues/250422011-02-15T13:00:08ZSoren Mallingsoren@meteko.dk
<p>After extjs based modulemenu was introduced the us TSConfig setting "options.moduleMenuCollapsable" does not have any functionality</p>
<p>A <br />(issue imported from #M17595)</p> TYPO3 Core - Bug #12177 (Closed): Closing dialog forces reloadhttp://forge.typo3.org/issues/121772011-01-13T13:46:20ZSoren Mallingsoren@meteko.dk
<p>if you click on the "Close" icon in the upperright corner of a modal window, the list of extensions is force-reloaded. Is this necessary, as you are "aborting" a action so nothing should/would be saved?</p> TYPO3 Core - Bug #23850 (Closed): HSC header is not bold, in be_group "Page types"http://forge.typo3.org/issues/238502010-10-27T09:42:09ZSoren Mallingsoren@meteko.dk
<p>I love the new HSC!</p>
<p>If using accessListRenderMode = checkbox and go to "Page types" in a be_group the first line isn't bold, as in ex. tt_content</p>
<p>(issue imported from #M16139)</p> TYPO3 Core - Bug #22768 (Closed): Wrong icons for elements in "Create new element"http://forge.typo3.org/issues/227682010-05-30T23:05:39ZSoren Mallingsoren@meteko.dk
<p>The "sys_template" got no icon<br />"Domain" doesn't use correct icon<br />"Alternative page language" doesn't use correct icon</p>
<p>(issue imported from #M14543)</p> TYPO3 Core - Bug #22767 (Closed): "Create new element" got a lot of space between possible elementhttp://forge.typo3.org/issues/227672010-05-30T23:03:21ZSoren Mallingsoren@meteko.dk
<p>The list of new element to create got a lot of space, after the new sprite icons has been introduced</p>
<p>(issue imported from #M14542)</p> TYPO3 Core - Bug #22715 (Closed): Writing name of existing database, doesn't use databasehttp://forge.typo3.org/issues/227152010-05-25T19:23:43ZSoren Mallingsoren@meteko.dk
<p>At install tool step 2, you are able to write a new database to create or choose a database from a select list.</p>
<p>If you write the name of a already existing database, the name isn't written to localconf.php and the next step will result in a error.</p>
<p>Solutio:<br />----------<br />check if written databasename exist in array of existing databases and then write it, if true.</p>
<p>Going to a meeting in 20 minutes, but will try to create patch later tonight!<br />(issue imported from #M14478)</p> TYPO3 Core - Feature #22372 (Closed): [Feature request] Add return_url to link even though page d...http://forge.typo3.org/issues/223722010-04-03T15:02:49ZSoren Mallingsoren@meteko.dk
<p>This is a feature request:</p>
<p>Issue:<br />When creating a link in RTE it would be great to have the possibility of adding the current page to the link as a return_url GET parameter.</p>
<p>Ex. if linking to a login page, from one page. Because the login page isn't restrictd, you don't get the return_url GET parameter, and the user will then have to take action in order to get back to the correct page</p>
<p>Solution:<br />Add a checkbox to the link generator, where you can tick of "Add current page as return_url" (or something similar) which then add the current page to the created link</p>
<p>I would like to try and write the patch, as we are in need of this function in a project I'm working on, but i would like to hear whether or not this function could be interesting for the rtehtmlarea extension?</p>
<p>(issue imported from #M13994)</p> TYPO3 Core - Bug #21698 (Closed): Extension category title not properly rendered in backendhttp://forge.typo3.org/issues/216982009-11-26T09:43:06ZSoren Mallingsoren@meteko.dk
<p>The extension category title is not rendered properly for the extension not having a category name, it's shown as</p>
<p><em>[]</em></p>
<p>Screenshot attached</p>
<p>(issue imported from #M12771)</p>