Earlier this week, we released the first stable version of the Mollom module for Drupal 7. The release denotes a major milestone for the engineering team at Mollom, because we started to track the development of Drupal 7 very early and kept the module always compatible to latest code in Drupal core.

Simpler, smaller, better

The most significant difference to the Drupal 6 module is that we were able to entirely remove plenty of code that was previously required to work around limitations and bugs in Drupal's Form API. While actively tracking changes in Drupal core, we could not stand our own ugly workarounds anymore.
It was time to fix Drupal core, so we could finally clean up the module's integration with forms:

  • We made it possible for form validation handlers to alter the form structure during form validation. Not being able to change a form during validation was the most annoying problem for the Mollom module, because it only conditionally shows a CAPTCHA — only when a post is suspicious and looks like spam to Mollom, the user is asked to solve a CAPTCHA. But initially, there is no CAPTCHA contained in the form, so the CAPTCHA needs to be dynamically added when required. Starting from Drupal 7, the form validation basically can be understood as an additional step to alter or process the form structure, if required. This allows us to conditionally generate a CAPTCHA and only show a CAPTCHA if a post might be spam, while still having access to the full form structure and form state.
  • We corrected and improved the caching of $form_state in the case of form validation errors, previews, multi-step ("wizard") forms, and other scenarios in which a form is rebuilt or re-rendered, and might have new or updated state information that should be cached. This allowed us to leverage Form API's native form caching as a true "state machine" and storage for the spam check results returned by the Mollom web service. Since the cached form state holds all information from previous form submission attempts now, the Mollom module is able to re-use that information and conditionally perform actions in subsequent form submission attempts (such as showing a CAPTCHA). Among other issues, we also helped to remove the auto-rebuilding magic of the 'storage' property, to cache most of $form_state when form caching is enabled, and ensured that form constructors can already decide on caching and rebuilding.

Along the way, we wrote more than 2,200 test assertions for the Mollom module's automated unit tests, to ensure that its functionality works correctly in almost every possible scenario. Effectively, Mollom's module tests are quite possibly the most aggressive Form API tests for Drupal, as it uses almost all of its advanced features.

Open, flexible, consistent

One of the goals for the Mollom module is to allow an easy and yet flexible integration with third-party Drupal modules. However, most contributed modules are following the example of Drupal core: Drupal 6 itself contained highly inconsistent forms. In order to protect more forms against spam in Drupal 7, we figured that we had to clean up and improve various forms in Drupal core to set the right example for contributed modules:

  • We introduced the pattern of consistently providing the ID of a new entity in form submission handlers, in the same location the ID would appear for an existing entity. Subsequently invoked form submission handlers are able to access the entity ID, regardless of whether the entity was just created or updated. This allows modules to read the ID of a post in an always consistent way and store the spam check results for the post in an own table. Likewise, every confirmation form that allows to delete an entity should also provide value of the entity ID in the same location as in the edit form.
  • We cleaned up and revamped the comment form to generate and return an always consistent and predictable form structure. Like many other Drupal 6 modules, the Mollom module also had to struggle with the old form structure, since it was always different, depending on various configuration and environment settings. In fact, the Drupal 7 version of comment_form() is a nice example for how to use the #access property correctly — which in turn allows third-party modules to re-use a form more efficiently or perhaps even make one of the hidden fields visible.

Mollom additionally integrates with the new account cancellation process in Drupal 7. This allows you to report a user account as spam to Mollom, and the account as well as all of the posts associated to it get reported as spam and deleted in one fell swoop.

Usable, in production, and translatable!

We invested a lot of time to improve the user experience of the Mollom module's user interface, so you can perform your daily spam moderation tasks faster and more easily. This is underlined by the fact that the module is actively used in production by thousands of Drupal Gardens users already, of which most have no technical expertise with Drupal.

Lastly, we now have centralized user interface translations on drupal.org. Much easier! Start right away and translate the Mollom module into your language!

Cross-posted in the Mollom blog.


Awesome! Now I can finally upgrade to Drupal 7!

Trevor, glad to know that we were able to unblock you from upgrading to Drupal 7!

This is not comment spam, this is interaction.

This post seems to be attractive for comment spam posters for any reason. Let's see how much more viagra pills, penis enlargement, thesis writing, tramadol, FedEx, Blackberry Free Ringtones, Lowest Price Viagra, Rihanna pictures, Free sex pictures, SMS ringtone, Online viagra prices, Drug dealer, SEO online marketing, Sexy latinas, Free movies, Free iTunes ringtones, Viagra Cialis, Amateur sex video, Free celebrity pictures, Free software, Sexy nudes, Soma pills, Motorola ringtone codes, and whatnot we can attract to this! :)

Beat me, baby!

Are you using Drupal 7 for this blog?