Custom Drupal development is not for the faint of heart. If you are a developer with little concern for maintainability, reusability, readability, or extensibility, then you may not struggle - there are many, many ways to approach any particular problem. However, if you're like me and have to carefully consider these core concepts before you proceed, then creating Drupal modules to solve a particular business problem requires a lot information at hand. Personally, I think the design patterns used in Drupal are conceptually approachable for even a fresh Computer Science graduate. But for a beginner to Drupal, the core problem is the vast quantity of entry points and useful modules to know before you can make good decisions.
The intended audience of this blog post is for intermediate to advanced back-end PHP developers trying to solve simple to complex business problems. Content administrators, site administrators, themers and designers have different challenges with Drupal. Junior PHP developers will likely take a very different approach to the same set of challenges.
Great Modules are Easy to Find - Research and Use Them
Before you type up a shred of your own code, you must look at what community contributions there are. I've found that compared to a lot of other frameworks, the quality of the code that makes it onto drupal.org is extremely high. All online modules require a vetting process that is fairly thorough. Also, it is quite easy to look at a module and get a feel if it has fallen onto hard times. Usage statistics, bug reports, dates of changes, and details about active maintainers are front and centre on the pages.
There are plenty of "Top X modules for Drupal" to get ideas. A search for "Drupal <Module X> vs <Module Y>" will get you what you need to know when comparing two similar modules. However, for me, the best tool has been Google searches for "<What I'm interested in> site:drupal.org/project/". That will effectively search through the summaries of every module. Many modules will contain links to documentation, so be sure to search the page for that when you're looking to dig further.
Finding great modules is important for many reasons. Two of my favourites are:
- Don't reinvent the wheel. You'll end up repeating the mistakes of your predecessors.
- Well written modules can be glued together with minimal code (although not minimal effort). Minimizing code is one of the best ways to make your code maintainable.
Unfortunately, it can still be very easy to pull modules together in a poorly maintained fashion. Drupal is flexible enough, there are many ways to approach a problem - but a lot of them are headaches for future developers. Study the design patterns used, keep your code simple, avoid complex hacks, and make ample use of flexible, popular modules like Features, Views, Panels and Rules.
Learn your Hooks
As a new Drupal developer, it can be very challenging to identify the "best" entry/access points to solve a problem. I know of no better way than to gain a strong recollection memory of all the available APIs. Of course, written memory of every single one is not necessary, since documentation and code is easily accessible. However, knowing what hooks and helper functions exist is crucial to making good choices. It can make the difference between an awkward hack, 500 lines of code, hours of xdebug tracing, or 10 lines of simple code.
Most code you'll write as a beginner should be geared towards taking existing functionality that is extremely close to your requirements, studying documentation carefully, and writing a few small hooks that finish the job. Simple "glue" code.
Between modules, core hooks and module hooks, you have your memorization cut out for you before you can even write good "glue" code. I will say it again - Drupal is not for the faint of heart.
Learn How to Structure your Modules - Organization and Optimization
I think it goes without saying that structuring your module in a clear manner enhances readability immensely. However, since Drupal revolves mainly around hooks, it can be challenging in many cases to organize your module by logical task. The approaches I would take do not seem popular in the Drupal community. Personally, I would like to make sure hooks are all a few lines long and simply call functions found in other files that are then organized by task. However, Drupal does come with a decent autoloader for classes. So, if you are doing heavily related tasks that would benefit from OO programming, you can consider that as a tool for organizing.
Since organizing by task does not seem popular, I would suggest organizing by related hooks. Many modules will allow you to put the hooks in specifically named files (such as through hook_hook_info() or through ctools api loading). Not only does this help with a bit of code readability (if the reader has already learned similar organizing techniques), but keeping your .module file lean is simply good for optimization. Most of the organization rules are there because the hooks won't be needed on every page load. I've seen the memory footprint APC requires to be useful on a site with 200 modules enabled - not pretty. Whereas I've made extremely useful "glue" modules that contain zero code in the .module file.
I have ironically already started referring to some hooks and modules that are useful to know about in this section as a demonstration of my earlier points :)
No Entry Point into the Menu is Unnerving
I won't go into too much detail here, but the menu/URL structure is dangerously close to being in the same memorization category as hooks and modules. Clever regex greps of files can often capture the menu structure - as can digging into some database tables. However, some menu items will really only be identifiable through good xdebug breakpoints. Luckily, there is usually a great deal of logic to menu systems, once you get to know it. However, it is definitely an additional piece to make entry into learning Drupal more challenging.
Just do Yourself a Favour and Clear the Cache Constantly
The caching mechanisms of Drupal are easy to access and are heavily used. There are at least 7 clearly distinct caches in core alone. Fortunately, as a beginner, you can easily avoid learning what caches to clear, when and why. Just stick to clearing them all until you've mastered more important things. Drush can make the task easy enough that it won't slow you down much.
Thank you for your time in reading my thoughts. If you have any early lessons in Drupal development you'd like to share, then I would love to hear them. I would like to take the step to experienced Drupal developer by creating a developer module to make some of the above tasks easier to learn. Hooks and, to a lesser extent, menu items seem like ripe pickings.