Drupal 7: Redirect Users From Unpublished Content

9th August 2016 - 4 minutes read time

I was recently asked to implement a feature on a Drupal site where all nodes of a certain type would redirect to a main listing page if that node had been unpublished. The problem in doing this is that if a post is unpublished then Drupal will issue an access denied response quite early on in the boot process. When the menu item is loaded it goes through an access callback which sees that the post is unpublished and issues an access denied before anything else can happen. So in this situation you can't use things like Rules to redirect users as the rule is never triggered.

The solution was to use hook_menu_alter() to change the access callback parameter of the node page. We are essentially replacing the normal access callback of node_access() with our own version.

  1. /**
  2.  * Implements hook_menu_alter().
  3.  */
  4. function mymodule_menu_alter(&$items) {
  5. $items['node/%node']['access callback'] = 'mymodule_access_callback';
  6. }

Here is our own implementation of the new node access callback. What we are interested in is any nodes of the type 'article' that are unpublished and if the user is anonymous. If this is detected then the request is redirected. If it isn't detected then we simply return the normal result of node_access(). There is no need to change the way in which the node permissions work for this so we keep it as it is.

  1. function mymodule_access_callback($op, $node, $account = NULL) {
  2. if ($node->type == 'article' && $node->status == 0 && ! user_is_logged_in()) {
  3. drupal_goto('/articles_list_page');
  4. }
  5. return node_access($op, $node, $account);
  6. }

This is only half of the story. We also need to take into account what happens if the page is access via Javscript, or if the page is encountered during a cron run. With the above code, if either of these conditions happen then cron will break and you will receive strange JavaScript errors on autocomplete fields. The following adds some more checks to prevent this.

  1. function mymodule_access_callback($op, $node, $account = NULL) {
  2. // If this is an unpublished article_page.
  3. if ($node->type == 'article' && $node->status == 0 && ! user_is_logged_in()) {
  4. // Make sure cron isn't running.
  5. if (variable_get('cron_semaphore', FALSE) === FALSE && $_SERVER['SCRIPT_NAME'] !== '/cron.php' && arg(3) !== 'run-cron') {
  6. // Not a JavaScript callback.
  7. if (arg(0) != 'js') {
  8. return drupal_goto('/articles_list_page');
  9. }
  10. }
  11. }
  12. return node_access($op, $node, $account);
  13. }

The above solution to this shows how important knowing the internal boot processes in Drupal and what hook to use in what situation is. We could have used something like hook_init() to do the same thing here, but we would need to load the node before hand and because it would be triggered on every page request the check would be more complex so that we didn't generate any false redirects. By overriding the node access callback in this way we ensure that we are only ever dealing with the correct nodes.


Thanks for this useful tip. Just one quick question, as I only have limited experience in using callbacks. Do you mean that mymodule (in 'mymodule_access_callback', line 5 in the first snippet) is to be replaced by the name of my module?. And the same thing with myown (in 'myown_access_callback')? Otherwise I would have thought that both of them should have the same arbitrary name and that my module name only should be used in the hook?

Tommy (Tue, 01/10/2017 - 09:18)

You are right, that was a mistake on my part. I've corrected the names of the functions now. Thanks for pointing that out! :)

Add new comment

The content of this field is kept private and will not be shown publicly.