To custom code or not custom code

We recently had the chance to rework the blog for Onbeing.org. While there are several improvements like adaptive images via Drupal’s Picture and Breakpoints modules, more structured and portable content, and a templated design/look, I want to focus on the decision that developers face in almost any Drupal project: use contributed modules or write custom code.

This has been a topic recently for several Drupal developers:

Mike Crittenden Drupal’s Golden Handcuffs http://mikecr.it/ramblings/drupals-golden-handcuffs and

Michael Prasuhn Understanding how custom code can help you build your Drupal site http://shomeya.com/articles/understanding-how-custom-code-can-help-you-build-your-drupal-site.

Both Mikes advocate writing custom code especially when the solutions around contributed modules become complex or fragile.

One of the features we wanted on the blog redo was previous/next links per blog post. I immediately looked at the usual contributed modules for this Custom Pagers (had good luck with this in Drupal 6), Previous Next API and Flippy.

I think the issues I ran into here are typical. Custom Pagers does not have a Drupal 7 release, Previous Next Api only has an alpha release for Drupal 7 and Flippy only works per content type (we needed multiple content types). So I gave previous next api a try. It was straight forward enough to get Previous Next API working and it looked good for a while until I found it was including unpublished nodes. So I looked at the issue queue. No similar issues. I looked at the code and saw no obvious reasons why. Crap, now I am left with deep debugging and a rapidly approaching deadline.

My next thought was: what are the real requirements for this feature? Really its a finding all the nodes in 2 content types, sorting them most recent first and then find the current nodes previous and next neighbors.

To translate this into something resembling code, use Entity Field Query to get all the node ids published nodes of in two content types, sort by created date Descending and return an array of these node ids. Then loop through the area finding the current node id, use prev and next functions to point the array at the prev and next values in the array and save them. Add a theme function and caching to round it out.

All this only took a few hours. You may say this does not benefit the community.  If you would have debugged an exiting module and committed a patch, the community would have benefitted more. This is true to an extent but it would not have helped us meet our deadline. Furthermore, it’s too easy to get into site building and theming mode where you throw together some views, do some theming and CSS and never get into the Drupal API. I know there are Drupal developers that are stuck exactly in this place. I was at one point. Not knowing much of the API becomes a problem when contributed modules don’t give you the exact functionality you need. It’s at this point where you need to start coding. It makes sense to pick and choose spots to write custom code.

Here is my take on a previous next module as a sandbox project. https://drupal.org/sandbox/ghankstef/2030901