Last week in Drupal Development

 

This week has been an interesting one for me in regards to Drupal. 

PHPStorm Debugging

After reluctantly trying the latest iteration of PHPStorm, I finally decided to try to use it for debugging. While I have Eclipse installed, it's been more of a matter of necessity than of desire. My enterprise experience left me familiar with Eclipse and its many idosyncracies. It's large size and slow boot time have always been an annoyance, but one I overlooked given the functionality it offered. I was using it as my primary development environment until I forced myself to sit down and memorize a few vim commands. The only remaining function for Eclipse on my system was debugging. While I'm aware of a vim extension for XDebug, I never bothered to use it. 

Getting PHPStorm to use the debugger is actually so easy I doubted it worked at first. The problem I tried to tackle on Sunday night, however, was replicating the same debugging workflow I had in Eclipse. In Eclipse, I used the IDE's internal browser to navigate to key pages and invoke a debugging session. It was clumsy, but familiar. PHPStorm, however, had no such internal browser. The thought I would have to debug everything in raw HTML spat out by the console seemed like a step back. After researching, however, I discovered that PHPStorm rightly assumes you'd want to use a full browser for debugging instead. The trick is that the invocation of the debugger is not from within the IDE, but from the browser. By including a URL token and enabling PHPStorm to listen for incoming debug sessions, you can effectively start a debugging session from Chrome or Firefox. Even better, with the appropriate debug extension, you can drop in and out of debugging mode in the same browser tab. This allows you to target the code you need to debug. 

I hate to say it, but PHPStorm is winning me over.

Flag Friend Starting to Click

The rest of the week I devoted to pounding away at my "favorite" Flag Friend issue (https://drupal.org/node/1433122). The new code actually makes a bit more sense than the original incarnation, but it's still riddled with bugs and failing tests. I've been banging my head against this issue for months now with no success. I was beginning to think I was just incapable of understanding it or Drupal at all. Then, Tuesday night, things...started...to click. The overall logic of the module began to come into focus and the pieces began to fit together. 

Flag Friend is perhaps the most circuitous Drupal  module I've encountered. Normally, a Drupal module implements hook functions to provide some bit of functionality. This may be displaying a page, processing a form, or working with the database. Often, the first few chapters of any Drupal development book combined with some careful web searches are all you need to understand a module. Flag Friend has been the exception to every rule. Instead of providing any of it's own forms or pages, it alters forms, pages, and even links provided by the Flag module. 

In order to confirm a friendship, Flag Friend replaces the flag links with it's own. Then it changes the flag page handler. The new handler manually calls up the original handler and merges new changes into it. The confirmation form is altered with not a new, but additional submit handler. Whenever a confirmation or denial is given, Flag Friend's handler runs, and then Flag's. 

The circuitous logic makes it damn near impossible to give it a straightforward reading. 

Needless to say, this circuitous logic reads like a bug to me. To me, it makes much more sense to handle much of the logic directly, and invoke the Flag API programmatically, rather than as a side effect of a half-dozen alters. This, unfortunately, has problems of it's own. I'm still unsure what the solution will be, but I feel I'm very close to finding it.

Longtime Devs Leaving Drupal Core

This week two longtime developers announced they wished to leave Drupal core development. Both Quicksketch and David Reid have been involved in Drupal development seemingly forever. Therefore, it was a bit of a shock when both announced their intention to be removed from core development and removed from MAINTAINERS.txt. Both had different and understandable reasons for leaving.

Quicksketch cited his profound unhappiness with the direction of core development in Drupal 8. It was no longer a thing he "loved or understood". He would continue maintaining his Drupal 7 modules, but was unlikely to port them to Drupal 8. Quicksketch also mentioned how most of the code he worked on for core had been ripped out in Drupal 8. This would upset any developer, but combined with how some Drupal devs absolutely loathe object oriented programming (much to my dismay) and aggressive stamping out of not-invented-here syndrome, it's enough to make any programmer toss up their hands. 

David Reid also mentioned that he no longer understood Drupal core thanks to the importing of Symfony components, but it was far from his sole reason. Reid is an extraordinarily prolific module developer, with hundreds of modules under his care. His motivation for leaving, however, had less to do with 8 than with simple lack of time. He's a new father, and many of his most popular modules are now in Drupal 8 core. He's stated in person that he feels "done" with them, and wants to move on. He still wants to retain maintainership of the core Token module.

My takeaway: 

This was inevitable. Drupal already had a minor schism when we introduced the object oriented Database Abstraction layer in Drupal 7. People shouted "inefficiency!" and "bloat!" and "scares away beginners!" 

Please.

It's true that PHP's OOP was a laughable and infuriating mess -- back in PHP 4. In PHP 5, and particularly in PHP 5.3+, it's become really solid. Drupal has been facing a scaling problem since Drupal 6, and 7's reliance on straight functions made it perhaps the most confusing, upsetting, odd, and angering API I have ever programmed in. And I've written code for closed source products that are much less subject to review. The reality is that OOP was created to handle code scaling issues with which Drupal is grappling. PHP is evolving to make it a competitive OOP language, so what are we waiting for? I think the real problem is not objects at all. 

The real problem is, sadly, human. 

Many of the core devs have been working on Drupal for years and years. They've built careers on it, and they are defensive about their code. This is perfectly natural. With Drupal 8, however, we've not only "picked up the house and put it on a new foundation" as Crell (Larry Garfield) suggested, but bulldozed the house that many devs feel they build with their bare hands. Instead, we've put a shiny new skyscraper in it's place and recreated the layout, rooms, fixtures, and wallpaper of the original house inside. It may look like home at first glance, but to these long time devs, it's just not the same.

In retrospect, the Drupal association really needed to do some careful championing of Symfony in core. We have a lot of developers, but the core Drupal community has been pretty bad at the human side of the equation. Many developers (Universe help me if any actually read my blog) would simply say: "Ugh. No. There's no point. This is the right way. They'll get used to it." It may be the "right way", but it doesn't make it feel right. Person management is just as, if not more important than writing code. And as an open source community, we suck at it.

One of the most important things I've written in the last few years as an IT Education Designer wasn't about code or processes, best practices, or workflows. It was about people. For a cloud computing class I made a huge deal about how to handle a cloud implementation in terms what the company wanted, what the employees worried about, and the technical concerns. I argued that a special migration board needed to be set up, and a "cloud champion" be designated. This champion was there to not only be a cheerleader for the cloud migration, but also to listen to the very real concerns of employees-on-the-ground. The champion acts as a liaison so that difficult situations can be expressed without the fear of punishment or losing one's job. 

For a OSS developer community, it's less about losing one's job as it is people leaving. Drupal has very few core maintainers, and it seemingly is getting fewer all the time. Losing even one core dev is a big deal that can have lasting effects. Thankfully, the likes of YesCT and xjm have been making core mentorship a priority to help bring in new developers. Perhaps if we had Symfony-in-core champion, we would have been able to convince those considering leaving core maintainership to stick with it. Maybe the divisions were simply too much, maybe they'll come back for Drupal 9, it's hard to be know for sure.

What I do know is that core mentorship is even more important today than it was before. I've done a little mentorship myself. I helped several others through testing, and rerolling patches. With the events of the last week, perhaps I should take that much more seriously.