The Drupal 8 plugin system - part 2
We saw in part 1 how plugins help us in writing reusable functionality in Drupal 8. There are a lot of concepts which plugins share in common with services, like:
- limited scope. Do one thing and do it right.
- PHP classes which are swappable.
Which begs the question, how exactly are plugins different from services?
If your interface expects implementations to yield the same behaviour, then go for services. Otherwise, you should write it as a plugin. This needs some explaining.
For instance, if you are creating an interface to store data in a persistent system, like MySQL or MongoDB, then it would be implemented as a service. The
save() function in your interface interface will be implemented differently for both the services, but the behaviour will be the same, i.e., it takes data as input parameters, stores them in the respective data store and returns a success message.
On the other hand, if you are creating an image effect, it needs to be a plugin. (It already is. Check image effects as plugins). The core concept of image plugins is to take in an image, apply an effect on it and return the modified image. Different image effects yield different behaviours. An image scaling effect might not produce the same behaviour as that of an image rotating effect. Hence, each of these effects need to be implemented as a plugin. If any module wants to create a new image effect, it needs to write a new plugin by extending the
Plugins used in core
Let's take a look at the major plugin types provided by Drupal 8 core. An example plugin of each plugin types will be the subjects of future blog posts.
Blocks Drupal 8 finally got blocks right. Custom blocks can be created from the
Field Types, Field Widgets and Field Formatters Check part 1 for how this is done in Drupal 8.
Actions Drupal 8 allows module developers to perform custom actions by implementing the
ActionBaseclass. Blocking a user, unpublishing a comment, making a node sticky etc. are examples of actions.
Image Effects Image effects are plugins which manipulate an image. You can create new image effects by extending
ImageEffectBase. Examples of core image effects are
Input filters User submitted input is passed through a series of filters before it is persisted in the database or output in HTML. These filters are implemented as plugins by implementing the
Entity Types In Drupal parlance, entities are objects that persist content or configuration in the database. Each entity is an instance of an entity type. New entity types can be defined using the annotation discovery mechanism.
Views related plugins A large collection of different plugin types are employed by views during the querying, building and rendering stages.
Plugin discovery is the process by which Drupal finds plugins written in your module. Drupal 8 has the following plugin discovery mechanisms:
Annotation based. Plugin classes are annotated and have a directory structure which follows the PSR-4 notation.
Hooks. Plugin modules need to implement a hook to tell the manager about their plugins.
YAML files. Plugins are listed in YAML files. Drupal Core uses this method for discovering local tasks and local actions.
Static. Plugin classes are registered within the plugin manager class itself. This is useful if other modules should not create new plugins of this type.
Annotation based discovery is the most popular plugin discovery method in use. We will briefly look at how we create a new plugin type using this method in the next part.