Search form

Drupal 8: CMI, Plugins, OO - Meet Yves Chedemois - Part 2

Part 2 - In this podcast, Yves Chedemois, aka yched, and I cover some changes to Drupal 8 core – CMI, the plugin system, and how they (and object oriented code) benefit developers. Yched is an important contributor to Drupal: he has been a maintainer of what was called CCK in Drupal 4.7 through Drupal 6.x, then became the core Field API in Drupal 7. In part one of our conversation, we talk about Yves's time working on Drupal, being part of the Drupal community (and the "Hey!" moment), Drupal development sustainability, and how the Drupal community stepped up to help him when he needed it recently. We spoke on a very pleasant September afternoon outdoors at DrupalCon Prague. You might hear the odd skateboard or two in the background of our conversation.

People should be excited about CMI in Drupal 8

"The first notable point: CMI is going to change the life of every single Drupal shop out there. It's just huge. This changes how you work with a Drupal site; developing it or maintaining it while it is live." CMI is the core initiative that moved configuration out of the database on Drupal 8, separating it from content, and into .yml files. This makes it possible to do content staging; to version control, import, and export configuration; and opens the doors to new ways of working and building Drupal products and distributions.

"It trickles down to many changes, API-wise. It unifies a lot of things. Previously, all systems in core and contrib. that had to store configuration, had to invent their own storage and take care of their own database storage; come up with the right schema and come up with the right API functions to load and save and invent the code flows around them.

Now, it's mostly taken care of for you. You don't have to bother with it anymore. It's nice for module developers, because you just have to follow the practices. You have to learn them once ... there's a learning curve, but you're guided along the way. What you learn on one subsystem mostly applies to all the other subsystems throughout all of core and contrib. This is huge."

While there is individual business logic and APIs defining views, image styles, rule triggers, etc. – since these are radically different from one another, "but how they work: How you load one, how you save one, how you modify one," and how you react to and interact with with them, "is going to be the exact same flows. Learn once and apply to everywhere.

People should also be excited about the plugin system in D8

The same pattern applies to yched's "2nd most important and interesting" innovation in Drupal 8: the plugin system. "It's the same pattern of unifying practices and APIs on stuff that many subsystems had to reinvent in Drupal 7. In core, you had image styles and image effects; image effects are typically plugins. On the Field API side, we had widgets, formatters, and field types. Those are 'plugin-like things' ... We had a series of things that basically represent the same pluggable feature, but there was no common API. So each of those subsystems had to invent them on their own."

In Drupal 8, developers can learn a unified set of patterns and practices and apply them across most of what they do in code, most anywhere in Drupal. "In getting those APIs right, it's been about not only getting it right for the use cases we have in core, but also how we can make it easy to learn, easy to leverage in your own contrib. or custom module ... How to define a new plugin type ... How to interact with it. I think this will be really important in D8. In D8 core, we have 20 different plugin types and this will only explode in contrib. The plugin API will be a very, very strong unifying pattern in how you structure your Drupal code."

How do I get into Drupal 8 now?

"All of these unified APIs we've been talking about in CMI and the underlying concept of config. entities relate to the entity system as we know it in Drupal 7, but way better and able to handle many more things. We've vastly improved consistencies in how a node works and how a view works in terms of how you load it, save it, interact with it. They have a common APIs for basic CRUD operations. This leverages object oriented code, which produces more 'layered', 'fractal' code. So to grasp a piece of run-time call stack, the code is split in different classes that all have a simple job to do, but doing a real, live task like saving a node goes through code in many different classes. Having a good vision of that can get a little confusing," But once you know it, "it's knowledge that stays and you don't have to do it over again every time. The cost of entry for understanding how the code works is a bit more complex."

The payoff for getting over that initial complexity hurdle is overall increased simplicity and consistency across Drupal's subsystems. "One of the good entry points might be seeing how OO lets you have a different, easier to encompass, formulation of existing concepts is to look at one of the [largely hook-based] systems that existed in Drupal 7, like blocks and field formatters." Yched explains the contents of one of these simple APIs and then suggests to open the implementation of a field formatter in D8, explains its contents and how it can be modified in a few lines of code. "This in the end is the nice thing about OO and the plugin system. It's a great way to enter the OO world."

See also: "Don't be STUPID, grasp SOLID" from DrupalCon Prague by Anthony Ferrara, aka ircmaxell, in which he covers understanding OO and good OO coding practices.