Im looking for a way to hide a cck field for every one except for one specific role.
I know that there is a module, Content Permission module, that takes good care of this. But I have taken over a very big site with many content types, with lots of related cck fields being defined. So installing Content Permission module is not a good idea because of the great amount of settings it would require.
It's a drupal 6 installation.
You may use hook_nodeapi in a custom module:
/**
* Implements hook_nodeapi().
*/
function yourmodule_nodeapi(&$node, $op, $a3 = NULL, $a4 = NULL) {
switch ($op) {
case 'view':
if (! user_access('show restricted content')) {
unset ($node->content['field_restrictedcontent']);
}
break;
}
}
/**
* Implements hook_perm().
*/
function yourmodule_perm () {
return array(
'show restricted content',
);
}
Nevertheless, be aware that this is somewhat a hack: I think you should reconsider using Content Permission module for your site, and make the effort needed to configure it for your node types. It's a one time job and it may protect you from compatibilities issues with other modules in your site.
You need to use any of the permissions module and reconfigure each of those fields in question. With code, you have to check user roles for each of those fields!
Related
I created a custom module for Drupal 8 that allows the users to choose a Content type in order to add some fields programmatically.
How I can create some fields (text type in this case) and attach they to a Content type with a custom module?
Some help?
Thanks.
Checkout Field API for Drupal 8
It has several functions implemented and hook_entity_bundle_field_info might be what you need, here is an example of textfield from the docs of that hook
function hook_entity_bundle_field_info(\Drupal\Core\Entity\EntityTypeInterface $entity_type, $bundle, array $base_field_definitions) {
// Add a property only to nodes of the 'article' bundle.
if ($entity_type->id() == 'node' && $bundle == 'article') {
$fields = array();
$fields['mymodule_text_more'] = BaseFieldDefinition::create('string')
->setLabel(t('More text'))
->setComputed(TRUE)
->setClass('\Drupal\mymodule\EntityComputedMoreText');
return $fields;
}
}
You might also need Field Storage, checkout hook_entity_field_storage_info
You need to create FieldType, FieldWidget and FieldFormatter(If necessary), there are good examples in Core/Field/Plugin/Field.
There is a good example here https://www.drupal.org/node/2620964
You can use this module to create fields programmatically for any entity type and multiple bundles at once from custom YAML or JSON files:
https://drupal.org/project/field_create
The simplest approach for your module is to add your fields in the hook_field_create_definitions(). Simply create this function:
function mymodule_field_create_definitions_alter(&$definitions) {}
I have a module that creates (and updates) Drupal 7 nodes programmatically.
Since the content of the body these nodes is changed by a program at random intervals I do not want anyone, including the administrator, to be able to edit them. Is there a way way to completely "turn-off" the interface that allows a administrator to edit a node?
If it's a standard user with an administrator role you can implement hook_node_access() in your custom module:
function MYMODULE_node_access($node, $op, $account) {
$type = is_string($node) ? $node : $node->type;
if ($type == 'the_type' && $op == 'update') {
return NODE_ACCESS_DENY;
}
return NODE_ACCESS_IGNORE;
}
If it's the 'super user' (user 1) you need to get a bit more creative as a lot of access checks are bypassed for that user.
You can implement hook_menu_alter() to override the access callback for the node edit page, and provide your own instead:
function MYMODULE_menu_alter(&$items) {
$items['node/%node/edit']['access callback'] = 'MYMODULE_node_edit_form_access';
}
function MYMODULE_node_edit_form_access($node) {
$type = is_string($node) ? $node : $node->type;
if ($type == 'my_type') {
return FALSE;
}
return node_access('update', $node);
}
I like both of Clive's suggestions, but one more option is to simply disable the fields using HOOK_form_alter. This will work for the User 1 account too. I've used this recently to disable a specific field that I don't want anyone modifying.
function YOURMODULE_form_alter(&$form, &$form_state, $form_id) {
if ($form_id == 'your_form_id') {
$form['body_field']['body']['#disabled'] = TRUE;
$form['body_field']['body']['#value'] = $form['body_field']['body']['#default_value'];
}
}
Admittedly, this solution isn't ideal if you're using the built-in body field because of the teaser. But it works great if you want to disable editing of certain fields while leaving other aspects of the node editable and the page intact.
I'm not sure why you need them to be an administrator. That role, honestly, should be reserved for people with absolute control -- and even those people should not use it as their "main" account due to the potential for destroying things. Why not just make an "editor" role or something similar, and give all the permissions you need?
I'm using the Commerce and Rules modules, and I'd like to keep in touch with my clients after they buy things from my store.
I would like to add a follow_up_date Field to the Product entity, and use that to schedule Rules. I've set up the rules, I've used the Entity has field condition so that follow_up_date gets loaded and can be read from and edited, but it doesn't appear as a data selector for scheduling components.
I've tried using the Date and Integer Date modules, and with datestamps of various kinds and granularities, but no dice.
How can I schedule a Rule using data from a Field?
Depending on how the access the product, fx via an order, a Rules bug/flaw is probably what's stopping you, see the issue on d.o.
There is a work around to fix this by using hook_entity_property_info_alter. Something like this should do the trick for you:
/**
* Implements hook_entity_property_info_alter() on top of the Line Item module.
*/
function module_entity_property_info_alter(&$info) {
// Add custom discount fields to circumvent a rules bug.
$properties = array();
foreach ($info['commerce_product']['bundles'] as $bundle => $bundle_info) {
$bundle_info += array('properties' => array());
$properties += $bundle_info['properties'];
}
$info['commerce_product']['properties']['field_NAME'] = $properties['field_NAME'];
}
Anonymous user is able to post nodes. After posting node, user is redirected to registration. After registration, the previously submitted node should be linked with newly registered user.
I played with rules and entities but I was not able to get it work properly. Any ideas?
I would write a custom module (but that's me). The module needs to implement hook_node_insert and save the nid into SESSION. Then on hook_user_insert it can do the change. Untested code:
function foo_node_insert($node) {
$_SESSION['mynodes'][] = $node->nid;
}
function foo_user_insert($edit, $account) {
if (!empty($_SESSION['mynodes'])) {
foreach ($_SESSION['mynodes'] as $nid) {
$node = node_load($nid);
$node->uid = $account->uid;
// This saves the revision as the current user uid but that's just what we wanted.
node_save($node);
}
}
}
Edit: don't forget unset($_SESSION['mynodes']);
Save the node data until after registration and post it then.
There's the Anonymous Node Create module.
The module allows anonymous users to create nodes. But 'anonymous' is questionable in this module. This module alters the node form for anonymous users by adding two field groups at the end before the save button.
The first field group has fields that allow users to create a new account. This new account is then the author of the new node created.
I have Pathauto configured to generate an alias based on the title of a node, for a specific content type. The problem is that I want to make small changes in this title before Pathauto uses it to generate the alias.
The first comment in this post suggests the use of hook_token_values, but I couldn't really understand how to use it, even after reading the docs. In my tests, when I implement this hook, the alias generated is always "array", which means I'm missing something.
Any help? Thanks.
It might be that you missed to implement hook_token_list as well. Providing a new token is a two step process:
Implement hook_token_list to declare the tokens you are going to provide. This will just be the name of the tokens, along with a short explanation, and the information to what type of objects the tokens will apply (e.g. node, user, taxonomy, ...)
Implement hook_token_value to actually generate the content of the tokens. This will be called when the tokens are to be replaced with the content they should stand for.
As you just want to provide an alternative version of the title token already provided by the token module, it is probably best to just copy the relevant portions from token_node.inc, stripped down to the relevant cases and adjusted to be used in another module:
/**
* Implementation of hook_token_list().
*/
function yourModule_token_list($type = 'all') {
if ($type == 'node' || $type == 'all') {
$tokens['node']['yourModule-title'] = t('Node title (customized version by yourModule)');
return $tokens;
}
}
This simply says that yourModule provides a token for node objects, named yourModule-title, along with a short description. The main work gets done in the other hook:
/**
* Implementation of hook_token_values().
*/
function yourModule_token_values($type, $object = NULL, $options = array()) {
$values = array();
switch ($type) {
case 'node':
$node = $object;
// TODO: Replace the check_plain() call with your own token value creation logic!
$values['yourModule-title'] = check_plain($node->title);
break;
}
return $values;
}
This will be called whenever the tokens for node objects are needed, with the node in question being passed as the $object parameter (for a user token, the $type would be 'user', and $object would be the user object, and so on for other types). What it does is creating an array of values, keyed by the token name, with the replacement for that token as the value. The original code from token_node.inc just runs the title through check_plain(), so this would be the place to insert your own logic.
In Drupal 7, the token functionality has been moved to core. Tokens are implemented by the hook_tokens and hook_token_info methods. For usage examples, follow the links provided, and look for links to functions that implement hook_tokens and hook_token_info… I found the statistics_tokens and statistics_token_info functions helpful in understanding how this hook works.
It's probably also worth noting that this hook needs to be implemented by a module… my first attempt I dropped my test functions into the theme's template.php, only to have nothing happen at all :-p