Mollom module for Drupal 7 released

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 removed 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 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 knew 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 a consistent and predictable form structure.  Like many other Drupal 6 modules, the Mollom module 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, most of which 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!

Thanks for using Mollom!

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.