[#20547] - [4.0] Plugin as services
- Fixed in Code Base
- 14 May 2019
- Medium
- Build: 4.0-dev
- # 20547
- Diff
- Digital-Peak:j4/plugin/services
- Success continuous-integration/travis-ci/pr The Travis CI build passed Details
- Failure continuous-integration/drone/pr the build failed Details
- Success continuous-integration/appveyor/pr AppVeyor build succeeded Details
User tests: Successful: Unsuccessful:
Summary of Changes
Loads the plugins through the boot functionality similar to what we have for modules and components.
A plugin needs then a file services/provider.php which does register the PluginInterface::class resource in the container:
public function register(Container $container)
{
$container->set(
PluginInterface::class,
function (Container $container)
{
// @Todo This needs to be changed to a proper factory
$plugin = \Joomla\CMS\Plugin\PluginHelper::getPlugin('content', 'myplugin');
return new MyPlugin(
$container->get(DispatcherInterface::class),
(array)$plugin
);
}
);
}
More information can be found in #19834, #20217 and #19667.
This is on hold till #19834 got merged as it is based on it.
Testing Instructions
- Log in on the back end.
- Open back end admin panel end.
Expected result
The joomla update check will be executed.
Actual result
All is working fine.
Documentation Changes Required
Needs to be documented like the component service locator stuff.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_admin com_associations com_banners com_cache com_categories com_checkin com_config com_contact com_content com_contenthistory com_cpanel com_fields com_finder com_installer com_joomlaupdate com_languages com_login com_media com_menus com_messages com_newsfeeds com_plugins com_postinstall com_redirect com_search com_tags com_templates com_users Repository Front End |
| Labels |
Added:
?
|
||
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-06-14 23:04:29 |
| Closed_By | ⇒ | wilsonge |
We do not have a dispatcher here at all. But it makes sense to have the same procedure for every extension to be loaded the same way. It would be a logical next step to get rid of the file path lookup thing for plugins too.
But it makes sense to have the same procedure for every extension to be loaded the same way.
No, it doesn't. You can't apply this same logic to language packages or templates. Different extension types have different purposes, they can't all be loaded and managed in the same way.
Components are service providers. Modules really should just be component tasks in a HMVC based environment. Both of those are in essence task executors, it makes sense to have some form of dispatching mechanism in front of them. Plugins are intended to be an event subscriber. They don't need a dispatching mechanism in front of them, and as long as it is mandated they extend the CMSPlugin class you can't efficiently use dependency injection with them. If we can deal with that subclassing issue then maybe it makes sense to support the service provider file to be able to do dependency injection, otherwise I kind of agree that the dispatcher concept here is overkill.
Just to be clear here, there is no dispatcher involved for plugins. It is just about instantion for plugins which is now in the hands of the plugin itself. The dispatcher stuff is from the module pr where this pr is built on top of it. When the module pr gets merged then this one will get much smaler. Thats why I labeled it "On hold".
| Status | Closed | ⇒ | New |
| Closed_Date | 2018-06-14 23:04:29 | ⇒ | |
| Closed_By | wilsonge | ⇒ |
| Status | New | ⇒ | Pending |
| Category | Administration com_admin com_associations com_banners com_cache com_categories com_checkin com_config com_contact com_content com_contenthistory com_cpanel com_fields com_finder com_installer com_joomlaupdate com_languages com_login com_media com_menus com_messages com_newsfeeds com_plugins com_postinstall com_redirect com_search com_tags com_templates com_users Repository Front End | ⇒ | Libraries Modules Front End Plugins |
| Category | Front End Libraries Modules Plugins | ⇒ | Libraries Front End Plugins |
| Title |
|
||||||
| Labels |
Removed:
J4 Issue
|
||
| Status | Pending | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-05-14 13:52:37 |
| Closed_By | ⇒ | wilsonge |
I honestly still don't really agree with this for the reasons mentioned earlier. But as per our discussion on glip earlier merged.
I'm going to make a decision to reject this. All our plugins are basically singletons - they are booted once and then that instance is used for the entire request cycle - unlike components and modules. The booting is done transparently to everyone using the CMS. I think in this case introducing a dispatcher is complete overkill. There are definitely optimisations we can make (making the plugin config array an object so that we can build the plugins optionally through the DIC) and obviously using the namespace stored in the extensions table in the DB so they can be namespaced. But I don't think a dispatcher is the way to go here