TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692018-01-16T15:54:39ZTYPO3 Forge
Redmine TYPO3 Core - Bug #83581 (New): Logical error while checking validity of a shortcuthttp://forge.typo3.org/issues/835812018-01-16T15:54:39ZDavid Ottodavid.georg.otto@googlemail.com
<p>The function getSubpagesForPages in Class TYPO3\CMS\Frontend\Page\PageRepository uses the constraints given to filter the resulting subpages to also check if the target of a shortcut is valid. The validity of a shortcut target (as the comment line above the function call in question says: "If shortcut, look up if the target exists and is currently visible") should only depend on its existence and visibility and not any other constraints used to filter the result of getSubpagesOfPages (e.g. a shortcut itself).</p> TYPO3 Core - Bug #73545 (New): Translation Meta Data in FALhttp://forge.typo3.org/issues/735452016-02-18T17:20:13ZAndrea Herzog-Kienasta.herzog@kienastdv.de
<p>You upload a picture in FAL. You did'nt edit the meta data. But you will find the translation button(s) for the given languages (en, fr and so on). If you click the button "translate meta data", all other language buttons will be removed, except the translate (world) button. If you click the button again, all flag symbols will be shown again.<br />Now you can click at one of the symbols for a language or at the world symbol and you can translate.</p>
<p>But imho TRANSLATION needs a given language (Mathias, we talked about it some years ago).</p>
<p>However: The tooltipps for the symbols are different:<br />World: translate metadata <br />English Flag: edit metadata for English<br />French flag: create metadata for francais</p>
<p>Please note: the uploaded pic has no metadata at all.<br />So nothing can be translated.</p>
<p>The difference between en and fr may be the following:</p>
<p>en is used / fr is installed.</p> TYPO3 Core - Story #64274 (Accepted): Add new Plugin registrationhttp://forge.typo3.org/issues/642742015-01-14T12:56:02ZMathias Schreibermathias.schreiber@typo3.com
<p>Registering a non-extbase plugin currently needs two things:</p>
<ul>
<li>Add the TCA necessary by calling <pre>\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addPlugin</pre></li>
<li>Add the typoscript by calling <pre>\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addPItoST43</pre></li>
</ul>
<p><strong>addPItoST43</strong> adds typoscript in this form: <pre>
plugin.tx_extensionkey_suffix = USER
plugin.tx_extensionkey_suffix.userFunc = tx_extensionkey_suffix->main
</pre><br />When you want to use namespaced code (and I say that's what we all want) you need to manually supply a classmap in this form:<br /><pre>
tx_extensionkey_suffix => '\Vendorname\Extensionname\Controller\Class'
</pre></p>
<p>I propose a new method to register non-extbase plugins that enforces stronger defaults and reduces the clutter in the Typoscript Obejct Browser.</p>
<a name="New-method"></a>
<h3 >New method:<a href="#New-method" class="wiki-anchor">¶</a></h3>
<pre>static public function addPluginTyposcript($FQCN, $methodName = 'render')</pre>
<p>See the example:<br /><pre>
static public function addPluginTyposcript(\MyAgency\MyExtension\Cached\Plugin\MyPlugin::class, 'dispatch')
static public function addPluginTyposcript(\MyAgency\MyExtension\UnCached\Plugin\MyPlugin::class, 'dispatch')
static public function addPluginTyposcript(\MyAgency\MyExtension\Cached\Menu\MyMenu::class, 'render')
static public function addPluginTyposcript(\MyAgency\MyExtension\Cached\CType\MyCType::class, 'render')
static public function addPluginTyposcript(\MyAgency\MyExtension\Cached\Header\MyHeader::class, 'render')
</pre></p>
As you can see the FQCN (Fully qualified class name) holds a strong default for registering a plugin in the frontend.<br />Let's take the example above apart:
<ul>
<li>\MyAgency
<ul>
<li>the Vendor name</li>
</ul>
</li>
<li>\MyExtension
<ul>
<li>Your extension key</li>
</ul>
</li>
<li>\Cached
<ul>
<li>defines whether a plugin runs cached or uncached (just for TS registering, you can re-define it via TS, possible values are:
<ul>
<li>Cached</li>
<li>Uncached</li>
</ul>
</li>
</ul>
</li>
<li>\Plugin
<ul>
<li>Determines the type, possible values are:
<ul>
<li><del>Plugin</del></li>
<li>Menu</li>
<li>CType</li>
<li>Header</li>
</ul>
</li>
</ul>
</li>
<li>\MyPlugin
<ul>
<li>Your class name</li>
</ul></li>
</ul>
We will drop support for "just include library", because the design is just broken.<br />All TS get's added to page.1000, which is problematic if
<ul>
<li>you have multiple of these plugins installed</li>
<li>your root object simply has another name than page</li>
</ul>
<a name="Typoscript-result"></a>
<h3 >Typoscript result<a href="#Typoscript-result" class="wiki-anchor">¶</a></h3>
<p>I propose to add more "dots" to the TS.<br />Possible result:<br /><pre>
plugin.MyAgency.MyExtension.Plugin.MyPlugin = USER
plugin.MyAgency.MyExtension.Plugin.MyPlugin.userFunc = \MyAgency\MyExtension\Cached\Plugin\MyPlugin->dispatch
plugin.MyAgency.MyExtension.Menu.MyMenu = USER
plugin.MyAgency.MyExtension.Menu.MyMenu.userFunc = \MyAgency\MyExtension\Cached\Menu\MyMenu->render
</pre><br />This will clean up the Typoscript Object browser.</p>
<a name="tt_contentCType-result"></a>
<h3 >tt_content.CType result<a href="#tt_contentCType-result" class="wiki-anchor">¶</a></h3>
We could also derive the TCA necessary from this classes.<br />The following fields in tt_content are affected:
<ul>
<li>CType</li>
<li><del>list_type</del></li>
<li>menu_type</li>
<li>header_layout</li>
</ul>
<p>Storing values in these fields needs to comply to the TS being generated.<br />So the resulting value from the example would be:<br /><pre>MyAgency.MyExtension.Plugin.MyPlugin
MyAgency.MyExtension.Menu.MyMenu</pre></p>
<p>When selecting values in the database this comes in handy because you can now use proper wildcards to isolate specific extensions.</p>
<p>In order to generate the label for the field in the BE we would use a locallang.xlf hit for the same identifier.</p>
<a name="Registering-multiple-PluginsCTypes"></a>
<h3 >Registering multiple Plugins/CTypes<a href="#Registering-multiple-PluginsCTypes" class="wiki-anchor">¶</a></h3>
<p>Currently TYPO3 loops through all registered plugins and adds the TS on demand (in every hit).<br />Additionally, it's painful if you have an extension that registers, say, 50 CTypes.<br />The idea would be to look up all CTypes automatically and cache this information.<br />This way an extension would just need to "configure" something like "I do supply UserFunctions".<br />If there are cached registrations, use those.<br />If no cached registrations are in place, try to look them up via the filesystem (using the logic described above) and build up the caches.</p> TYPO3 Core - Bug #63810 (Accepted): pages SYS_LASTCHANGED does not update when page cache is clearedhttp://forge.typo3.org/issues/638102014-12-12T12:06:24ZMichiel Roos
<p>When the frontend cache is cleared, the SYS_LASTCHANGED value is not updated. This means that the 'Last Modified' header sent out by TYPO3 will stay unchanged for all the pages. All visitors holding a cached page in their browser cache will keep this page forever. They will check back with the server after the page 'expires' from their cache, but will never fetch a new version because the server says the page has not been modified.</p> TYPO3 Core - Bug #59225 (New): Disabled Pages from Type Mount Point are still visible in Frontendhttp://forge.typo3.org/issues/592252014-05-30T10:58:32ZAlex Kellneralexander.kellner@einpraegsam.net
<p>System TYPO3 4.7.17</p>
<p>Scenario: Adding a Page of type "Mount Point" with a page from tree 1 in tree 2.</p>
<p>I want to have a new menu item "test" in my second tree.<br />Related page "News" should be shown. That works fine.</p>
<p>But even if I disable the Mount Point - it's possible to open the link <br />in frontend. I have to delete the mount point to disable the functionality.</p> TYPO3 Core - Feature #52225 (New): Frontend user access for users which are not in selected userg...http://forge.typo3.org/issues/522252013-09-24T14:46:47ZBernhard Ecklbernhard@eckl-medien.de
<p>Sometimes I have a contents with restricted access in frontend for specific usergroup(s). There I insert the restricted content (like news plug-in, set the usergroups which are allowed to view the content), a login box (no access definition), a text element where I describe that the content is restricted to some users and that the user has to login (access to not logged in users) and another text describing that he is has no access to the content (should be only visible for logged in users which are NOT in the defined usergroups). But it is not possible to set access permissions for logged in users which are not in one or more specific usergroups. I have done this using extension maja_tscondition and a condition like: ![usergroup = 36]. This solution works but is not usable for editors (editors don’t know typoscript). My suggestion for this problem is to add a checkbox in the access tab (page properties and content elements) naming like »Show content only for logged in users which are not in the selected usergroups«. I think I am not the only one, this »problem« should have lots of other integrators with restricted access content.</p> TYPO3 Core - Feature #52114 (New): Expand "do not search" to subpageshttp://forge.typo3.org/issues/521142013-09-18T15:41:28Zd.ros no-lastname-given
<p>The do not search function in page settings is a quite useful thing. Especially if you want to hide pages from search and googlesitemap xml rendering.</p>
<p>But there´s one thing that makes it quite unhandy on large pagetrees. You cannot expand it to child pages. You can go with the list module, but even this is much efford if you want to hide 200 pages.</p>
<p>An equivalent usage to the access function would be a great benefit from an editors POV.</p>
<p>Cheers</p>
<p>David</p> TYPO3 Core - Feature #45577 (New): Possibility to sort records in TCEforms by label_userFunc labelshttp://forge.typo3.org/issues/455772013-02-18T16:55:50Zmost wantedmostwantedtypo3@gmail.com
<p>You can use label_userFunc to display meaningful custom labels for each record of a table in TCEforms. At the moment it is not possible to sort the records by this custom labels.</p>
<p>$TCA['table_name']['ctrl']['sortby'] and<br />$TCA['table_name']['ctrl']['default_sortby'] do not work for this task.</p>
<p>It would be useful if you could sort records in TCEforms by label_userFunc labels.</p>