I recently came across an issue with this site.
I wanted a particular block created by the Views module to only show up on the Account page of the User logged in (Authenticated User). Since this block will be displaying information sensitive to the Author, it should obviously not be visible to other users. Also, since Drupal has a real issue with context sensitive information across the site in its OOTB (out of the box) configuration -- without having to load extra modules into memory, I had to hunt around for a solution that might solve a few issues.
Let me begin by demonstrating the problems I faced.
Problems
- URL Path Aliasing - so the arg() function won't do as it returns the itemized version of the URL path.
- <?php ?> - escaping the code is essential.
- Avoid adding extra .tpl files and template file coding.
Solutions
Path URL Aliasing
This is a tricky one. Since we are using clean URLs, it means using the arg() function will return values which would make are conditional statements somewhat complicated and untidy. Given the ease of testing for $user object variables and certain pathing values like "node" and "user", it would obviously be simpler to convert the Aliased path into its original source components.
Luck for us, Drupal has a nice tidy function that does that for us: drupal_get_normal_path($path). Also, since we need to split the path into its components, we'll use the PHP function explode to get the job done!
What this will return is an array with the path in key/value pairs we can easily draw a set of conditions on.
PHP Escaping
This issue has always been a case of "read the fine print". You'll note on a particular Block's configuration page, in the Page specific visibility settings a radio button that reads "Show if the following PHP code returns TRUE (PHP-mode, experts only).". The best part about form field descriptions is when you read them and not glossing over them as "experts" usually do. After all, we know what we're doing, so why should we have to consult them?
Had I of course noted the line that read "If the PHP-mode is chosen, enter PHP code between <?php ?>." I might have noticed the PHP escaping required. So, for you Drupalites out there, please do not forget these little babies, otherwise, your code will always return TRUE and you'll be running around in circles trying to figure out why it should rather not be showing that block on another User's account page.
No extra Code
The last thing I wanted to do, and I certainly could have done this, is duplicate the block.tpl.php file, rename it to match the block I created for the user account page (something like block-24.tpl.php) and add all the necessary coding to hide or show the information there. I was being lazy and wanted the code to reside on the site.
Though this is a possible route to take, I would point out the inherent issue with this technique: code maintenance. Since we've put code into the database of the site, it means, we now have to remember the code is here and in many cases, should someone other than myself require to modify the site, they would have to either figure this one out on their own or Read The Frakin' Manual. Of course, only if you put some together -- odds are, it won't exist. Hence, an external file might be a more sustainable solution in the end.
Wrapping Things Up!
The final step is to take the code I've written out below and paste it into our Blocks PHP text field.
<?php
// Get the current User object
global $user;
// Explode the Drupal URL Alias into its source components
$path = explode('/', drupal_get_normal_path($_REQUEST['q']));
// Test for each condition and set return value
if (($path[0] == "user") && ($path[1] == $user->uid)) {
return TRUE;
} else {
return FALSE;
}
?>
If all goes well, the Views created Block should now only show up on the Logged In User's page. Of course, this can be added to any Block, it need not be a Views Block at all.
Happy Drupaling!
