Maintenance fixes only

The flux service integration API provides a framework for flux integration with any remote service. While it has been created for the fluxkraft module suite, it is useful on its own as well.

The module eases integrating Drupal with remote services like twitter, facebook, your own web service or whatever. It exposes an admin UI for managing service connection settings and service accounts. By default it exposes no functionality for end-users, but it comes with an optional extension module that allows end-users to create personal service accounts.

Requirements

• Composer Manager
• Entity API
• UUID
• X Autoload
• Views

Integrated services

• flux Dropbox API
• flux Facebook API
• flux feeds Integration
• flux flickr API
• flux LinkedIn API
• flux XING API
• flux Twitter API

This module will be useful if you're using Yandex Mail for domains and your Drupal user accounts have corresponding mailboxes on Yandex, with sam

If you enable this module, the "From" address on contact emails, both site emails via the contact form and user-to-user emails via the member contact form, will be "From" the email address configured in site_mail (admin/config/system/site-information in d7). The reply-to header will be set to the address that Drupal would have used as the From address.

Note that Drupal 8 has this feature in core, so this module is not needed in D8.

This avoids many spam-classification issues. Many, many mail handlers will classify as spam a mail that comes from an unauthorized location, as this is spoofing. What Drupal does by default is spoofing...

Dreamhost actually *prevents* the sending of Drupal emails in many cases. This module should resolve that problem, but it's a problem elsewhere almost everywhere the Drupal contact form is used.

If you don't mind using a 3rd party service and have a nontrivial site, you'll probably enjoy the mandrill module and service. If you're on Dreamhost shared hosting, though, it probably means you have a trivial site to maintain and Mandrill would be overkill and additional complexity.

Taxonomy terms are typically displayed as Taxonomy Term Fields and each term also has a corresponding taxonomy/term/% page, where % is the term's tid. (If the term field is a link, you can click on it to get to the term's page.) There are other contribs that allow you to control access to the fields, but those modules leave the term pages open for everyone to see, even for anonymous users.

The Taxonomy Permissions module adds view terms in vocabulary permissions to the list of permissions of the Taxonomy core module and displays the resulting merged list on the Permissions page.

To avoid surprises, vocabularies are visible by authenticated and anonymous users by default. You have to change the permissions to see any effect of this module. Roles without the 'view' permission for a given vocabulary will not see Taxonomy Term Reference fields for that vocabulary, and they will not be able to access the taxonomy/term/% pages for the terms in that vocabulary.

This module allows you to create vocabularies that are not publicly visible but only for certain roles, for example:

• vocabularies to control a workflow
• vocabularies to control node access (with one of the taxonomy access modules)
• vocabularies to tag users, content, comments, etc. for administrative tracking

Module functionality was added to the Drupal 8 core.
Provides a Views-style formatter for boolean list fields.

Types of formats that can be used: