118: Drupal 8 Wins: Avoiding the Dead Hook Blues - 3/3

Drupal 8 Wins: Avoiding the Dead Hook Blues, Part 3 - Today we wrap up this mini series with Larry Garfield, Kris Vanderwater, and me answering the question "Do I need to learn Symfony to develop for Drupal 8?", getting the lowdown on plugins, and doing a wrap-up on the important points from our whole, 3-part conversation.

In August 2013, I spoke with Larry Garfield and Kris Vanderwater in a 90+ minute live Hangout on Air about the origins, details, and implications of the big architectural changes coming in Drupal 8. Today's video and audio podcasts are the third set of "curated" excerpts from that long conversation.

In part one, we covered Larry and Kris's Drupal backgrounds, early Drupal memories, compare Drupal 4 to Drupal 7 and 8, some pragmatic reasons to choose Drupal, and how to get your head around the Symfony2 framework.

In part 2, we went over the Go PHP 5 project as the first seeds of cooperation between different PHP projects, how the Symfony2 framework became part of Drupal 8, why we aren't building Drupal 8 on Symfony full-stack, and CMI, abstraction in Drupal, and the future of Features in Drupal 8.


Symfony2 != Drupal 8

Q:"If I'm not familiar with Symfony, will I have a hard learning curve for Drupal?"

A: Larry Garfield - "Adopting various Symfony components has had a huge impact on Drupal, however people should not confuse the parts that are done with Symfony versus the parts that are done with PHP 5.3. PHP 4 and PHP 5.3 are different languages: conceptually, structurally; they happen to be mostly backward-compatible, but that's about it. Drupal 8's biggest shift is that it is a PHP 5.3 system. We have ported Drupal to a new language. That is the biggest jump for people. Symfony is a PHP 5.3 component library that we're using a lot of pieces of to save time and because they have already solved a lot of hard problems in ways that are very good."

"You don't need to know Symfony full-stack in order to use Drupal. Understanding the HttpKernel would be helpful, but you don't need to build a couple of projects with Symfony full-stack to work with Drupal. You do need to understand PHP 5.3 development: classes, objects, not using globals, dependency injection, events as a concept. These are all things that are not specific to Drupal 8 or Symfony. They are specific to PHP 5.3 and modern PHP development."

A: Kris Vanderwater - "If you're a Symfony user and have used it in your projects in the past, you're going to be able to carry some of that knowledge forward. The places where we're using Symfony are in CMI, the routing system, the dependency injection container (which is awesome and you should absolutely learn it no matter what, just for your own well-being). With the exception of the dependency injection container, most of the rest of the stuff is behind various layers of Drupal stuff. You're probably not going to need to deal with it unless you absolutely have to." Beyond the dependency injection container, Kris says the only one you might need to touch would be the routing system, and you'd have to be doing something routing specific. There are Drupal wrappers around most of the Symfony components, so "the short answer is 'no', you don't need to know Symfony in order to do Drupal."


Q from the event live chat: "Question: Plugins, plugin types, plugin managers, arrrrgh! How?"

A: Kris

  • "A plugin type is a term that we use colloquially to refer to a type of plugin ... You actually won't see that in code anywhere. You might see it in a couple of comments or something like that, but a 'plugin type' is just words that we use."
  • "Plugin Managers are actually a class that composes together the ability to discover where a plugin exists. You can think of this in terms of hooks. Info hooks in Drupal 7 have largely been replaced by plugins in Drupal 8. So when we talk about 'discovery', that's what we mean."
  • "Plugins are just the individual implementations of that." Check out Kris's session from last year's NYC Camp. "I attempt to explain exactly these things in it. Anybody should feel free to ping me on IRC about this topic. We do have a bit of documentation on Drupal.org that covers this pretty well."

"For the most part, developers shouldn't be worrying about most of these concepts unless they are transferring an info hook that they created in their module over to the plugin system, which is a really great thing to do. I would heavily encourage it and I would heavily support it across IRC. Feel free to ping me; I'm more than happy to help."

Wrap-up: Larry

"Drupal 8 is a big jump, but it's a big jump that we didn't have choice about making. This is something we need to collectively understand. PHP 4 is a dead language we had the ability to either leap forward, catch up and try to push forward in the new model, or sit on a sinking island until no one wanted to touch Drupal. This wasn't core developers conspiring to make life difficult for people, this was, 'We have to catch up with the rest of the industry or we're going to die alone.'"

"A lot of things Drupal has done very well. In terms of community management and community building, we're second top none in the PHP world. Some of the stuff we've done with CMI is amazing. We actually have a solution for compiling code at runtime and keeping it secure. We actually solved that! I've never seen anyone else do that ... That's CHX being amazing ... "

"Drupal's routing system is built on Symfony, but the actual pipeline was a collaboration between Drupal and Symfony CMF that EZPublish is also going to be using. There's a lot of benefit to us and to PHP by collaborating more. It's not just a matter of saving time ourselves or being lazy; there's an actual huge benefit to collaboration. We see this within Drupal all the time and now we see through the broader community."

Wrap-up: Kris

"One of the things we've adopted [in terms of becoming a more integral part of the broader PHP technical community] is standardizing on Composer. It's a tool that can be used in order to literally compose together various PHP libraries. You can say, 'I need Symfony's autoloader, I need Symfony's HttpKernel, I need Guzzle, I need Twig, I need Assetic, I need Drupal's plugin system (maybe, if I get my way!).' This becomes a way for you to put in a single file all of the base-level components that you need in order to run. And guess what? Drupal has one of those! It's got a composer.json file sitting right inside of it and it specifies all of the Symfony components [and a bunch more]."

"This means that a good chunk of what Drupal is doing today is taking these things and weaving them together in the way that we want. This is very powerful. This also means that we, as Drupal, can begin to abstract our own components into something that other PHP systems could be making use of."

"What's even more interesting about is if you start talking about extracting various 'Drupal-isms', our secret sauce, the things that really make us *us* and putting them into these sorts of libraries and making them available to the greater PHP world. Anybody who is a topical expert in one of those things, their potential influence out in the PHP world just increased dramatically because if those components start being used outside of Drupal, guess who they're going to call in order to implement it? Drupallers who know it. This is a really interesting way to begin sharing our code and our culture with the greater PHP community."