Summary: Drupal 8 Wins: Avoiding the Dead Hook Blues, Part 2 - In today's conversation, Larry Garfield, Kris Vanderwater, and I go 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, CMI, abstraction in Drupal, and the future of Features in Drupal 8. 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 second 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. The Seeds of Cooperation Larry surprised my by pointing all the way back to 2007 as the origin of his blog post "Getting off the island in 2013" and the eventual adoption of Symfony2 components into Drupal 8. The Go PHP 5 project was the first collaboration between PHP projects. It was a joint effort to force the adoption of PHP by hosting providers, by eliminating the "chicken and egg problem" and setting a date for Drupal, Joomla!, and others to drop support for PHP 4 in 2008. As Larry puts it, "We assassinated a programming language." Interestingly, there is some interest in doing this again. Larry goes into some detail about how Drupal adopted the Symfony2 HttpFoundation Component and eventually other components as well. Why not go all the way? In response to the question, "Why not build Drupal the CMs as a layer on top of Symfony full-stack?" Larry says, "If we were starting from ground zero right now, there would be a viable argument to make for that. There are places where that might be problematic however: Symfony the full-stack framework is structurally designed on the assumption that all changes are code changes. Your configuration is config files that you edit and then deploy to production after a compile step. It's not built around the 'site-builder clicky-clicky' model. That's not what the full-stack framework is optimized for. " Where will Drupal 8 be better for developers? "That's not a short list," points out Larry. "Some of the major improvements are ..." Returning output that is not just a page "became a first class citizen". Drupal 7 and earlier was a page-building tool. Drupal core is more loosely coupled, making it a lot easier to change or override. "Drupal, at the platform level, is mostly objects that are configured using a dependency injection container, which means you can override piece of core and even reassemble them differently without technically 'hacking core'. You're not modifying code, you're just manipulating configuration at a much lower level." For module developers, "Drupal 7 had an [very limiting] approach of passing blobs of data around and letting them get modified: render arrays, form arrays, alter hooks. You have a big blob of state and you manipulate it until you're ready to do something with it. Everything was treated as a global. Drupal 8 doesn't use arrays as the ultimate data object, you actually have a structured data object that has actual architecture. You have service objects that can act on those or other events that then get wired together. You have a lot more discrete. small pieces you can use." Resources Larry on Twitter Larry's blog post "Getting off the island in 2013" Palantir (check out their beautiful responsive site and sign up for their newsletter!) Commerce Guys Kris on Twitter Kris's Blogpost "A Drupaller in Symfony Land" "Create your framework" by Fabien Potencier Video!
