http://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692015-01-14T12:56:10ZTYPO3 ForgeTYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2446712015-01-14T12:56:10ZMathias Schreibermathias.schreiber@typo3.com
<ul><li><strong>PHP Version</strong> set to <i>5.5</i></li></ul> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2446722015-01-14T12:59:57ZAndreas Wolfandreas.wolf@typo3.org
<ul></ul><p>Looks good :-)</p>
<p>The only thing that bugs me after reading it once again is the cached/uncached stuff. I’m not sure if the class namespace is really the right place to have such information. Having two methods registerCachedPlugin/registerUncachedPlugin or a separate caching parameter would be better IMHO.</p> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2446732015-01-14T13:02:22ZBenni Mackbenni@typo3.org
<ul></ul><p>What I would like to see is</p>
<p>1) The plugin registration should be unified, also working for extbase extensions<br />2) I think a strong default should be not using "plugin" (CType list, subtype list_type) anymore but CTypes directly for the future.<br />3) I would love to have an auto-registration (similar to EXT:autoloader) instead of adding this to ext_localconf.</p>
<p>I can write down a blueprint for that</p> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2446742015-01-14T13:23:51ZMathias Schreibermathias.schreiber@typo3.com
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/244674/diff?detail_id=209152">diff</a>)</li></ul> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2446752015-01-14T13:37:55ZCarsten Bleickercarsten@bleicker.de
<ul></ul><p>I need 2 Method calls?<br />\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addPlugin<br />\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addPluginTyposcript</p>
<p>if so, why not just one?</p> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2446762015-01-14T13:48:11ZMathias Schreibermathias.schreiber@typo3.com
<ul></ul><p>As written above:<br />One thing is TS, the other thing is TCA related.</p>
<p>It could be unified, that's the plan.</p> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2446772015-01-14T13:53:33ZMathias Schreibermathias.schreiber@typo3.com
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/244677/diff?detail_id=209153">diff</a>)</li></ul> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2446782015-01-14T14:00:27ZMathias Schreibermathias.schreiber@typo3.com
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/244678/diff?detail_id=209154">diff</a>)</li></ul> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2446822015-01-14T14:10:59ZMarkus Kleinmarkus.klein@typo3.org
<ul></ul><p>Extbase only supports plugins and and ctype, but not headers and menu.</p>
<p>I'm not sure if the change of the TS syntax is really possible at the current stage. This would maybe work out for third party extensions, but it will break IndexedSearch which would be the first candidate needing this API.</p> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2446832015-01-14T14:12:08ZMathias Schreibermathias.schreiber@typo3.com
<ul></ul><p>I gave indexed_seach some thought and I think it would be easier to supply a classmap for IS only.</p> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2448632015-01-15T16:14:28ZMathias Schreibermathias.schreiber@typo3.com
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/244863/diff?detail_id=209416">diff</a>)</li></ul> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2449632015-01-16T08:42:44ZDaniel Siepmanncoding@daniel-siepmann.de
<ul></ul><p>Thanks for the nice topic.</p>
<p>I would prefer to follow Benjamin Mack:</p>
<blockquote>
<p>3) I would love to have an auto-registration (similar to EXT:autoloader) instead of adding this to ext_localconf.</p>
</blockquote>
<p>I don't want to write code at all to do this obvious things. I just want to place my code, following the strong defaults and conventions, and it's there.</p>
<p>I think that's pretty easy for non-extbase plugins. As you don't need any further configuration like Extbase does.</p>
<p>I don't think you can handle both ways the same. Extbase just needs, at the moment, further configuration which, in my opinion, can't be fetched from existing sources.<br />And that's mostly fine. Of course it would be better to have the same principle and way for both. But Extbase is not the same. It itself can follow the above way. But it's not TYPO3, it's Extbase, a PHP Framework inside of TYPO3 CMS.<br />If you stick to it, you have to follow it.</p> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2449932015-01-16T13:02:29ZMarkus Kleinmarkus.klein@typo3.org
<ul></ul>Well we can make this auto-registration based, but that would require:
<ul>
<li>Having the information whether a plugin is cached or uncached encoded into the namespace</li>
<li>The method to call has to be fixed to some value.</li>
</ul> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2449952015-01-16T13:06:52ZMathias Schreibermathias.schreiber@typo3.com
<ul></ul><p>Markus Klein wrote:</p>
<blockquote>
Well we can make this auto-registration based, but that would require:
<ul>
<li>Having the information whether a plugin is cached or uncached encoded into the namespace</li>
</ul>
</blockquote>
<p>Or my having something like static public runScriptUncached = true;<br />But that would involve calling the class itself while building up the caches.</p>
<blockquote>
<ul>
<li>The method to call has to be fixed to some value.</li>
</ul>
</blockquote>
<p>I discussed this with CK yesterday.<br />He's in favor of having an explicit registration.<br />Maybe do a hangout with people interested.</p> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2449992015-01-16T13:21:55ZMarkus Kleinmarkus.klein@typo3.org
<ul></ul><p>Mathias Schreiber wrote:</p>
<blockquote>
<p>Markus Klein wrote:</p>
<blockquote>
Well we can make this auto-registration based, but that would require:
<ul>
<li>Having the information whether a plugin is cached or uncached encoded into the namespace</li>
</ul>
</blockquote>
<p>Or my having something like static public runScriptUncached = true;<br />But that would involve calling the class itself while building up the caches.</p>
</blockquote>
<p>A clear no-go as this would open up things to break again during bootstrap. Imagine a constructor which does some nasty stuff. While bootstrap loads all the ext_localconf files the class would be instantiated and would therefore crash the whole instance.</p>
<blockquote>
<blockquote>
<ul>
<li>The method to call has to be fixed to some value.</li>
</ul>
</blockquote>
<p>I discussed this with CK yesterday.<br />He's in favor of having an explicit registration.<br />Maybe do a hangout with people interested.</p>
</blockquote>
<p>I guess I prefer explicit over implicit too in this case, although it is hard to draw the line. Implicit is better for avoiding configuration hassle, but explicit is better for emphasizing relationships/dependencies. Implicit as also more error-prone and harder to debug. Consider a typo in the folder name for instance. Your plugins will never show up and you've no clue why and even worse, the system can't help you out, as it simply doesn't know you were intending to add a plugin. If you have that explicitly, the system can shout: Hey I can't find that plugin you want to add. You get a clue where to start searching for the issue.</p> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2450182015-01-16T15:23:03ZMathias Schreibermathias.schreiber@typo3.com
<ul></ul><p>Markus Klein wrote:</p>
<blockquote>
<p>A clear no-go as this would open up things to break again during bootstrap.</p>
</blockquote>
<p>Agreed.</p>
<blockquote>
<p>I guess I prefer explicit over implicit too in this case, although it is hard to draw the line.</p>
</blockquote>
<p>Actually no.<br />Explicit is easier to use AND to implement, less error prone and simply faster.</p>
<p>So the challenge is to make the process of registration as simple as possible and short as possible.<br />This includes a short, easy to read, expressive syntax.</p> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2450582015-01-16T17:25:43ZDaniel Siepmanncoding@daniel-siepmann.de
<ul></ul><p>Just to bring in some ideas from other projects for the syntax. That's what I imagine could be the DSL for a Ruby Project:<br /><pre>
TYPO3.extension.config do
plugin :news
plugin :admin
end
</pre></p>
<p>That can be the same as for Extbase. The above is without.<br /><pre>
TYPO3.extension.config do
plugin :news, cached: [ :list, :detail ], non_cached: [ :search, :result ]
plugin :admin, non_cached: [ :edit, :new, :update ]
end
</pre></p> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2463332015-01-23T11:46:13ZAndreas Wolfandreas.wolf@typo3.org
<ul></ul><p>Daniel Siepmann wrote:</p>
<blockquote>
<p>That can be the same as for Extbase. The above is without.<br />[...]</p>
</blockquote>
<p>Nice idea, however I think this form suits a bit better:</p>
<pre><code>TYPO3.extension.config do
plugin :news { cached: [ list, detail ], uncached: [ search, :result ] }
plugin :admin { uncached: [ :edit, :new, :update ] }
end
</code></pre>
<p>So this is a more JSON-style syntax, to make it more clear that the cached/uncached lists are in fact properties of the plugin; that’s a point I missed in Daniel’s suggestion. Apart from that, nice thing :)</p> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2511922015-02-28T17:34:35ZBenni Mackbenni@typo3.org
<ul><li><strong>Target version</strong> changed from <i>7.1 (Cleanup)</i> to <i>7.2 (Frontend)</i></li></ul> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2607422015-06-08T14:21:01ZMarkus Kleinmarkus.klein@typo3.org
<ul><li><strong>Status</strong> changed from <i>Needs Feedback</i> to <i>Accepted</i></li><li><strong>Target version</strong> changed from <i>7.2 (Frontend)</i> to <i>7.3 (Packages)</i></li></ul> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2607462015-06-08T15:15:48ZMarkus Kleinmarkus.klein@typo3.org
<ul></ul><p>After discussing this extensively with Mathias Schreiber again, I summarize:</p>
<ul>
<li>we want autoregistration (real life usecase: saving lots of typing when adding 55 CEs)</li>
<li>Location in extension is <code>Classes/<Plugin|Ctype|Menu|Header>/<Cached|Uncached>/<ClassName>.php</code></li>
<li>Method called in class is "render()"</li>
</ul>
<p>The TypoScript and TCA registration will be autogenerated, no need to call <code>addPlugin</code> and <code>addPItoST43</code> anymore.</p>
<p>The TypoScript changes proposed above will be omitted for the time being.</p> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2607532015-06-08T16:02:13ZThomas Maroschiktmaroschik@dfau.de
<ul></ul><p>I have several issues with the suggested solution:</p>
<p>Implementing this through autoregistration introduces a lot of complexity and overhead into requests: like inflecting the class name from a filename is cumbersome and error prone. further the "buildup" time of CMS increases, when loading fails it doesn't fail with a error message but just doesn't work, etc. further class loading is more and more a duty of composer and the CMS shouldn't know about the implementation details of composer, so it should just load classes transparently from what location ever. caching the information introduces it's own issues, like when to invalidate, when to rescan. for the system it's hard to detect changes automatically. debugging why a certain plugin doesn't load can sometimes take hours where the time debugging exceeds the time saved typing an explicit registration by far. I experienced this myself in other former TYPO3 products as biggest productivity killer.</p>
<p>So I think a better low tech solution would be to simply register this plugins in a file (maybe like the new TCA config files) where the plugin name is the key and the value is an array consisting of the full classname and the method to call. TS and tt_content TCA could still be fed from this. and the large array simply be cached in configuration cache.</p>
<p>We could provide a cli command that scans your extension for those classes and registers them then in a configuration file to make the life of a developer a bit easier. Further the developer can then go on and check the result of the operation. This command could also do all kinds of configuration checks and provide valuable information to the developer. This would be efficient, because the plugin information only changes on "commit time" and not during "runtime".</p> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2607542015-06-08T16:26:54ZMathias Brodalambrodala@pagemachine.de
<ul></ul><p>Just my two cents: Tim Lochmüller has implemented something like this with his <a href="http://typo3.org/extensions/repository/view/autoloader" class="external">autoloader</a> extension.</p> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2607562015-06-08T16:42:50ZPatrick Broens
<ul></ul><p>IMHO the whole description of this issue is wrong. You do not need addPItoST43 to register a userfunc. You can add the TypoScript yourself if you have added a CType using addPlugin. I don't even want to use addPItoST43, because it is an old magical thingy nobody understands. The proposed replacement of css_styled_content is not using this, but is using data processors from the content object FLUIDTEMPLATE, which makes this registration of classes redundant.</p>
<p>That does not mean we need a replacement for addPItoST43, but keep in mind there are other ways to handle data as well, as the CSC replacement is doing with data processors. They need to be assigned anyway, without magic.</p> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2607592015-06-08T16:54:40ZMarkus Kleinmarkus.klein@typo3.org
<ul></ul><p>Well, of course for Ctypes this "new" API will not be relevant anymore, due to new "CSC". But we still need a way to register namespaced, pibased plugins. Nothing more or less.<br />The discussion about the future concept solely grew out of that need.</p> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2607762015-06-08T22:06:54ZChristian Kuhnlolli@schwarzbu.ch
<ul></ul><p>I read through all comments and some of the involved code, but still need to think about that a bit longer.</p>
<p>At the moment, I think that an "autoregister" by putting some classes at magic places is not my favorite. I've tried that with the new toolbar registration and threw away the implementation after realizing all the magic, assumptions and ugly code the system has to go through and the hell dev's tap in during debugging if it does not work - and it never works at first try. So, I'm fully on Thomas side at this point.</p>
<p>Looking specifically at addPItoST43(), I'm mostly thinking about just deprecating it without substitution: It doesn't provide much value beside it puts stuff into a convention namespace - but it extracts this magically from the input parameters, and that is exactly what is hitting us currently. For indexed_search, we could just add the TS on our own and not use the method anymore. Maybe that is the most straight and simple solution ahead - at least the ugly alias could be kicked this way.</p> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2607782015-06-08T23:17:57ZMarkus Kleinmarkus.klein@typo3.org
<ul></ul><p>After all that fruitful discussion, I started digging a lot deeper and would suggest this solution:</p>
Each extension can define the following files in the Configuration/ folder:
<ul>
<li>Plugins.php</li>
<li>ContentElements.php</li>
<li>HeaderLayouts.php</li>
<li>Menus.php</li>
</ul>
<p>Each of them is supposed to return an array, which contains all Plugins/Menus/... including configuration.<br />Example</p>
<pre>
<?php
return [
1433786303 => [
'handler' => \TYPO3\CMS\IndexedSearch\Controller\SearchFormController::class,
'cached' => FALSE,
'icon' => '',
'label' => ''
]
];
</pre>
<p>Where 'icon' and 'label' are optional and will be loaded from default locations, if not specified.</p>
<p>I inspected all places which depend on the methods <code>addPlugin</code> and <code>addPItoST43</code> being called, which are luckily only three.</p>
<p>Those configuration files are loaded at different places then:</p>
<p>1.) \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::buildBaseTcaFromSingleFiles<br />The TCA (currently done by <code>addPlugin</code>) is added here just before the TCA/Overrides are executed<br />=> The TCA changes are cached</p>
<p>2.) \TYPO3\CMS\Core\TypoScript\TemplateService::addDefaultTypoScript<br />The TypoScript is added and will be cached as well.<br />(former <code>addPItoST43</code>)</p>
<p>3.) \TYPO3\CMS\Core\TypoScript\Parser\TypoScriptParser::checkIncludeLines:858<br />Also a place which is influenced by plugin TS.<br />Here the TS needs to be added as well.<br />(former <code>addPItoST43</code>)</p>
<p>The benefit is a dedicated, explicit configuration, which is only evaluated when needed and is fully cached.<br />(Additionally, if we embrace a standard for PHP class placement, a dedicated tool coult generate these config files automatically.)</p> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2607792015-06-08T23:23:00ZChristian Kuhnlolli@schwarzbu.ch
<ul></ul><p>Markus, this is going into a sane direction, but it also opens a relatively huge topic: "Finally get configuration handling done". Let us give some time here and evolve that. Do we have enough person power to tackle this thing in 7?</p>
<p>If we open this pit, we need to have a look at all main registrations of std api's in the core ... this is a rather huge part.</p> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2607812015-06-08T23:44:55ZMarkus Kleinmarkus.klein@typo3.org
<ul></ul><p>Well, I guess it is the right direction, but maybe too early. ;-)</p> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2615912015-06-15T17:08:33ZBenni Mackbenni@typo3.org
<ul><li><strong>Target version</strong> changed from <i>7.3 (Packages)</i> to <i>7.4 (Backend)</i></li></ul> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2682502015-07-23T15:51:42ZBenni Mackbenni@typo3.org
<ul><li><strong>Category</strong> changed from <i>Backend API</i> to <i>1595</i></li><li><strong>Sprint Focus</strong> set to <i>Stabilization Sprint</i></li></ul> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2688342015-07-28T17:39:59ZBenni Mackbenni@typo3.org
<ul><li><strong>Target version</strong> changed from <i>7.4 (Backend)</i> to <i>7.5</i></li><li><strong>Sprint Focus</strong> deleted (<del><i>Stabilization Sprint</i></del>)</li></ul> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=2770552015-09-24T07:50:22ZBenni Mackbenni@typo3.org
<ul><li><strong>Target version</strong> changed from <i>7.5</i> to <i>8 LTS</i></li></ul> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=3278052017-03-28T22:54:10ZBenni Mackbenni@typo3.org
<ul><li><strong>Target version</strong> changed from <i>8 LTS</i> to <i>Candidate for Major Version</i></li></ul> TYPO3 Core - Story #64274: Add new Plugin registrationhttp://forge.typo3.org/issues/64274?journal_id=5068782024-01-11T15:59:51ZOliver Haderoliver.hader@typo3.org
<ul><li><strong>Related to</strong> <i><a class="issue tracker-4 status-8 priority-4 priority-default" href="/issues/102821">Task #102821</a>: Drop \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addPItoST43</i> added</li></ul>