{"id":4410,"date":"2016-08-14T14:20:50","date_gmt":"2016-08-14T19:20:50","guid":{"rendered":"http:\/\/www.carnaghan.com\/?p=4410"},"modified":"2019-09-23T21:10:32","modified_gmt":"2019-09-24T01:10:32","slug":"drupal-8-plugin-system","status":"publish","type":"post","link":"https:\/\/www.carnaghan.com\/drupal-8-plugin-system\/","title":{"rendered":"Drupal 8 Plugin System"},"content":{"rendered":"\n

There is a lot of new terminology in Drupal<\/span> 8 and for anyone not familiar with Object Oriented programming<\/span>, some of it can be downright confusing. For myself, I have worked with OOP<\/span> for quite a while, however I have not spent as much time writing custom modules<\/span> for Drupal<\/span> 7. While I am familiar on the surface with the hook system and API<\/span> at a very novice level, I have never really had to do any intense back end<\/span> development in D7. Now that I am working in Drupal<\/span> 8, things are quite different with my projects at work. Thankfully my OOP<\/span> background has filled in some of the gaps, however my lack of Drupal<\/span> 7 module<\/span> development knowledge has proven to be a burden.<\/p>\n\n\n\n

In Day 8 we are looking at the Plugin<\/span> System and I have to be honest I was a little bit confused when I started looking at plugins<\/span>. Part of the reason for this was down to my lack of knowledge of Drupal<\/span> 7 development concepts, most notably, hook_info. In addition to this, I had just gotten my head around the concept of services in Drupal<\/span> 8 and found a blur between what I envisioned to be a service vs what could be considered a plugin<\/span>. Thankfully I was able to find some answers.<\/p>\n\n\n\n

Plugins<\/span> vs Services<\/h2>\n\n\n\n

The best description I could find of a plugin<\/span> with Drupal<\/span> 8 was found in the Drupal.org Why Plugins?<\/a> article<\/span>. The author describes a plugin<\/span> as something that would typically be exposed via a user interface<\/span> which users<\/span> can then configure<\/span>, interact with, or select which implementation of functionality they desire. This contrasts a service which is ‘intended to be something that modules<\/span> do programmatically to other modules<\/span>.’ The Lullabot article<\/span>, Creating a Custom Filter in Drupal 8<\/a> provides a nice analogy for a plugin<\/span> manager to that that of an ice cream shop and the plugins<\/span> themselves, ice cream, flavors, accounting systems for the business, etc.<\/p>\n\n\n\n

If you’re like me and are not as well versed in Drupal<\/span> 7 module<\/span> development, you might not have realized that the new Drupal<\/span> 8 plugin<\/span> system is essentially a replacement for hook_info<\/a> (a handy hook that allowed for organizing of other hooks as well as separating their logic out of the .module<\/span> file<\/span> which could become large and unmanageable for more sophisticated modules<\/span>. In addition to the above, unlike services, plugins<\/span> are setup to be ‘discoverable’ by Drupal<\/span> via annotations<\/a>. The Talking Drupal<\/span> podcast illustrates this well in their Intermediate Module Development Concepts<\/a> episode. When researching plugins<\/span>, I found a really good video from DrupalCon<\/span> Barcelona by Kris Vanderwater, who walks through setting up a basic example plugin<\/span> called plugin_message<\/a>.<\/p>\n\n\n\n

\n