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.
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.
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.
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.
This project has been sponsored by:
Is an independent professional consulting group with extensive background in telecommunications, IT, software development and implementation. Visit http://jmproduct.ru/en for more information.
Largest air carrier in Russia. Visit http://aeroflot.ru for more information.
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.
- Entity/Field based translation based on Content Translation and Title. The advantage of this approach is more control over fields (e.g. Name field is translatable, where URL field is not), and it's support for different modules (node, comment, taxonomy, user).
- Assign translation tasks, give translators access to specific languages
- Dashboard for translation admin to track translation tasks, and for translators to track their tasks.
- Notifications support to notify translator when a new task is assigned to him, and to notify translation admin when a new translation is published.
The work on this project is ongoing, and a dev version will be available soon.
This project is sponsored by Meedan. Meedan is a leader in English <-> Arabic translation, news, dialogues and social media.
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...
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 allows you to publish your content under embargo. This will result in a page being available in the navigation and in search results but it's content will be replaced by a specified text. To do this the embargo module uses hook_nodeapi to override the "view" operation.
The current version allows you to:
- Specify which node types can be put under embargo
- Specify an end date for the embargo
- Enable the embargo per node
- Add embargo replacement text per node
Feature requests at this time are:
- Specifying a default text for all content types
- Specifying a default text per content type
- Alert me functionality when content is released from embargo
Development of this module is sponsored by Sogeti Netherlands.
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.
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.
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.
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.
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
URL token is an API module to make token-based access control simple.
There are two main features:
- Request a token
- Check that a token is valid (usually via a URL)
You should only install this module if another module requires it. This module doesn't provide any functionality by itself, it provides features for other developers to use in their modules.
Field Access API provide an wrapper to let other modules easily implement any access criteria for fields, both for view and edit mode.
It let developers define any custom rule for granting or not access to a specific field.
It is an API module, so doesn't provide any end-user feature on its own, and is intended for developers. Install it only if another module requires it or you want to make your own implementation.
If what you are looking for is an out-of-the-box way to limit field access based on user role, you should use Field Permissions instead.
The access rules are set on the field's UI, and can be applied either to the field instance, or set to be overridable for each entity where the field appears on.
Modules can declare 4 types of implementations, using hook_fieldaccess_info :
"edit" and "view" ones, to deal with granting or not access to the field, for the respective operation.
"edit override" and "view override" ones, to be able to change the field rendering instead of just omitting it, in case the user has been refused access (eg, showing the value of a field while keeping it not editable on an entity edit form instead of not displaying it at all).
See README for implementations examples and usage.
This module is no longer active. The Masquerade module does what this module does, only better, so go and download that instead.
The difference with Masquerade and my module is that mine displays the "switch" link along side the "edit" link for users, where as Masquerade has the option to masquerade as a user in the operations dropdown. Masquerade also logs the user-switching as well as giving you a switch-back link, so it is truly superior.
The initial download for this module will still be available if you feel like using it.
This little module gives you the ability to switch to any user via the admin panel found at admin/people in Drupal 7. It adds an extra link in the operations-section called 'switch'. Click it and you'll be logged in as that user.
You can also switch to a user by using a URL, switch-user/%uid. If you have the correct privileges the system will log you in as the given user.
This module extends the content access module to put the view (any/own) [TYPE] to the drupal permissions form. So a user settings the access permissions doesn't have to switch between two forms and he doesn't need access to change content type settings.
The module is part of the ERPAL Distribution
This project is developed by Bright Solutions. We also offer paid Drupal and ERPAL integration and process consulting
This module restores the Priority feature of Node Access that was removed in Drupal 8.
Node Access Priority does not have a user interface itself, but if you use multiple Node Access modules, then those that support Priority will let you increase or decrease their priority relative to the others.
Allows administrators to override the visibility of menu items. Normally, items which are inaccessible won't show up in the menu. Using this module, menu items can be set to always show up. Their contents will still be restricted.
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.
Provides markup to indicate user roles and roles that can access restricted content.
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 can works with og-7.x-2.x. Permission of this module will be override by og : a private comment will be accessible only to group members.
NOTE: This module is in no way affiliated, endorsed, nor provided by ClickBank.com.
What is this module?
This module validates purchases on payment processor ClickBank, and provides a "secure" file download link. This module IS appropriate in the following situations:
- You already use ClickBank as your payment processor
- You don't want to pay for services to protect your digital goods at the point of sale
- The information you're selling does not need to be 100% secure
- your digital goods should not be available to search engines, or users typing in the url directly.
This module does NOT do the following:
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. Define widgets. 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.
Generally, this project enables content authors to see from any current content (entity) its dependent entities content.
Project overcome a major content control difficulty for content authors.
Provide content authors ability to track external content which refers to current content, without the need to check mass of external content to find out whether each external content refers to current content or not.
Content dependency main advantages:
- Easily manage content dependencies - you can view/update for each content entity it's dependent entities from one places.
- Backward Compatibility - You can install this module & start use it without need to perform any change in your content structure.