2

I have a block that I only want to display in nodes that the current user created. What's the best way of going about this?

Thoughts so far

I can access $user (and therefore the UID) anywhere, so I need to compare this to the node author UID. The only problem is finding a place where I can also pull in the current node information to find out it's author.

I really don't want to put php in a block (bad practice and all) and I couldn't see where I'd do this in context.

If I can't find a better way then the backup plan is to create an automatic field on node creation which contains the authors UID, then use this in page.tpl.php to set a class which will apply display:node to the block whenever the author UID =! user UID.

EDIT: Solution

The block I was trying to effect was in a custom module, so I took Yuriy's code and put into the modules hook_block_view. The result was this:

function mymodulename_block_view($delta = '') {
  $block = array();
  switch($delta) {
    case 'mymodulename_form':
            if (preg_match('#node/([0-9]+)#', $_GET['q'], $matches)) {
              if ($node = node_load($matches[1])) {
                global $user;
                if ($user->uid !== $node->uid) {
                  $block['content'] = array();
                } else {
                  $block['content'] = drupal_get_form('mymodulename_form');
                }
              }
            }
    break;
  }
  return $block;
}

I think this is what's going on:

preg_match and $_GET are used to take the node path from the current page. This returns: "node/xx". This is then used to load the correct node which is then matched against the global UID. An if function then either empties the block content or fills it.

  • Do you want to show the block for particular content type ? – Bala Sep 11 '13 at 7:21
  • Or the page created by the user ? or to show for specific role ? – Bala Sep 11 '13 at 7:33
0

I would implement hook_block_view_alter() and remove the block's content (resulting in hiding the block). Something like this (untested):

function hook_block_view_alter(&$data, $block) {
  if ($block->module == 'somemMdule' && $block->delta == 'someDelta' && preg_match('#node/([0-9]+)#', $_GET['q'], $matches)) {
    if ($node = node_load($matches[1])) {
      global $user;
      if ($user->uid !== $node->uid) {
        $data['content'] = array();
      }
    }
  }
}
  • Thanks very much, I ended up using a modified version of this in my module code as it was a custom block I was looking to display. – Dominic Woodman Sep 11 '13 at 19:17
0

I don't understand your reluctance to use php in a block, particularly in the block visibility settings.

If you set the block to display only on the pages where the following php code returns true, then the following, or something similar, should do the job for you.

<?php
global $user;
$node = menu_get_object();
return ( $user->uid == $node->uid );
?>
  • 1
    Having the PHP filter module enabled is a huge security risk, and maintenance nightmare. It's certainly an option, but it sounds like it's not one the OP is comfortable with. – Yuriy Babenko Sep 10 '13 at 23:03
  • 1
    @YuriyBabenko If no permissions are given, then only user 1 can use php code for settings. It is only a security risk if the permissions are given to untrusted developers. Use of php is certainly never allowed for site users. Maintenance nightmares are a symptom of poor documentation. Every thing we do should be documented so our successors can work with the site, and so we can remember what we have done. – Triskelion Sep 10 '13 at 23:36
  • 1
    Triskelion, have a look at this: drupal.stackexchange.com/questions/2509/… – Yuriy Babenko Sep 11 '13 at 0:29
  • @YuriyBabenko A much more current and scholarly discussion is the argument about the inclusion of the PHP module in D8 core, best summarized by the comment by David Rothstein. I also agree with the comments by Webchick (same thread). Security is a question of coding practice. The power of Drupal is in its flexibility. To answer the question "Is the current user the node author?" using php does not in itself impose a security risk. The most "coding resources" efficient way to accomplish this is with an eval()'d php snippet. – Triskelion Sep 11 '13 at 16:21
  • I agree that the PHP filter can be used relatively safely, and that it is the simplest way of achieving the desired functionality, but I don't agree that it's a good approach. Drupal's flexibility can quickly lead to a project's downfall, and including PHP code in the database is one of the stepping stones to that conclusion. – Yuriy Babenko Sep 11 '13 at 17:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.