Drupal finally using OOP

Finally. This is a huge step forward for Drupal. After eschewing OOP practices for a long time, its finally winning over core developers, which will make working with Drupal as a Framework easier in many ways. I copied the announcement below, but you can see that patch and discussion here.

This patch is about to be committed. It is the foundation to change for example $comment from an stdClass to a comment specific class allowing for $comment->save(). This is a monumental change and everyone is invited to review and familiarize with the new system even before it is committed.

What is possible when you use proper classes? The first thing I envision is a plugin/pluggable system in the same way that Zend Framework allows you to use Controller Plugins and View Helpers from a pluggable object, without the need to inherit or compose an object. For example, in a Zend View, you can call a partial like this:

{syntaxhighlighter php}

partial(‘my-partial.html’);
?>

Now, the View class doesn’t have a method named partial, instead the magic __call method intercepts the call, gets the Partial view helper, and calls its invoke method.

Grokking Zend Framework 2

I’ve found these to be helpful in porting a ZF1 app to ZF2, which is in Beta1 status at the moment.  Rob Allen’s tutorial -updated for the beta, worked for me out of the box using git submodule.  The programmers reference manual for groking new concepts, although sometimes it takes a couple of reads. Finally, looking at the code for the EdpUser module helped me figure out how to use DI and how to structure a functional module.

Once you start to understand the Dependency Injection container and the new Module bootstrap, in many ways its easier to get up and running than with ZF1.  I love that modules are first class citizens in the new MVC implementation.

Frustration with Drupal core growing

When a prominent developer and contributor lashes out that Drupal is in dire straits, you better listen.  You ought to read his critique of how Drupal core development is stalling, or at least stuck in the mud.  That can’t be good news for anyone looking to upgrade to Drupal 7.  My thoughts after the quote.

In addition to the half-baked, single-purpose product features mentioned above, Drupal core still carries around very old cruft from earlier days, which no one cares for. All of these features are not core functionality of a flexible, modular, and extensible system Drupal pretends to be. They are poor and inflexible product features being based on APIs and concepts that Drupal core allowed for, five and more years ago.

Where would Drupal be if they had worked more closely with the PHP community early on?  I have no idea, but a lot of PHP programmers have looked down on Drupal because most of the codebase can be messy, with poor API design decisions, overuse of globals, and leaky separation of concerns. Along with Drupal eschewing Object Oriented Programming and resulting best practices, its no wonder that talented developers would choose to use a framework like Zend, Symfony, or Cake to build a complicated website.  It sounds like a lot of short cuts and idiosyncrasies are now baked deep into Drupal core, and ripping them out too much work for core developers.

I’ve always thought that Drupal’s greatest strength is certainly not the great design of its codebase, but the Drupal community and ecosystem. A contrib module usally exists for many common website needs, like managing redirects, creating useful URLs for content, integrating with analytics,  and plugging in 3rd party commenting systems.  On top of that, there are super-modules like Views, Panels, and Context, which let you prototype and build parts of a website without having to write any code at all.  The Drupal community has solved a lot of problems through determination and individual brilliance, but that model can’t be sustainable in the long run.

Is there a solution?

Drupal core should cater to programmer’s needs, via coherent APIs and pluggable subsytems.  A complete rewrite of core, or even big parts of core, would be a waste of time. Drupal would stagnate while other frameworks kept improving.  I think Drupal 8 should seriously consider using a framework like Symfony2 as the foundation for core.  I mention Symfony because it has an EventDispatcher component that can replace most of Drupal’s magical hooks system.  The next release of the Zend Framework will have a similar component. A tested framework, used not just by content management applications would expose developers to a wider range of best practices, particularly around configuration management, deploytment, and unit testing.

Contrib should cater to site builders needs and focus on adding features on top of core that they want.  Modules in contrib can improve faster to meet user needs, fix bugs, and innovate.  This is an idea proposed in the discussion linked above. Moving as many modules as possible out of core also makes Drupal leaner.

Using OpenId for Authentication

Cal Evans wrote a straightforward and excellent tutorial on how to to use Zend_Auth and its OpenID adapter to authenticate users today.  I was not only impressed by the tutorial itself, and I liked how he had code up front and so well commented, but also by how easy it was to implement the code here on my blog.  This was my first practical look at the Zend Framework, and the only gotcha I encountered was that it threw an Exception because I’d used session_start, but it provides its own classes to handle sessions. 

Unlike Cal, I did have luck in finding information on using AOL as an OpenID provider.  It was the first result when I googled for OpenId and AOL.  The short of it is that if you have an AOL IM account, you can login wherever you see OpenId, as on the sidebar here.   Heres what I’v been able to find about providers:

  1. AOL – your Openid URL is of the form http://openid.aol.com/SCREENNAME, replace SCREENAME with your IM username.
  2. Google – if you have a Blogger account, you have to enable it and then you can use your blog’s url as an openid url
  3. Yahoo! can provide openid, but you have to enable it.  The usability is pretty poor, as the first url it gave me as my OpenID identifier looked like  some weird hash token.  But you can chose an easier to remember one, or use your flickr url as an identifier if you have one.

There are more providers listed on openid.net.  If you have an account with AOL or Yahoo! and want to know what all the fuss is about regarding OpenID, try leaving me a comment!