Monday, 21 January 2013

Flirting with a Drupal module


Many times I'm dealing with new Drupal modules. Usually the coders writing those modules are not always UX experts. But even if they are, trust me I can easily get lost when taking the first steps. So I'll share with you what I usually do when I check a new module I intend to use.

If I don't know the exact solution I often look at the Drupal usage stats page. Here you can find all the modules (not sandbox) ordered by usage. Don't take it as an only evaluation scale of the module - many modules are used because the new kid on the block is not yet discovered, or some module just not meant to be on production (as usage stats mainly for prod sites). So there you can find quite some modules hopefully that just sound good.

Inspecting them a bit more you can see the chart falling rates. Well, we're not a Hans Rosling but we can make some judgement by taking a quick look at the chart. Then the module page shows the description - we like it or not. Don't forget to check for the [documentation] link on the sidebar, that's pretty important. Then comes the critical part, on the same right side the bug and issue report. Always read through the open bug reports! You can easily spot what could cause problem in your environment.

Now, if you're still in your dreamworld thinking that the module won't launch the rocket silos (just kidding) you can download it. Being a developer you shouldn't miss checking the source. I'm one of the superlame guys who couldn't find the menus on the UI. So I go to the module file and check hook_menu. There you will know where are the UI anchors. You sure checked those pages - looking cool, *whew*.

Then look for alter points: drupal_alter, module_invoke, call_user_func_array, module_implements. It's an indicator how cooperative the module is in general. Trust me, drupal_alter is like your best pal who rents his girlfriend whenever you want.

Now it's also worth to check what APIs (less core-ish) it uses: check for hook implementations - it's nice when Drupal is used well.
Very crucial part can be if it's working with exportable items, using CTools or Features API. A little trick I do sometimes is looking for module_exists. That check the existence of another useful module that can add extra to the functionality and that's the only way you can be informed about that.

And finally we check the renderables. How well it uses the theming later, hook_theme, preprocessors and templates. Maybe look for form element definitions, formatters and widgets.

Then you can earn the semi-geek lover badge :) Congratulations. One day I'll share with you the uber-geek lover recipe for module recognition.

---

Did I miss any step when one want to meet a new module?

All right I tell you the short evaluation of a module: shout the name in public -> on any occurrence of murder, suicide or goat sacrifice you better not to install it. No blood - install it. Cheers.

Peter

No comments:

Post a Comment