Actively maintained

Fluent Mail provides an alternative to drupal_mail() with fewer convolutions and a more pleasant developer experience via a fluent interface. If you are not a developer or another module does not require it, you will derive no benefit from this module. It makes no changes on its own. To make use of the module call fluent_mail() in your code instead of drupal_mail() when you wish to send mail. How is this an improvement? Let's look at an example of sending a simple test message with drupal_mail():

<?php

/**
 * Implements hook_mail().
 */
function mymodule_mail($key, &$message, $params) {
  $message['subject'] = t('Test message');
  $message['body'][] = t('This is a test message.');
}

/**
 * Send a test email.
 */
function mymodule_send_test_mail() {
  drupal_mail('mymodule', 'test_message', 'me@example.com', language_default(), array(), 'admin@example.com', TRUE);
}

?>

And the same example using fluent_mail():

<?php

/**
 * Send a test email.
 */
function mymodule_send_test_mail() {
  fluent_mail('mymodule', 'test_message')
    ->setTo('me@example.com')
    ->setFrom('admin@example.com')
    ->setSubject(t('Test message'))
    ->setBody(t('This is a test message.'))
    ->send();
}

?>

This module adds a new type of widget to be used on facets.
It is displayed as a small form with only one input of type textfield and a submit button.

Webform Submission Reference creates a webform component that points at submissions from a target webform.

Address Field Nigeria

This module is a plugin for Addressfield module. It provides a user friendly Nigerian address form.

This is a very simple filter module to calculate the size of uploaded any type of file in your site.

An extension module to 2.x version of Search API Entity Translation module.

Changes the way in which Solr Search module stores the multilingual content, making it use solr dynamic fields for translatable entity fields.

For example, when indexing "body:value" field, solr would normally store its value in tm_body:value property. With this hook (assuming that body field is translatable and comes from translatable entity, and that currently being processed content language is fr) it will be stored in tm_fr_body:value instead, with nothing saved to default tm_body:value property.

This allows to use different datatypes for different language-based solr fields, thus allowing to configure different tokenizers/stemmers/spell checkers/stop words/protected words/etc for each language separately.

Obviously it also works when retrieving data from solr, looking for language-based dynamic fields, and, if they exist - assigning their values back to relevant Search API properties (not language-based anymore).