It’s often said that building sites with Drupal is like building from a bucket of legos. Some of the bricks stand well on their own, some are better suited for bridging the gap between two bricks that don’t quite fit together themselves, all of the bricks shine when used together to create a more cohesive whole.
As of this writing there are almost 23,000 modules listed on drupal.org with new ones being added every day. It’s getting crowded in contrib and if you want to make friends you’re going to want to follow a few best practice techniques to make sure your custom code is extensible, doesn’t step on anyone else’s feet and in general is written to play nice with others.
Well written modules lend themselves to being reused over, and over, and over. Save yourself some time in the long run by investing in designing a good API up-front and leave yourself with code that can be reused again, and again. If you do it right you can even handle all of your project specific special cases while still maintaining a reusable code base.
This session will discuss best practices for ensuring that your module isn’t going to conflict with code written by someone else. Exposing your own API and allowing other modules to respond to actions in your code or to modify the way your module handles certain operations without having to modify your code whatsoever. We will also discuss some common pitfalls that can prevent other modules from being able to make use of your reusable code, and I’m sure some other gems too.
This session is for anyone that may find themselves writing Drupal module's, especially those interested in creating reusable tools either for themselves or to share with the Drupal community.
- How and when to expose your own hooks.
- Why should my module allow others to alter my precious data?
- How do I allow other modules to modify my module’s precious data?
- Patterns for breaking up your code into smaller, more reusable bits.
- Examples of the other modules that make good & bad use of these patterns.