About Drupal
Drupal is a great platform for the creation of all kinds of websites, particularly those with user-contributed content such as social networking sites.
Check this page for articles and links about Drupal development.
Best books for Drupal development
Pro Drupal Development, Second Edition (Pro)
An absolute must for the serious Drupal developer. This is one book I find myself referring to time and again. The modular organization of Drupal is reflected in the book, which makes it very easy to use, since most of the time you can go straight to the chapter you want.
Once you've bought it you can also buy a second copy in e-book form from the Apress website, which makes it even more useful.
Amazon Price: $29.69 (as of 07/05/2008)
Drupal 5 Themes
Covers the subject of theming in more depth than Pro Drupal Development. I don't regard this as an absolutely essential purchase but for anyone who's new to Drupal theming it does provide a lot of very useful information.
Amazon Price: $35.99 (as of 07/05/2008)
Drupal Links
- Drupal's home site
- Drupal's home site is the best place to start for learning about the software, getting help with questions and downloading code.
- Dries Buytaert's blog
- Dries invented Drupal. All hail!
- Articles by Lullabot
- Lullabot is a consultancy specialising in Drupal and I find their articles very stimulating and insightful.
- My own blog articles about Drupal
- Articles from my own blog covering Drupal development topics such as theme and module writing.
- My Drupal portfolio
- Some Drupal sites I've worked on recently.
My favourite Drupal modules
Ten modules I use time and time again
1. Content Construction Kit. Practically any major site will need some custom fields. CCK and the many available modules that build on it are vital tools.
2. Views. You want lists and tables of your content? Views will give it to you.
3. FCKEditor. The best of the WYSIWYG editors, I reckon. Couple it with IMCE for a very cool content editing solution.
4. Devel. Amazingly helpful to anyone doing module development. Baffling to everyone else!
5. Module Weight. Another developer must-have. It doesn't do much but making sure things happen in the right order can be vital.
6. Path Redirect. Who moved my pages? When you've reorganised or redeveloped a site, don't serve your users yucky 404s, serve them yummy 301s and keep them satisfied.
7. Pauthauto. Give your site nice, clean, SEO-friendly, URLs - automatically.
8. Update Status. Ensure your site stays fit and healthy by making sure you see when new versions of modules are available. Especially important to ensure you stay abreast of security alerts. Part of core in Drupal 6.
9. Organic Groups. Love it or hate it - and it can pose a challenge to developers at times - OG solves a wide range of content access problems, so it deserves a place in every Drupal toolkit.
10. Event. More vital functionality, though like OG sometimes it's tricky to get working correctly. (It's been rewritten recently and hopefully it'll prove a little more reliable in future.)
2. Views. You want lists and tables of your content? Views will give it to you.
3. FCKEditor. The best of the WYSIWYG editors, I reckon. Couple it with IMCE for a very cool content editing solution.
4. Devel. Amazingly helpful to anyone doing module development. Baffling to everyone else!
5. Module Weight. Another developer must-have. It doesn't do much but making sure things happen in the right order can be vital.
6. Path Redirect. Who moved my pages? When you've reorganised or redeveloped a site, don't serve your users yucky 404s, serve them yummy 301s and keep them satisfied.
7. Pauthauto. Give your site nice, clean, SEO-friendly, URLs - automatically.
8. Update Status. Ensure your site stays fit and healthy by making sure you see when new versions of modules are available. Especially important to ensure you stay abreast of security alerts. Part of core in Drupal 6.
9. Organic Groups. Love it or hate it - and it can pose a challenge to developers at times - OG solves a wide range of content access problems, so it deserves a place in every Drupal toolkit.
10. Event. More vital functionality, though like OG sometimes it's tricky to get working correctly. (It's been rewritten recently and hopefully it'll prove a little more reliable in future.)
My latest articles on Drupal
Fetching RSS feed... please stand byHow Drupal modules work
If you wonder how modules work in Drupal, this short guide will give you some idea of the thinking behind Drupal's module API. You'll need some familiarity with PHP to follow it, but I've tred not to get too tecchnical.
The Drupal module system is not object-oriented. Instead it uses a function naming convention, as we'll see. This has both advantages and disadvantages, but the strength of any API is not in the programming paradigm but in the design choices made within it. There are some awful OO APIs as well as some great ones, and the same is true of procedural APIs. I'd characterise Drupal's API as very practical, with some minor flaws and annoyances.
Drupal uses the 'hook' concept, which is a very old and well-tried one. The idea is that at key processing points the programer tests for the existence of modules which implement the hook, then calls those that do.
In Drupal's case this works as follows: each active module registers a unique identifying string eg 'my_module' which is to be used as the prefix for its functions. To implement a particular hook the programmer simply writes a function of the appropriate name. So to implement the 'menu' hook which creates menu entries, a function called 'my_module_menu' needs to be written.
To write such a function you need to know what arguments will be passed and the format of the expected return value, which you can find in the documentation of the hooks API.
The strength of this approach is that the additional functionality to be provided by a module is relatively tightly constrained, thus making it harder for system integrity to be compromised. The same strength may also be a weakness if the designer of the calling code, failing to understand some likely requirements, makes the hook interface too narrow in scope.
Because of the maturity of Drupal and the generally sound approach taken by Dries Buytaert and others who've worked on it, the hooks in the core API provide a good balance between extensibility and robustness.
The same cannot always be said for contributed modules, which if they do provide hooks of their own are seldom of such a high quality. That is probably inevitable, but it's one of the frustrations of working with august modules as CCK and Views that they are not as flexible as the Drupal core.
As well as the hooks API, which executes functions in your module, Drupal also provides a large number of functions that your module's functions can themselves make use of. The documentation of these other API functions is also excellent.
A separate API system is used for the "theming" (UI components) of Drupal sites. I'll be writing another article about that for this page.
The Drupal module system is not object-oriented. Instead it uses a function naming convention, as we'll see. This has both advantages and disadvantages, but the strength of any API is not in the programming paradigm but in the design choices made within it. There are some awful OO APIs as well as some great ones, and the same is true of procedural APIs. I'd characterise Drupal's API as very practical, with some minor flaws and annoyances.
Drupal uses the 'hook' concept, which is a very old and well-tried one. The idea is that at key processing points the programer tests for the existence of modules which implement the hook, then calls those that do.
In Drupal's case this works as follows: each active module registers a unique identifying string eg 'my_module' which is to be used as the prefix for its functions. To implement a particular hook the programmer simply writes a function of the appropriate name. So to implement the 'menu' hook which creates menu entries, a function called 'my_module_menu' needs to be written.
To write such a function you need to know what arguments will be passed and the format of the expected return value, which you can find in the documentation of the hooks API.
The strength of this approach is that the additional functionality to be provided by a module is relatively tightly constrained, thus making it harder for system integrity to be compromised. The same strength may also be a weakness if the designer of the calling code, failing to understand some likely requirements, makes the hook interface too narrow in scope.
Because of the maturity of Drupal and the generally sound approach taken by Dries Buytaert and others who've worked on it, the hooks in the core API provide a good balance between extensibility and robustness.
The same cannot always be said for contributed modules, which if they do provide hooks of their own are seldom of such a high quality. That is probably inevitable, but it's one of the frustrations of working with august modules as CCK and Views that they are not as flexible as the Drupal core.
As well as the hooks API, which executes functions in your module, Drupal also provides a large number of functions that your module's functions can themselves make use of. The documentation of these other API functions is also excellent.
A separate API system is used for the "theming" (UI components) of Drupal sites. I'll be writing another article about that for this page.
