Drupal, meet PHP FIG - Larry Garfield

0
DrupalCon Asia Mumbai background image

Listen to the podcast:

Download podcast (59.58 MB)

Larry Garfield aka crell: Drupal 8 Web Services Initiative Lead, a subsystem maintainer for a couple of things, relevant and Drupal representative to the PHP Framework Interoperability Group. Make sure you listen to the podcast for the full origin story of Larry’s online handle!

This conversation with Larry Garfield (@crell) is the first in a series of interviews Campbell Vertesi (@CampbellVertesi) and I carried out in preparation for DrupalCon Asia in Mumbai. We are building the world’s longest DrupalCon session and packing all 6+ hours of it with information and personalities you won’t want to miss! So actually ... For our one hour in the spotlight in Mumbai, we’ve been doing a lot of preparation. Our “session” will include a lot of additional materials like podcasts and blog posts about what we’ve learned along the way.

Our session, Meet PHP-FIG: Your community just got a whole lot bigger, Drupal is about Drupal 8’s membership in the new, interoperable PHP community. We’re covering the basics of what the PHP Framework Interoperability Group (PHP-FIG) is, what the various PSRs are and do, talk about testing and dependency management, and what it means to be a part of the new PHP community — including having better architecture, cleaner code, and more interoperability. All of this adds up to a big move to get projects “off their islands,” saving developers a lot of code, and companies a lot of money, among other benefits.

I apologize for the poor audio quality in this recording and hope the quality of the conversation makes up for it.

“I don’t want to speak to PHP from Drupal. I don’t want to speak to Drupal from PHP because that implies that those are different things that aren’t a part of each other or that I’m part of one talking to the other. That’s not the point. The point is that Drupal and PHP are not separate entities. Drupal is part of the PHP world and the PHP world is part of Drupal. That collaboration has helped us produce Drupal 8 and that collaboration I’m sure would continue to produce not just future versions of Drupal but better practices, more robust practices in PHP itself. So I would encourage everyone from these two large robust communities ... don’t look at them as two large robust communities. Look at them as different pockets of one larger community that we can all learn from, that we can all benefit from, and together we can build a better PHP for all projects.”

More by or featuring Larry, further reading

  1. Getting off the island in 2013
  2. Building Bridges: Linking Islands (2014)
  3. Drupal & PHP: Linking Islands, the podcast – part 1
  4. Drupal & PHP: Linking Islands, the podcast – part 2
  5. Drupal 8: Happy, but not satisfied
  6. Larry’s challenge for us: “Giving Back in 2016. Contribute to other projects. Get your name on the contributors list for a new open source project.”

Interview video - 43 min.

What is the PHP FIG--PHP Framework Interoperability Group--for and does it have something like a mission statement?

Larry: Okay. So a history lesson. The Framework Interoperability Group began life at php[tek] in 2009 in Chicago as the PHP Standards Group. We got together in a hotel room and said “With PHP 5.3 coming out and all these namespaces, it would be really cool if we all use them the same way and hey, we could do some cool autoloading stuff with that.” So the original goal was simply “Let’s collaborate and push this out to the community.” It was renamed to the Framework Interoperability Group in I think 2012. It didn’t really do anything more useful for several years.

In practice these days, pretty much any project that matters is using either the PSR-0 or PSR-4 autoloading standard. A project that doesn’t then has a huge amount of pressure to start doing so.

The PSR-2 coding standards: Most projects that are just random projects have now adopted tooling PhpStorm and phpcs, support by default, and there’s pressure on projects like Drupal that don’t use it to start using it just for conformity’s sake.

If you’re going to do anything new with HTTP messages now and you’re not already using Symfony’s HTTP foundation, you’re foolish to not use PSR-7 or something very close to PSR-7 because there’s a lot of tooling and tools built on top of that already.

So who are the members of the FIG group these days?

Larry: There’s I think 41 or 42 members now. I don’t remember all of them off the top of my head. They’re listed on the website. I’ll say they include pretty much very major project except Wordpress. So Symfony, Zend, Drupal, Joomla, phpBB, about a dozen libraries like Monolog or Stash or Doctrine, some smaller libraries you may not have heard as much about like Jackalope. It really runs the gamut from really big players like Drupal to really small players like Jackalope and everything in the middle.

What are some valid reasons why projects like Wordpress or individual developers would choose to ignore this interoperability movement, not take advantage of the PSR standards?

Larry: I think the biggest reason that projects wouldn’t follow PSR is legacy code bases. If you have a code base that’s been around for eight, 10 years or even just five years, you probably have a lot of internal conventions already built up and changing them is hard. Not like Drupal knows anything about that. ;-) So for a project like Wordpress where mission statement number one is backward compatibility, switching their logging system to use the PSR-3 logger would be an API break or at least extra API clumsiness so they’re not willing to do that. Certainly for a project by Drupal, switching our coding standards to PSR-2, whatever the technical benefits or downsides to that are, regardless of whether PSR-2 is a good spec or a bad spec, would mean changing literally millions of lines of code. It could be scripted to cover 98% of it fairly easily, but it still means every single patch and every single person’s local configuration and defaults in their IDE change. That’s not a small ask. So I think the biggest impediment to PSR adoption is simply existing standards, existing code bases, existing practices, which are sometimes legitimate complaints and sometimes not.

Actually, there’s one comment which you made in your Drupal 8 launch blog post which I recommend for everybody to read ...

... continued: You mentioned actually one of the most significant things about the launch of Drupal 8 is proving that it is possible. Before we manage to do this, it was an open question, is it possible for the entire community to retool, change the entire API method of thinking and switch to object-oriented concepts and unit testability. We managed to drag one of the world’s largest open source communities through that and successfully launched a product. You’re right. It’s an enormous undertaking to understand other projects not wanting to do that.

Larry: I actually have a keynote that I gave called Eating Elephants that is that exact point of this is a lot of work. If Drupal can pull it off, so can anybody, but it’s still a lot of work. Not every project necessarily wants to go through that, the level of overhaul that Drupal did and not necessarilyevery project needs to. But I think over time, simply through natural project churn, most of the standards are going to become widespread in practice.

What are the choices that people should be making now outside of implementing the PSRs?

... continued: So outside of FIG, of course FIG is just one part of a broader movement for interoperability and standard behaviors across no matter what it is you’re building with PHP. So what are some of the architectural implications of this exciting new world? What are the choices that people should be making now outside of implementing the PSRs?

Larry: I think the most important, just general good modern practices for collaboration these days are:

  • use a PSR-based autoloader because everyone else is. It just using your code and sharing your code dead simple.
  • Register it with Packagist because then getting it through Composer is dead simple.
  • Use proper dependency injection because that makes it a lot easier to swap out pieces and plug your system into someone else’s ...
  • ... which also means build your code in small standalone components rather than one big monolithic system.

This is really a movement that Symfony started with Symfony 2. It was the first project to really have a component library that was loosely coupled and then built a framework on top of it. Others have since done the same. Zend Framework 3 is moving heavily in that direction. The Aura project is strictly decoupled components with a framework built on top. A lot of major components now are completely standalone.

I think the biggest thing is think in terms of small, discrete pieces that you can mix and match. Same kind of Lego block approach that Drupal has striven for at the module level for years, even though we didn’t do a very good job of it at the code level all the time. We’re getting better. The more you do that, the easier it is to exchange code with people, the easier it is to reuse code, and also the easier it is to test.

Good unit testable code is also loosely coupled, is also easy to swap out, is easy to reason about. All of these concepts overlap on each other.

Testability, understandability, debuggability, ability to share with others all have the same underlying structure, underlying needs. So focusing on any one of those will make the others better.

What are some wheels that we decided to bring in from outside in Drupal 8, rather than reinventing them?

Larry: So the big first wheel we got from elsewhere was our routing system which we pulled in from Symfony and along with that, a new architecture that spread throughout the rest of the system and took over. The template engine, of course, Twig is new and that’s been a huge win. Everything I’ve heard front enders adore it. That’s third-party code. The places we didn’t, the configuration system is primarily homegrown in large part because we needed the UI integration for it. Symfony’s configuration system, for example, assumes you’re doing configuration by editing files on disk. Drupal assumes you’re doing configuration by pushing buttons in the UI. These are fundamentally different assumptions and that same underlying tooling that supports one is not really going to support the other. Not very well.

Drupal’s coming to the fold or gotten, become part of main line PHP. Talk about how this new world of interoperability has allowed Drupal to start making contributions outwards into other systems and other frameworks, other applications.

Larry: Honestly, I think at the moment, our biggest contributions are patches we’ve submitted to other projects, be that Symfony, Guzzle, Zend, whatever. Just being the poster child for this new PHP world. Drupal, being a demonstration that yes, it is possible to teach an old CMS new tricks, yes it is possible to embrace these modern tools and techniques, yes there’s benefits to doing so, you will survive. Honestly, I think that’s our biggest contribution is just proving that it can be done. We’re not the only project that has adopted lots of Symfony but I think just the evolutionary pressure we give that way is probably the biggest impact. It’s that the proof is in the Drupal 8 release, that it is a thing and it can be done and we should continue to provide that example of growth and of maturity enough to admit that you can change things. I think that’s probably our biggest contribution to PHP at the moment.

So OO isn't so hard after all ...

... continued: I think early on when we were talking inside the community about adopting object oriented practices, about adopting some of the Symfony. A lot of the conversation was around Drupal being not so accessible for newbie programmers, people coming to write their first lines of code. It seems like it’s so much easier when it’s procedural. What I’m most excited about with Drupal 8 is watching what happens in the next two or three years as we demonstrate that anybody can code with modern practices, too. And that in fact, it makes it easy. If you can learn how an IF statement works, you can understand what a class is. So I think that’s another cultural export that we’re offering the rest of the PHP world.

Larry: You don’t have to be a comp sci grad from school in order to write in modern object-oriented code. We have thousands of people now from Drupal who have picked it up without being in school for it and are liking it.

In the last few years, you’ve done a series of posts and sort of challenges to I guess the broader PHP world.

... continued: Initially, “Hey Drupal, we’ve got to get off our island and accept that we shouldn’t carry all this liability ourselves.” Then there was a building bridges post which said “Go visit people in other communities” and there was a challenge this year, build something in a project that’s not your home project. What’s your mission statement and challenge for all of us in 2016?

Larry: I know what I’m going to say. First one was go out and learn from other projects. The second one was go out and build with other projects. So I’ll say it now. Your challenge for this next year, contribute to other projects. Your goal is to get your name on the contributor’s list for a new open source project, some project that’s not your home project.

Add comment

By submitting this form, you accept the Mollom privacy policy.