I recently set up a contact form on a WordPress site – and it reminded me what a rigid process extending WordPress (WP) is.
Contact forms running reCAPTCHA protection seem to fair pretty well at cutting spam, so I found a plugin by a nice chap called Deko Boko – Nice plugin and it seems to work fine, it’s just a shame the poor guy had to build the entire admin interface, posting catching and emailing mechanisms and finally tie in the reCAPTCHA support from scratch.
Looking to do the same thing on a Drupal site I manage the experience and process was quite different. Drupal Modules (think WP Plugins, but smarter) snap together like legos to form workflows that fit your needs. You can do things through the Drupal interface that would require PHP coding in WP.
First I enabled the Contact module, included in the base Drupal install. Then I downloaded a Contact Form Module which did not include the support of the specific reCAPTCHA scheme I desired, but had every other feature I was looking for.
Next I downloaded a Drupal specific reCAPTCHA module, and the base PHP library from the reCAPTCHA folks and deposited those files in their appropriate folders in my Drupal install.
WordPress does provide ways for developers to modify output and have certain actions triggered by WP functions, Drupal takes this much farther by setting up an environment that allows for Drupal Modules to modify the behavior of each other. This can shift the balance of power to the sys admins, advanced users who don’t quite know what they are doing with PHP and away from PHP savvy web developers.
Once I had the reCAPTCHA plugin set up and working – I used it’s interface from my Drupal admin area to select the form generated by the contact form module and shizzam – I put my peanut butter in your chocolate! The guy who wrote the contact form module did not need to add specific reCAPTCHA support to his module, and the reCAPTCHA module guy did not do anything special to allow the modification of the previous plugin to use reCAPTCHA. Neat huh?