Minimally maintained

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:

Summary

Makes the http://dejure.org/ service available as an input filter.

dejure.org allows you to send a text to their service which contains mentions of German law paragraps and court decisions. It will parse the text and replace recogniced paragraphs and decisions with a link to their law database.

The filter is basically using this page: http://rechtsnetz.dejure.org/dienste/vernetzung/vernetzen You can also use the form there for testing.

Example

§ 113 BGB


Urteil des LAG Schleswig-Holstein vom 18.07.2006

2 Sa 155/06

Pressemitteilung des LAG Schleswig-Holstein

will turn into

§ 113 BGB


Urteil des LAG Schleswig-Holstein vom 18.07.2006

2 Sa 155/06

Pressemitteilung des LAG Schleswig-Holstein

Real life examples and connectors for other systems beside Drupal you can find on http://dejure.org/vernetzung.html

Installation / Configuration

1. Install like any other Drupal module.

Summary

Field UI Plus adds a modest amount of data to the administration configuration
page provided by the Field UI module. This helps to see the important field
instance configuration settings at a glance, without having to walk through
numerous subpages.

Cautions

This is intended for use with the default Drupal 7 administrative theme, and
will no doubt look terrible if used in other administrative themes.

Rationale

The Field UI module provides an administrative user interface to the Field
module functionality that works well for the basics, but any earnest use of
fields will quickly run into its limitations. Suppose, for example, that you
are working on a project wherein the node entity portion of the data model is
described by a few dozen content types, a hundred or so different field
definitions, and more than two hundred field instances spread across those
content types. This is not unreasonable once you start thinking about the sort
of Drupal site that supports the Economist, for example, or other similar
business initiatives. Your data model will invariably evolve as the project
progresses, and a great deal of the administrative work flow is defined, or at
least channeled, by the settings in those few hundred field instances: which
widget to use, the messages displayed to the user, which fields are required,

Motivation