Extend and customize Drupal functionality with contributed modules.
If a module doesn't quite do what you want it to do, if you find a bug or have a suggestion, then join forces and help the module maintainer. Or, share your own by starting a new module.
At first sight, you may think it's just another fork of already available module on drupal.org like taxonomy_access or tac_lite. First one is a taxonomy control access based on roles, second one is a taxonomy control access based on users. But both of those modules miss the - according to me essential - inheritance notion :
if you have access to one term, you don't automatically have access to the children nodes. My module does take care about inheritance and this way permit a powerfull user access control.
This module allows to create 301 redirections for unused entity paths, by bundle and language.
For example, if you have some content type, and you don't want people to visit it's corresponding "node/%node" page (because that content type is not a page-like content type, it's just an object-like content type that must remain hidden).
Another useful case, is when you desire to redirect Taxonomy term page to an existing View page, with a given exposed filter selected ($_GET parameter).
This module allows to authenticate to Drupal using Google+ account.
It includes PHP client library for Google APIs (google-api-php-client).
This module is independent and does not require any other modules or libraries.
This module is sponsored by DrupalSquad
MoneySuite provides a set of modules for Drupal sites that rely on the sale of memberships and/or content for revenue. This project is differentiated from the existing commerce modules in that it requires no special adaptation for the sale of memberships and handles one time or recurring payments through a variety of payment gateways.
This module adds the functionality to have Panelizer Variants based off of List Defaults in Panelizer Full Page Override. What this does is allows you to have multiple layouts for one content type based off a field selection. The functionality doesn't seem to really exist yet. WELL, now it does!
Node translation access module allows to control access to nodes for selected languages
When using the entity translation module for node translation, all the available languages will inherit source language. In this case, node will be visible on all available languages no matter whether it has translation or not. Using entity translation module you can deny access to nodes of selected language. You can deny access to languages per node. Users will see standard access denied page.
The predelete module hooks into the deletion process of nodes. By default it is not possible to react on a deleteion attempt before the deletion of a node. This is cured by providing the hook_predelete_node(). Other modules may implement the hook and add custom checks on the node that is about to be deleted.
The module ships with an API documentation and an example module that provides a single checkbox field. Nodes that contain the field could only be deleted if the checkbox is checked.
TAC Redirect 403 extends the Taxonomy Access Control module by allowing you to specify a redirect URL for each taxonomy term. When a site visitor navigates to a content page that is restricted by a taxonomy access control rule, instead of Drupal's standard 403 (Access Denied) page being displayed, the visitor is redirected to the URL entered for the restricting term. This can be used to send people to custom "upsell" pages.
For example, if your site has the taxonomy terms Basic and Premium, and these are used to designate content as only available to members at the corresponding membership tier, this module lets you redirect visitors attempting to access restricted content to a signup form for purchasing the necessary membership level.
This module adds a permission which can be used to allow or disallow certain roles to delete the homepage node. This is useful when some roles such as content administrators need to be able to delete nodes, but you want to prevent them from deleting the homepage node.
Privacy Per User provides a simple framework to enable privacy settings per user, similar to the privacy settings on a site like Facebook. Those settings may be used to check access for display of entire pages, elements of a page (such as in a theme), or as an argument validator in a View. This allows individual users to control access to things such as their profile, specific elements of their profile, or lists of content they may have made, e.g. flagged nodes. It offers a flexible API to allow additional privacy states to be added (e.g. friends only) and an exportable set of privacy types.
This module allows you to restrict access to a comment by changing the theme of the comment if there is private.
Installation and configuration
Normally install the module in sites/all/modules, and enable it,
then go to admin/structure/types/manage/YOUR_CONTENT_TYPE/comment/fields and add a boolean field with the machine name field_private_comment.
Set it with
On value : Private comment
Off value : Public comment
Configure permission in admin/people/permissions#module-private_comment
This module introduces a new permission to restrict access to /taxonomy/term/TID and /taxonomy/term/TID/feed pages. The restriction is global for all vocabularies. If you need more fine grained control, have a look at Rabbit Hole.
The development of this module did not take a lot of time, but was nonetheless sponsored by Whisky Echo Bravo.
This module allows granular control of block visibility on a per-domain basis.
Use this module to set different visibility rules for each domain on your site, as setup by the domain access module. You can use this module in conjunction with the Domain Blocks module to restrict blocks from certain domains.
After installing your module, visit a block edit page and see the extra options added to "page visibility".