At Fuse we work exclusively with Drupal. Every project starts with an assessment of what we need to do for a clients site and ultimately how we'll do it with Drupal. We tend to sell our clients and ourselves on the fact that the Drupal framework can do pretty much anything and with the plethora of contributed modules it pretty much can.
That is... until it can't.
Any Drupal developer will tell you that they've had more than their fair share of run-ins with missing functionality or bugs in contributed code that are show stoppers for a client's site. Functionality that just has to be there or has to work properly or the project won't pass QA.
In my experience, there have been two ways we deal with these run-ins.
The first and most common option is to go around Drupal. Drupal is PHP and I know PHP. I can code my way out of any hole. Drupal makes it so easy to tie into its "bits and hooks" at any level of the stack that I can easily write custom code, custom modules or if Iâm desperate, hack a contrib module and mark it as a "do not update" in a random README somewhere within the clients files. Easy, done and I can all but forget about it until something breaks.
The second option is to go right through Drupal. To some developers, this sounds scary. To some managers, this is out of the question. So much potential learning and reading and stuff. You might need to have a good grasp on what functionality is missing or what exactly is causing something to break. You might need to comment on an issue queue or two, or even worse, apply a patch! Gross! Almost seems not worth it.
Here's the thing. The second option should be the only option. It should be an understood cost of working with Drupal. It should be written into the license agreement. We get so much for free that we should all feel obligated to return something, anything to the Drupal community. Project success shouldn't only be measured with timelines and budgets, but also with the amount of community involvement that the project was able to generate.
When I started thinking about this mindset for working with Drupal, I thought it would be a good idea to actually give it a try instead of waxing idiotic. I made a decision that the next project we took on would be made entirely of what was available in core and contrib. If changes were needed, they would be found in issue queues, tested, RTBCâd or written ourselves and contributed.
The project that came in wasn't a huge site, but definitely wasn't a simple brochure site. It's multilingual, has a few unique functionality requirements and requires the most dead simple management interface possible. Not a seemingly insurmountable challenge, but when you throw budgets, an aggressive timeline and a new relationship with a client into the mix it could be hard to not slide back into the old steady.
Anyways...
We've completed the configuration phase and we're about 90% complete with theming. Not including a few lines of code in the template.php file (specific to the theme) and three lines of code in two views to provide some default argument handling (which may lead to a useful contrib module), we have not written one line of custom code.
A total of 7 patches have been written or applied to add or fix functionality, 3 which have been RTBCâd and subsequently committed to the dev releases. Awesome! That means for the next release of those modules we can update and everything will work as normal. This is good for the Drupal community, it's good for our client, but most importantly it's good for us. We have less to maintain long term and we can focus on adding functionality for our clients instead of fixing code that we wrote ourselves.
As an added bonus, we also now have a better understanding of how core and some contrib modules work by digging through code and figuring out where and why things are broken. We've increased our knowledge of the contrib modules available and how we can combine them to get exactly the functionality we need. We've instantly gained thousands of team members that are constantly fixing, testing and improving every piece of our clients code, and most importantly, we've paid something back to the community that helps make our company possible.
What can you do?
The first step is to google, bing or duckduck. Whatever you want, but search and read. There's a huge chance that someone somewhere was looking for the same functionality you need and found it or made a contrib module to handle it. The key is, knowing what you need and the Drupal terminology that would be used to describe it.
If it's a bug you're dealing with. The issue queue is your best friend. Every module has one and they're easy to search. Again, knowing the problem you're having is helpful so digging through the code and discovering pertinent information is paramount.
When you've exhausted all your options and your only choice is to write some custom code, think contrib first. Break down the module into two parts. What is specific to the site you are working on and what could be useful to other projects you may be building in the future. Even better, what could be useful to the Drupal community?
Ultimately, participating and contributing to the Drupal community is a low cost for using it day in and day out, and, for me, happens to be a rewarding one.
When you have free time an easy way to get started is the novice issue queue.
http://drupal.org/project/issues/search/drupal?issue_tags=Novice
These are issues that should be approachable by anyone. They include simple patch reviews, documentation edits, etc....