251 Modules match your search

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.

GCC Hierarchy

This project allows to define group permissions (of GCC groups) for group hierarchies.

Supported hierarchies:
1. Core taxonomy hierarchies
2. Hierarchies created by Node hierarchy module

The patch from #2296515: Permissions in group hierarchies is required for GCC.


Workbench Access Content Type

Extensible editorial access for the Workbench suite for granular access permissions by content types.

This module will add a new tab "Content Types" at the configuration page of Workbench Access, to provide permission by Section by Content Type.

This module was developed by Vardot for Georgetown University in Qatar.



Field Paywall

Field Paywall allows developers to replace fields on entities with a message depending on user permissions. It's useful for giving visitors teasers to content before advising them to sign up to see more.

Walkthrough video

A walkthrough video is available at http://youtu.be/a-Y8tiHuvaQ with a full demonstration of how to use field_paywall and how to override field_paywall templates.


Access Join

Have you ever encountered a scenario when you have content for which you are setting view permissions and you find you would love to require your users to have two of your existing roles to view it? By default Drupal will allow users with either of those two roles to view the content, and your only recourse is to find a module like Taxonomy Access Control to control your access from a separate location, or to create a 3rd role and require it to view the content (and then assign that 3rd role to untold numbers of users).

Access Join solves that problem! With either blocks or nodes (node usage requires the Content Access module) you can select a group of roles and with the flip of a radio selector change that content to require all the selected roles for access!

Access Join essentially allows the 'AND-ing' of roles together when setting which roles can view content. Drupal's default behavior is to use OR when looking up which roles have access to content. The module works for blocks and (with a very small core hack) nodes.


Entity Access API

This is a proof-of-concept module. Don't use it on a production site. This is an API module, and it does very little by itself. You probably shouldn't install it unless another module tells you to do so.

The original purpose of the module was to create a user-level access system for all entities. The high-level goal was to make it easy for a module to get an answer to the question "does User A have access to view the comment with ID 37?" The low-level goal was to create a system that allows simple granting/revoking of access to perform certain actions on entities, and this system should work with minimal changes across the rest of the Drupal site. For example, if User A does not have access to view node 42, then that node should not appear in Views listings for that user.

However, the reason this module was written was to make it easier to build a system for user-controlled privacy settings. That architecture has gone down a different route, and the code in this repository currently doesn't reflect that effort and won't be continued. I may still end up putting the user privacy effort at this namespace, but it will look very different than what is here now.


Reduced node edit


Reduced node edit lets users edit a node even if they don't have access to the body's input format: in that situation, the body field will be hidden, but the user will have their normal edit access to the rest of the node. A good description of the problem is in issue #91663:

Users lose (or don't have) edit access to nodes that they should be able to edit, given their roles and associated access control settings.

The node.module node_access() function denies 'update' access to a user, if a node has an input filter assigned that the user cannot access.

This can be a problem because a user can create a node, the administrator may alter input filter permissions so that the input filter used to create the node is no longer accessible to the user (or edit the node and assign a restricted input filter to the node) - and the original user can no longer edit a node (the edit tab disappears from the node menu, and if the user tries to access the edit function via /node/x/edit URL, the users receives an access denied message.)

This module will hide the body textarea in those cases where the user doesn't have access to the input format; they can still edit the title and other fields that they do have access to.



Domain ip

Domain_ip local tab

We recently saw a scenario where the client wanted to create an ip whitelist for their intranet site. This site is the same installation as the client’s public site. It simply has a different domain and different content. The question was ‘How we can manage separate whitelists and blacklists (ie ‘list sets’) for each domain, rather than one list set per installation.’

This module solves that issue. It is functionally a combination of two existing modules: ‘Ip_ranges’ ( http://drupal.org/project/ip_ranges ) and ‘domain_access’ (http://drupal.org/project/domain).
Domain_ip depends on Domain Access.

Domain_ip behaves similarly to ip_ranges, but it differs in the following ways:

  • Ip_ranges is used to define an ip whitelist and blacklist for a specific site. This is okay except for installations that also use the domain_access module, because they have different domains for a same installation. In this case, they are restricted to single list sets across domains. Whereas ip_ranges works against all domains for an installation, domain_ip provides a separate list set for each domain, respectively, meaning each domain has its own independent whitelist and blacklist.
  • To manage multiple sites, on the administration page there is a separate ip settings tab for each list set. Each domain has its own administration tab.


Services Content Lock


This module adds Services support to the community module called content_lock that will prevent two users from editing the same node concurrently. This module exposes the main operations of content_lock through Services as a resource, so that content locking can be done over a web service API such as REST for mobile applications or third party integrations. The main operations it currently implements are retrieve, create, and delete.


This module exposes the following operations of content_lock as a web service:

  • retrieve - Find out if a node is locked and get info about a lock e.g. who owns the lock and when it was created.
  • create - Create a new content lock on a node. Locks a node preventing other users from editing it.
  • delete - Deletes an existing lock on a node. Only the lock owner may delete the lock.


This module depends on the following modules:



    Phone Captcha

    With phonewithcomputer.com service, we use phone for CAPTCHA service.

    It provides a unique way to authenticate user.


    Phone CAPTCHA depends on the CAPTCHA module.
    A patch is required for CAPTCHA 7.x-1.0 https://drupal.org/node/918856#comment-7583533




    IP List


    The IP List module allows administrators to maintain and search list of IP addresses and IP address ranges, and associate each address or range with an arbitrary organization (string). The module doesn't do anything with this list, but the list can be integrated into other systems.

    This module was written to be integrated with a Varnish ACL (access control list) and thereby allow non-technical administrators to manage a list of IP addresses and ranges that can bypass a content paywall.


    Virtual Site

    Virtual Site allows a site admin to quickly instantiate a sub-site or standalone site within a single Drupal install. Virtual site instantiation includes, among other things, the ability to quickly populate a new site with placeholder content, menus, and selection of custom themes.

    This module is in early development, so it may be a few weeks before the first development release is posted. However, this project page has been created to begin fleshing out documentation and feature set.


    FileField Secure

    Allows for selected filefields to protect their files from download unless from users with appropriate role permissions. This allows a site to use Public file access method for the main site, but selectively secure a subset of files as required.

    The module works by creating a secure subfolder under files. Therefore there are a few requirements:

    * Ability to use .htaccess files to secure folders on your server (i.e. Apache webserver).
    * Filefield_paths to put selected files in the secure folder.


    Flexible template


    Allows you to create textfield and textarea elements in editable area, so that another editor will be able edit just this textfields and textareas and not will be able edit all the text.


    Translation Workflow

    Translation Workflow is a translation management and workflow for Drupal 7. Based on the new Content Translation which introduces entity/field translation for the new translatable fields capability in Drupal 7.




    The user will be restricted from premium content. The content will be unlocked with the presence of page specific cookies and/or a master (Profile complete) cookie.

    Users will unknowingly register and login with just an email account. All other required profile fields will be progressively required for access to premium content.

    This module will be dependent on premium content or content access? Still deciding...



    Audience provides an abstract definition of user groups and types in a given context. These definitions are called "Audience presets" and can be used by other modules to control different types of audience related actions or permissions. By using CTools these audience presets are exportables and can either get stored in a database or live in code provided by modules.

    Modules can use these presets to check if a user is member of a given audience. Therefore audience_is_member_of($preset, $account, $context) is used.
    Using audience_members($preset, $context) all users of a given audience in the given context can be retrieved.

    Audience presets are instances defined by an audience type. Default audience types shipped with Audience are "user", "roles", "author" and "userreference". There also "intersection" and "union" that merge multiple preset definitions to one preset (e.g. User is "author of node xy" and has "role admin").


    These modules are part of the project.

    • Audience - Definition of audience presets
    • Audience ACL - Caching of audiences by using ACL
    • Audience NodeAccess - Provides a CCK Field that uses ACL cached audiences to control access on the given node


    Conditional Roles for Workbench Moderation

    This module and its parent project, Conditional Roles, will be superseded by Access Control Kit. No further development will be done here on CRWM, other than to ensure a clean migration to ACK.

    Allows Conditional Roles to work with permissions provided by Workbench Moderation to control moderation actions and state transitions.


    OG Restricted Content

    This module provides a hopefully simple way to restrict access to organic group content to subgroups of users. You first define the levels of access you need (for example: top secret, secret, confidential) and, using Drupal permissions system, assign permissions to view content of different levels to the different user roles.

    You can also give content editors the possibility to restrict node access to different levels.

    This module is particularly useful in combination with OG User Roles.



    In some cases you want to publish a certain piece of content on a specific date. You can use the Scheduler project for this but this means the content will not be available until the specified date. This will result in people not being able to find content that will be published in the future.



    This module will allow you to have your Drupal site unhosted.

    Unhosted is an open web standard for decentralizing user data. On the unhosted web, data is stored per-user, wherever the user decides.

    Node Access Rebuild - Quick

    Sites with very high numbers of nodes often times have trouble rebuilding their node access permissions since the default drupal behavior is to load and save each node individually. This is an adequate solution when you have a few hundred nodes, but when sites have 500k or possibly millions of nodes, this can take hours to days to complete. Needless to say, that can really cut into your beer time.

    The goal of this module is to provide very quick, bulk inserts directly into the node_access table without iterating through nodes individually. the module supplies a hook "hook_quick_rebuild" and passes no data in. from there, modules that implement grants can use this to do a bulk insert for all the nodes that meet access criteria.

    This module ties in to the rebuild permissions form, and takes over that functionality, so the UI works exactly the same way as before. If node access granting modules exist that this module does not support, a notice gets added to the rebuild permissions screen, and the process reverts to the slow way of building permissions.

    Node body AJAX

    Loads the node body (and teaser!) via AJAX so that it isn't visible when the user does "view source." There is also an option you can turn on that will also attempting to disable copy & paste via Javascript - but it doesn't fully work in all browsers and versions.

    Remember: There is no way to completely stop someone who knows their stuff from copying your content!

    This module isn't useful in most cases, but can be helpful if you're trying to deter people from copying your content.


    Premium Fields

    Allows you to set certain CCK fields as premium. Premium fields will only be shown if the user has premium access (per the premium_content module) to the given node.