260 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.

Iron Curtain

Developed by Reload, sponsored by Scribo.

This module allows the site admins to restrict access to certain paths or the entire site, based on the visitor's IP address.

It allows users with a certain role to bypass the system, it allows a list of paths to bypass the system and it allows you to make a list of paths which can only be seen by whitelisted IPs, and another list which can not be accessed by blacklisted IPs.


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.



OSF for Drupal

OSF for Drupal

The Open Semantic Framework (OSF) for Drupal is a middleware layer that allows structured data (RDF) and associated vocabularies (ontologies) to "drive" tailored tools and data displays within Drupal. The basic OSF for Drupal modules provide two types of capabilities. First, there are a series of connector modules such as OSF Entities, OSF SearchAPI, OSF Field Storage and OSF Views to integrate an OSF instance into Drupal's core APIs. Second, there is a series of module tools used to administer all of these capabilities.

By using OSF for Drupal, you may create, read, update and delete any kind of content in a OSF instance. You may also search, browse, import and export structured datasets from an OSF instance.

OSF for Drupal connects to the underlying structured (RDF) data via the separately available OSF Web services. OSF Web Services is a mostly RESTful Web services layer that also allows multiple Drupal installations to share and collaborate structured data with one another via user access rights and privileges to registered datasets. Collaboration networks may be established directly to distributed OSF Web Services servers, also allowing non-Drupal installations to participate in the network.


Form Element Access (FEA)

Per role access configuration for all form elements in a configured form. Use this to quickly filter forms for unneeded/unwanted form elements.


  • User interface to administer affected forms
  • User interface to administer per role access of the form elements
  • Automatically index all fields in a configured form upon display
  • Permission to bypass the access rules
  • Grant, or revoke permissions per form


Webform Per Email

Attaching to a webform


This module implements a permit based access system to allow anonymous users submit a Webform only if they display a valid one-time access permit.


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




    Workflow required

    This simple module allows nodes with required elements to be left empty when the node is in selected workflow states.

    This is Useful for 'draft', 'unpublished' or 'staging' kind of workflow states where the node isn't yet finished. It's especially useful when using nodes as complex formal applications over several pages where users typically spend lot of time to fill out and work with them.

    The FAPI '#required' attribute will recursively be unset after the form is build, but enabled again just before rendering, giving the user the same visual experience as before.


    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.