robotstxt access permissions
andyceo - June 26, 2009 - 09:08
| Project: | RobotsTxt |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Description
First of all, thanks for that great module.
My issue is about access permissions to administer robobts.txt content. on several projects, we have a SEO-specialist, who promote our sites in search engines, and we want to grant him "edit robots.txt". At the moment, we can do this only by provide him full 'administer site configuration' rights.
So, we offer:
let's implement hook_access() :
<?php
function robotstxt_perm() {
return array('edit robots.txt');
}
?>and patch hook_menu() (file robotstxt.module, line 36) :
before:
<?php
'access arguments' => array('administer site configuration'),
?>after
<?php
'access arguments' => array('administer site configuration', 'edit robots.txt'),
?>And here we are! :)
#1
Well, a few changes we need to code to all works properly.
At first, we create a custom access function:
<?php/**
* Check the multiple access permissions through 'OR' operator
*/
function _robotstxt_access() {
$is_ok = FALSE;
$perms = func_get_args();
foreach($perms as $perm)
if(user_access($perm)) {
$is_ok = TRUE;
break;
}
return $is_ok;
}
?>
after, we need to set access callback to this our custom access function. Here is a full listing of robotstxt_menu() hook:
<?php
/**
* Implementation of hook_menu().
*/
function robotstxt_menu() {
$items['robots.txt'] = array(
'page callback' => 'robotstxt_robots',
'access callback' => TRUE,
'type' => MENU_CALLBACK,
);
$items['admin/settings/robotstxt'] = array(
'title' => 'RobotsTxt',
'description' => 'Manage your robots.txt file.',
'page callback' => 'drupal_get_form',
'page arguments' => array('robotstxt_admin_settings'),
'access callback' => '_robotstxt_access',
'access arguments' => array('administer site configuration', 'edit robots.txt'),
'file' => 'robotstxt.admin.inc',
);
return $items;
}
?>
There is a patch of all changes I attached below.
#2
I cannot see the need for _robotstxt_access()
#3
_robotstxt_access() is needed because the default access function - user_access() - get only 1 string (a permission string) - http://api.drupal.org/api/function/user_access/6 . if we will not use _robotstxt_access(), and will use user_access() instead, we get an error, cause we can't pass 2 permission strings in user_access() at one moment.
We offer to use _robotstxt_access(), because we want the backward compatibility - users who already have the 'administer site configuration' permission, can to edit robots.txt, and the new users with 'edit robots.txt', too.
We can refuse using _robotstxt_access() and leave only one permission string 'edit robots.txt', but in that case we havn't backward compatibility.
#4
+1 for this change.
#5
We can avoid the extra function by automatically assigning the 'edit robots.txt' permission to anyone with the 'administer site configuration' permission.
#6
How should we assigning the permission?
#7
Like this. Used 'administer robots.txt' instead of 'edit robots.txt' incase the module adds more feature (not likely, but this is more understandable with current permission terminology).
#8
I thought you'd like to implement a trigger that assigns the permission every time a new role get's the administer site configuration... the above patch is the way I thought to do this first. I'm only not a fan of 1000 or more permission checkboxes on the permission settings page... this is why I'm not sure if adding another one is a good idea as I do not really see why everyone should edit a file that is mostly configured once per site "live time" or per major version. Why are we going to make such a small and neat module complex? :-(
Someone with the permission to alter robots.txt can harm your sites SERPs - in words - one wrong wildcard and your site is DEAD. I believe this is something for administrators only... I understand that SEOs think they need to change it periodically. Why ever - we changed our files max once per 2 years in the last 10 years and if I wouldn't have done a review it would be wrong now... if you do not have full permissions to a site there must be a good reason. But I'm not very strong about this... we can get this in if it's really important.