For the past year, all of my Drupal work has been devoted to building a product on top of Drupal. In the beginning of the year, I worked with the Science Collaboration Framework to create PD Online. For the past 7 months, I have been with GoingOn building a social education platform on top of Drupal. I hope I will have the opportunity to tell you everything I have learned at Drupalcon in the Building a Product on top of Drupal session held by Tao Starbow and I.

When I first heard of the goals of the Science Collaboration Framework, by brain started racing for possible solutions to the myriad of obstacles that needed to be overcome in order to essentially create a product on top of Drupal. At the end of the project, I had figured out how to:

• Set up distributed development amongst a 6 person team
• Enable “branching” from production, so editors and users can submit content while development is done elsewhere
• Deploy reliably to test, staging and production environments

Although those were some big accomplishments in the world of Drupal development, they didn’t solve the issue of creating a product on top of Drupal. When I sat down and heard the problems GoingOn is trying to solve, I had to immediately scrap my most useful tool: DBScripts. Two years of work there!!

I had to go back to the grind stone and figure out another solution, or rather, a whole new set of solutions that together could enable me to build a product with Drupal. Lucky for me, though, the Drupal community has been working on many of these problems, too, and by this last Fall, there is now a more robust exportables system thanks to the work of Earl Miles and all the other ctools developers, and Development Seed for creating ‘faux’ exportables of some Drupal-core areas and managing the exports easier with features.

Here are a few approaches I have been taking while building this product for GoingOn:

• Everything in code. Absolutely no configuration is done in the database, and hook_update_N() has become my good friend
• Building an expanded API. The APIs provided in Drupal-core and contributed modules are frequently lackluster, so we had to build our own in order to speed up development time
• Maximizing exportables. We utilize hook_<foo>_alter() to get even more usefulness out of exportables and save me a lot of time
• Environment variables. Automatically set different configuration settings for when the site is in ‘development’ or when it is in ‘production’ or ‘readonly’ modes
• Abstracting permissions. Developed a permission set system so neither we nor our users have to face the permissions matrix of doom
• Managing company users. Protect user1, and automatically provide a user for each individual in our company, across all our websites automatically, and protect those users from being modified by our clients
• Unit testing. One cannot manage 10s of thousands of lines of code without an automated testing system
• Improving the installation process. Simplified install profiles and maximized hook_install()
• Standardizing documentation. A standardized, straightforward README in every module, and abiding by documentation coding practices makes it easier for team members to grok the codebase

And much much more! Come find me at Drupalcon San Francisco and I’ll talk your ear off on my experiences and everything I have figured out. If I’m lucky, Tao Starbow and I will have the opportunity to speak about these issues in our session