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.
Le Gate is a simple module that restricts user access to pages on a site, and then provides two mechanisms
by which users can then gain access. It was first developed as an "age gate" module to allow access to a site
only when an appropriate age is selected (>15yo for COPPA). But then we decided to make it more generic.
When a user tries to access a restricted page they are redirected to a configurable and themable page
The goal of this project is to provide a method for users to easily configure access settings to their own entities. The interface for configuring access will come from a shared access field attached to the entity.
Implement field hooks to define the new shared_access field type.
Define formatters and formatter settings.
Implement an extendible access controller class structure for defining access realms and their underlying functionality.
Define several default access realms (user, organic groups ... perhaps a few more).
Implement field hooks so that a form shows up on the entity content page.
Implement a standard sharing settings form that can hook into the access controller classes and be used to control access to the entity.
Provide autocomplete functions and hooks for displaying user name/og suggestions as the user types
Implement access hooks and query/query_HOOK alter functions to control access
Implement field access hooks so that the form only shows when the owner or configured admins view the page.
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".
This module will count the number of times an authenticated user visits a page matching a path pattern. If the views per hour reach the established limit the user will be redirected to either an established page or a will be sent to the standard 403 page.
Permissions exist to allow roles to ignore the limits so administrators can browse without limitation.
The use case I initially built this for is to deter users from manually scraping through other user's profiles to build mailing lists.
Shield Pages modules allows the administrator to secure any page in your website by password. You just need to go to configuration page of this module and add path, password. After that the added path will be password protected.
This module allow administrator to set global password for all shielded pages.This module allow administer to set multiple passwords for shielded page per path. This module provide bypass password protection of shielded pages permission also. All the shielded pages will be accessible by users having this permission.
When you update the privacy settings of an Organic Group, you may need to rebuild the node access settings of the nodes assigned as posts to that group. Unfortunately the node access rebuild system focuses on rebuilding all nodes, instead of just those affected.
This module has forked the node rebuild system to allow developers to target one or more Organic Group's for node rebuild. It has the following features:
Automatically detect when group privacy changes as the result of the node edit form and directs users automatically to the batch edit screen.
Integration with Spaces allowing group administrators to rebuild node access for their group at need.
Developer API in the form of a og_node_access_needs_rebuild() function to add new groups for rebuild.
Plays nicely with general node access rebuild flag, allowing general node access to trump og-specific rebuild.
This module is set for maintenance and bug fixes only and is unlikely to get much in the way of new features. Good, minimal feature patches are welcome. As we currently have no use for a D7 version of this module, we are open to requests to create and co-maintain a D7 branch.
Small module that allows you to use regex to validate fields on the registration form.
While there are alternative modules to validate fields on the registration form, I found that none of them allowed for regex checks on the name and email fields on registration. They also seemed to be overly complicated or only allowed for checking on the username or email address.
This module is quite simple and allows you to check any textfield on the registration form.
Add-on for the Node Gallery module that creates and maintains default gallery for every user.
The main goal of the module is to make image sorting easy, optional task, and to streamline the uploading process.
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.’
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.
This module grants per-session permissions for users to access nodes they created.
Yet another simple node access module, this time catering to users whose nodes have to be published for them to have access.
It grants temporary (session based) node access permissions to users with set
roles after they create that node.
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.
This module adds support for mixed use of SSL and non-SSL (http and https protocols) for the 6.x branch of Domain Access.
Currently, Domain Access allows you to specify per domain whether to use http or https, and if a domain source is configured, URLs throughout that site (including form actions and so forth) use that protocol. However, if your site mixes use of both protocols (say, with SSL to protect the user login page, admin pages, or authenticated sessions in general), Domain Access does not support that configuration.
Allows overriding page nodes on a domain-specific basis.
Provides an "Override" tab on node pages that removes the current domain from the node's domain access, clones the node, and publishes the clone to only the current domain.
Copies translations of the node being overridden (if any), too, so they're considered translations of the newly created node.
Sidesteps need to use multiple url_alias tables (with Domain Prefix). Makes Drupal interpret the URL alias for a node that's been overridden as a path to this domain's version of the node. Example: node 1 (the node at node/1) is published to all domains with the URL alias contact-us. You visit the node from the subdomain "cats" and select the "Override" tab. Now a new node has been created (node 2), that's published only to the "cats" subdomain, and node 1 is no longer published to the "cats" subdomain. When you visit http://site/contact-us you'll see the content of node 1. However, when you visit http://cats.site/contact-us, you'll see the content of node 2 -- node 1's override.
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.
With Brain Forum Moderation you can add "Moderation" field to your Brain Forum posts.
It creates an ajax link that opens a popup with variety of moderation options when clicked.
Development has just started so it will take some time before even the basic features are ready for production.
You can help by opening feature requests so i can figure out which features are actually needed.
These are some planned features:
GeoIP Role allows to dynamically grant roles to the current user according to his IP address location.
It depends on the GeoIP API module.
Currently, GeoIP Role allows to attach countries to roles, thus defining geographical zones.
When a user visits your site, he dynamically gain the role(s) attached to the country reported by his IP address.
GeoIP Role may be used with any other module like Nodeaccess that controls access based on user roles.
File access by node type allows website administrators to select which roles can access files belonging to nodes of a certain node type. This goes beyond simple field permission, since there can be situations where users might embed an uploaded file into a Body textarea, or a WYSIWYG editor.
This module allows the restriction to work even in those cases by intercepting the file download before it happens. It also respects other access control mechanisms, since it defaults to either restricting access, or delegating it further. If the file download is not denied, and no other module is there to make a second decision, then it will download it. This allows for future integration with other modules and should be consistent in how Drupal handles access control.