TinyMCE has a few built-in methods that allow you to turn the editor on and off; essentially this is all you have to do to switch between the two modes. It is not, however, a second interface. The WordPress editor actually has two rich-editors: one for Visual, and one for HTML. Instead of turning  off TinyMCE, WordPress merely switches the rich-editors. That’s why you see those nice formatting buttons even through, you’re in HTML mode. Accomplishing that type of functionality is difficult. You can see the complexity of the custom switchEditors method in editor.dev.js.

Too much to cover. For now, I will simply show you how to turn the rich-editor on and off. First, set up a basic TinyMCE editor. This code builds of my other post. There you can find a more complete description of what’s going on. In short, though, wp_tiny_mce() does all the initialization for you, and queues it on the page. This example could exist on a plugin options page, the profile editor, a post metabox, or really anywhere you want users to rich-edit.

<?php
wp_tiny_mce( false , // true makes the editor "teeny"
	array(
		"editor_selector" => "foo",
                "height" => 150
	)
);
?>

<textarea class="foo" id="foo" name="foo"></textarea>

Although you must setup the editor for your plugin using wp_tiny_mce(), the regular TinyMCE methods are all available to call from some custom JavaScript. The ones you want to be concerned with are mceAddControl and mceRemoveControl. If you spent any time digging through editor.dev.js, you would notice that the complex WordPress switcher still uses these methods.

Above the textarea, stick some links that will act as our switchboard:

<p align="right">
	<a class="button toggleVisual">Visual</a>
	<a class="button toggleHTML">HTML</a>
</p>
<textarea class="foo" id="foo" name="foo"></textarea>

Now, write some simple jQuery that adds the switching functionality. You could enqueue this as a separate file, or place it with the textarea.

jQuery(document).ready(function($) {

	var id = 'foo';

	$('a.toggleVisual').click(
		function() {
			tinyMCE.execCommand('mceAddControl', false, id);
		}
	);

	$('a.toggleHTML').click(
		function() {
			tinyMCE.execCommand('mceRemoveControl', false, id);
		}
	);

});

The buttons now add or remove the rich-editor respectively. You will notice that, when in HTML mode, the textarea resolves to a very small box. To combat this problem, simply give it some rows and cols markup, or style it with CSS.

Another route in you could take  is a single button that toggles the editor on or off. I use this in my TinyMCE Signature plugin. It’s not terribly different; just add some logic.

jQuery(document).ready(function($) {

	$('a.toggleEditor').click(
		function() {
			id = 'foo';
			if (tinyMCE.get(id)) {
				tinyMCE.execCommand('mceRemoveControl', false, id);	}
			else {
				tinyMCE.execCommand('mceAddControl', false, id);
			}
		}
	);

});

“A nonce is a number used once, and it is used for intention verification purposes in WordPress. Think of it as a password that changes each time it is used. [...] The idea is simple: we verify that user’s request is intentional by verifying that the request originates from within the WordPress admin.”

WordPress ships with a handful of convenient functions that help you create and verify Nonces. They are chiefly designed for synchronous use, or where data is passed from one web page to another using an HTTP request. You create a nonce in your initial form using wp_nonce_field() and then verify that nonce is correct in the method that handles the form with check_admin_referer(). It’s fairly straight forward and well documented.

However, what if you want to secure your AJAX (asynchronous) transaction with Nonce? With a simple glance at the code, an evil-doer could still send some irresponsible data to your plugin. You can approach the problem with the same theoretical mindset as a normal nonce: pass a code, check it, carry on. The main difference here is how we pass the nonce code.

Let’s imagine we have a very simple bulletin plugin that allows a registered user to type a note and post it without a page refresh. First, set up the basic plugin stuff.

$QuickNotes = new QuickNotes();

class QuickNotes {

	function QuickNotes() {
		add_action('admin_menu', array(&$this, 'add_note_page'));
		add_action("admin_print_scripts", array(&$this, 'js_libs'));
		add_action('wp_ajax_quicknotes_add', array(&$this, 'add'));
	}

	function add_note_page() {
		add_theme_page('Quick Notes', 'Quick Notes', 'administrator', 'quick_notes', array(&$this, 'notes'));
	}

	function js_libs() {
		wp_enqueue_script('jquery');
	}

	function notes() {

		if ( function_exists('wp_nonce_field') )
			wp_nonce_field('quicknotes_nonce', 'quicknotes_nonce');

		?>
		<div class="wrap">
			<h2>Quick Notes</h2>
			<ul id="note_board"></ul>
			<p>
				<textarea id="note"></textarea>
				<a class="button" id="add_note">Add Note</a>
			</p>
		</div>
		<?php

	}

	function add() {

	}

}

As a quick overview, here’s what has happened so far:

• We added an option page under Appearance that returns the ‘form’ held in the notes() method.
• Queued the jQuery library (good for AJAXing)
• Mapped an AJAX request using wp_ajax_ (action => quicknotes_add(), callback => add())
  • This allows us to use a method within our plugin to handle the AJAX request, as opposed to a separate web page.
• Created a Nonce to use called quicknotes_nonce.

Now let’s set up the actual AJAX request with jQuery so the user can add the note without a page refresh. Using the $.post method, we’ll send the values for both the note and the nonce when the ‘Add’ button is clicked. Finally, the note is pasted back to note board.

function notes() {

	// The Nonce ......... ?>

	<script type="text/javascript">

		jQuery(document).ready(function($) {
			$('#add_note').live('click',
				function () {
					note = $("#note").val();
					nonce = $("input#quicknotes_nonce").val();
					$.post(
						"<?php echo get_option('siteurl'); ?>/wp-admin/admin-ajax.php",
						{
							action:"quicknotes_add",
							note : note,
							nonce : nonce
						},
						function (str) {
							$('ul#note_board').html(str);
						}
					);
				}
			);
		});

	</script>

	<?php  // The Form ..........
}

So, the nonce is now being passed as a $_POST parameter just like standard operating procedure. Next, assert the validity of the nonce in the add() method. If the nonce is correct, move on to inserting the note into the database, or just echo it back to the list.

function add() {

	if (!wp_verify_nonce($_POST['nonce'], 'quicknotes_nonce'))
		exit();

	echo '<li>' . $_POST['note'] . '</li>';
	exit();

}

That’s it! Download the entire example.

A fine way to do this is via the class setting found under Insert/edit Link. Through a plugin or a theme, you can set specific classes from which the user can choose. Use the tiny_mce_before_init hook that WordPress provides. It works by declaring some extra classes that are added to the mega array of TinyMCE settings.

Drop this in your functions.php file, or in your plugin:

add_filter('tiny_mce_before_init', 'add_lightbox_classes');

function add_lightbox_classes($initArray) {

	$initArray['theme_advanced_styles'] = "Lightbox=lightbox;iFrame=iframe";

	return $initArray;

}

There is a problem with this, though! By using the tiny_mce_before_init hook you effectively replace the normal ones like: aligncenter, alignleft, etc. If you examine how the normal ones are generated, you’ll find they are not created through the initArray. They are fed in through another javascript object. If WordPress sees that there is something other than nothing in the theme_advanced_styles key, it replaces everything.

So, if you want to keep the normal ones you need to redo them in your hook function. I should probably submit a core patch that addresses this.

jQuery(document).ready(function($) {

	$('#start').datepicker({
		dateFormat: "@",
		onSelect: function(dateText, inst) {
			dateText = eval(dateText);
			var min = new Date();
			min.setTime(dateText);
			$('#end').datepicker('option', 'minDate', min);
		}

	});

	$('#end').datepicker({
		dateFormat: "@",
	});

});

It’s as easy as that.

However, if you’re localizing this script to the island from Lost, I cannot guarantee that start date will be there in the first place.

There are a handle-full of questions I’m dealing with. The most important, is “how do users prefer to post events?” There are two general ways I can imagine a plugin going about this one:

• Create an event from a specific post
• Create a discrete event, separate from the posts … with the option of linking to a post.

The database architecture would be very different foreach() of these scenarios. I think that the second would allow for more control over the calendar itself. For instance, if the calendar features events from all over the place (not your blog), the first scenario would require you to make a post for it anyway. With discrete events, you could feature events without an associated post.

However, a very intimate relationship between events and posts is probably what most users would expect from a ‘native’ WordPress event function.

Of course, there could be both … but that would mean, in theory, two separate ways to go about posting events. It could be a few too many avenues for reaching the same goal. Also, that would be a pain for me to document.

If you’ve got a second, please tell me what you think.

However, Thickbox is becoming a little antiquated:

• It’s no longer maintained (http://jquery.com/demo/thickbox/)
• In the WordPress context, it uses annoying $_GET variables to pass data

Now that the WordPress interface is being brought towards a more open source model, I hope this is one of things they change. I’d like to see more integration of the jQuery UI Dialog widget.

Regardless, Thickbox is how it works now; so here’s how to use it in a plugin.

Concept

The most frequent use (I’m saying this with no evidence to support my claim) of any modal box in a plugin is to do something without navigating to another page. For instance, you upload an image through a Thickbox; the page stays current, but an image is uploaded asynchronously through the modal-box.

For this example, let’s imagine that it is necessary for a user to decide something: black or white? We want them to open a box, decide, and close the box all from the plugin’s interface.

General Plugin Setup

<?php
/*
Plugin Name: Black or White?
Plugin URI: http://www.example.com/
Description: You choose.
Version: 0.1
Author: Kyle Truscott
Author URI: http://www.keighl.com
*/

$BlackOrWhite = new BlackOrWhite();

class BlackOrWhite {

	function BlackOrWhite() {
		add_action('admin_menu', array(&$this, 'add_admin'));
		add_action("admin_print_scripts", array(&$this, 'js_libs'));
		add_action("admin_print_styles", array(&$this, 'style_libs'));
	}

	function add_admin() {
		add_theme_page('BlackOrWhite', 'BlackOrWhite', 'administrator', 'black-or-white', array(&$this, 'admin_view'));
	}

	function js_libs() {
		wp_enqueue_script('jquery');
		wp_enqueue_script('thickbox');
	}

	function style_libs() {
		wp_enqueue_style('thickbox');
	}

	function admin_view() {}

	function choice() {}

}
?>

Fairly normal. In order to use Thickbox, you need to queue both the script and style respectively. WordPress has these pre-registered for us, so all we need to do is tell it to load with wp_enqueue_script() and wp_enqueue_style() from the constructor.

Calling the Thickbox Dialog

In order to actually have the modal-box pop up, it is necessary to do so through the href parameter of a link. This is where it gets ugly.

function admin_view() {
	?>
	<div class="wrap">
		<h2>Black or White?</h2>
		<p>
			<a class="thickbox button" href="<?php echo get_option('siteurl'); ?>/wp-admin/admin-ajax.php?action=choice&width=150&height=100" title="Choice">
				Choice
			</a>
		</p>
		<p>
			Your choice: <span class="your-choice"></span>
		</p>
	</div>
	<?php
}

You need to :

• Declare “thickbox” as one of the link’s classes (“button” is nice too)
• Direct the link to: <?php echo get_option('siteurl'); ?>/wp-admin/admin-ajax.php?
• Give it the following $_GET variables
  • action – tells WordPress how to handle the AJAX request, or what stuff to load into the Thickbox
  • width – the dialog’s width in pixels
  • height – the dialog’s height in pixels

The reason for passing the AJAX request through admin-ajax.php is so we can call one of our plugin functions … the one for the dialog box content. Back in the constructor, simply tell WordPress to which function it should redirect the AJAX request.

function BlackOrWhite() {
 add_action('admin_menu', array(&$this, 'add_admin'));
 add_action("admin_print_scripts", array(&$this, 'js_libs'));
 add_action("admin_print_styles", array(&$this, 'style_libs'));

 add_action('wp_ajax_choice', array(&$this, 'choice'));
}

Now, when the user clicks “Choose”, whatever we have stored in choice() will return within the box.

In the Thickbox

So far so good, but there is nothing in the modal-box. We need two buttons: black and white. The dialog box displays whatever is returned from choice(). Therefore, that’s where the buttons go.

function choice() {
	?>
	<p>
		<a class="button choice_button" id="Black">Black</a>
		<a class="button choice_button" id="White">White</a>
	</p>
	<?php
	exit();
}

Don’t forget to exit() the function, or you’ll get an annoying 0 in the Thickbox. We don’t have any href info for these links, because we’ll be handling their events via jQuery. The goal here is to only have one page, right?

Some jQuery

function admin_view() {
	?>

	<script type="text/javascript">
		jQuery(document).ready(function($) {
			$('.choice_button').live('click',
				function () {
					var choice = $(this).attr('id');
					tb_remove();
					$('.your-choice').html(choice);
				}
			);
		});
	</script>

	<!-- The rest of the admin view ... -->

	<?php
}

On the click event of either choice_button, we execute a function that returns the user’s choice to the main interface.  Use the live() method to bind the event, because the buttons were loaded via AJAX.

Removing the Thickbox is much easier than launching it … simply call the tb_remove() function.

Conclusion

All in all, using the Thickbox in WordPress plugins is not that hard, but it could certainly be easier.

Download the full tutorial code here: Black or White?

<?php
add_action("admin_print_scripts", "js_libs");

function js_libs() {
     wp_enqueue_script('tiny_mce');
}
?>

<script type="text/javascript">

	tinyMCE.init({
		mode : "exact",
		elements: "a_nice_textarea",
		theme : "simple"
	});

</script>

<textarea id="a_nice_textarea" name="a_nice_textarea"></textarea>

However, enqueuing the TinyMCE really won’t get you any results. You need to use the wp_tiny_mce() function, which is not well documented. Essentially, the function pre-constructs the TinyMCE for you, and you override its default options. The main option to override is editor_selector which points TinyMCE at a specific textarea class.

<?php
wp_tiny_mce( false , // true makes the editor "teeny"
	array(
		"editor_selector" => "a_nice_textarea"
	)
);
?>

<textarea class="a_nice_textarea" id="a_nice_textarea" name="a_nice_textarea"></textarea>

You can stick this anywhere you want, and it will work (for the most part). All the available configuration options for TinyMCE can be determined by referencing it within the array. WordPress has a bunch of them determined by default for the post content editor; most of them are fine as is.

// TinyMCE init settings
$initArray = array (
	'mode' => 'none',
	'onpageload' => 'switchEditors.edInit',
	'width' => '100%',
	'theme' => 'advanced',
	'skin' => 'wp_theme',
	'theme_advanced_buttons1' => "$mce_buttons",
	'theme_advanced_buttons2' => "$mce_buttons_2",
	'theme_advanced_buttons3' => "$mce_buttons_3",
	'theme_advanced_buttons4' => "$mce_buttons_4",
	'language' => "$mce_locale",
	'spellchecker_languages' => "$mce_spellchecker_languages",
	'theme_advanced_toolbar_location' => 'top',
	'theme_advanced_toolbar_align' => 'left',
	'theme_advanced_statusbar_location' => 'bottom',
	'theme_advanced_resizing' => true,
	'theme_advanced_resize_horizontal' => false,
	'dialog_type' => 'modal',
	'relative_urls' => false,
	'remove_script_host' => false,
	'convert_urls' => false,
	'apply_source_formatting' => false,
	'remove_linebreaks' => true,
	'paste_convert_middot_lists' => true,
	'paste_remove_spans' => true,
	'paste_remove_styles' => true,
	'gecko_spellcheck' => true,
	'entities' => '38,amp,60,lt,62,gt',
	'accessibility_focus' => true,
	'tab_focus' => ':prev,:next',
	'content_css' => "$mce_css",
	'save_callback' => 'switchEditors.saveCallback',
	'wpeditimage_disable_captions' => $no_captions,
	'plugins' => "$plugins"
);

For a closer look at wp_tiny_mce(), check out the source.

For incorporating the Visual/HTML mode switcher, and turning TinyMCE on and off, see Switching Visual/HTML Modes With TinyMCE.

This process can be done on any template. First, we need to procure the member’s id number, with which we can filter the database. There is a global variable for this, {member_id}, but it becomes rather unstable when used in conditionals and database queries. I find it easier to simply grab the $SESS data. Make sure the PHP parsing stage is set to input.

<?php
global $SESS;
$member_id = $SESS->userdata['member_id'];
?>

With this info we can query the database, and use a conditional statement to filter the members’ access. If their join date is after the entry’s date, we shut them down.

{exp:weblog:entries orderby="date" sort="desc" limit="1"}

	{exp:query sql="SELECT join_date FROM exp_members WHERE member_id = '<?php echo $member_id; ?>'"}

	    {if {entry_date} > {join_date} }

	        You get what you pay for!

			<!-- EE Entry Data ... -->

	    {if:else}

			Forget about it.

	    {/if}

	{/exp:query}

{/exp:weblog:entries}

Calendar

The same principles, as applied above, can be used within an AJAX-ified mini-calendar. Check out my post on the matter, because the following code builds upon it.

From within the {if_entries} bit of the calendar tag, you can filter the links by the same method of querying the database with the member’s id. If their join date is after the entry, they don’t see a link.

<?php

$weblog =  $_POST['weblog'];

if (isset($_POST['month'])) :
	$month = $_POST['month'];
	$year = $_POST['year'];
else :
	$month = date('m');
	$year = date('Y');
endif;

global $SESS;
$member_id = $SESS->userdata['member_id'];

?>

{exp:weblog:calendar weblog="<?php echo $weblog;?>" switch="calendarToday|calendarCell" month="<?php echo $month; ?>" year="<?php echo $year; ?>"}
    <table class="calendar" border="0" cellpadding="4" cellspacing="0">
    	<tr>
	    	<th class="calendarHeader">
		    	<a href="" alt="{previous_date format="%m"}" class="{previous_date format="%Y"}">&lt;</a>
		    </th>
	    	<th class="calendarHeader" colspan="5">{date format="%F %Y"}</th>
		    <th class="calendarHeader">
		    	<a href="" alt="{next_date format="%m"}" class="{next_date format="%Y"}">&gt;</a>
		    </th>
		    </tr>
	    <tr>
	    	{calendar_heading}
		    <td class="calendarDayHeading">{lang:weekday_abrev}</td>
		    {/calendar_heading}
	    </tr>
	    {calendar_rows }
	    	{row_start}<tr>{/row_start}

				{if entries}
				        {entries}

				            {exp:query sql="SELECT join_date FROM exp_members WHERE member_id = '<?php echo $member_id; ?>' "}
				                {if {entry_date} > {join_date} }
				                    <td class='{switch} calentry' align='center'>
				                        <a href="{day_path=<?php echo $weblog;?>/index}">{day_number}</a>
				                    </td>
				                {if:else}
				                    <td class='{switch}' align='center'>
				                        {day_number}
				                    </td>
				                {/if}

				            {/exp:query}

				        {/entries}
				    {/if}

			    {if blank}
					<td class='calendarBlank'>&nbsp;</td>
				{/if}
		    {row_end}</tr>{/row_end}
	    {/calendar_rows}
    </table>
{/exp:weblog:calendar}

With a little help from jQuery and AJAX, it’s not a difficult procedure. Essentially, we will create a separate EE template that dynamically generates a calendar, and load it in to another template passing some $_POST variables. When the users clicks “Next Month,” the calendar is regenerated without a page refresh.

Calendar Template

First, create a new EE template lib/calendar, or whatever you’d like to call it. Be sure to set the PHP parsing stage to input. As you can see, the month, year and weblog parameters for the calendar tag are being dynamically accepted from the $_POST array.

<?php
$weblog =  $_POST['weblog'];
if (isset($_POST['month'])) :
	$month = $_POST['month'];
	$year = $_POST['year'];
else :
	$month = date('m');
	$year = date('Y');
endif;
?>

{exp:weblog:calendar weblog="<?php echo $weblog;?>" switch="calendarToday|calendarCell" month="<?php echo $month; ?>" year="<?php echo $year; ?>"}
    <table class="calendar" border="0" cellpadding="4" cellspacing="0">
    	<tr>
	    	<th class="calendarHeader">
		    	<a href="" alt="{previous_date format="%m"}" class="{previous_date format="%Y"}">&lt;</a>
		    </th>
	    	<th class="calendarHeader" colspan="5">{date format="%F %Y"}</th>
		    <th class="calendarHeader">
		    	<a href="" alt="{next_date format="%m"}" class="{next_date format="%Y"}">&gt;</a>
		    </th>
		    </tr>
	    <tr>
	    	{calendar_heading}
		    <td class="calendarDayHeading">{lang:weekday_abrev}</td>
		    {/calendar_heading}
	    </tr>
	    {calendar_rows }
	    	{row_start}<tr>{/row_start}
		    	{if entries}
			        {entries}
		                <td class='{switch} calentry' align='center'>
		                    <a href="{day_path=<?php echo $section;?>/index}">{day_number}</a>
		                </td>
			        {/entries}
			    {/if}
			    {if not_entries}
					<td class='{switch}' align='center'>{day_number}</td>
				{/if}
			    {if blank}
					<td class='calendarBlank'>&nbsp;</td>
				{/if}
		    {row_end}</tr>{/row_end}
	    {/calendar_rows}
    </table>
{/exp:weblog:calendar}

Javascript

For the user page, where the calendar is to be displayed, first load the jQuery core. Also, create an empty div with an id of “calendar” somewhere on the page.

<script type="text/javascript" src="http://code.jquery.com/jquery-latest.js"></script>

Create the calendar functions using jQuery’s $.post method to load the calendar. We send it, via post, the data for the specific month/year we’d like to display. In parallel, jQuery is on the prowl for links embedded in the calendar; clicking on these links trigger the render_calendar() function again, but this time with new month/year data extracted from the prev/next links we set up in lib/calendar. The data is stored as class and alt; you could store them however you want, though.

$(document).ready(function(){

	var weblog = "xxxxxx";
	var month = xx;
	var year = xxxx;

	render_calendar(section,month,year);

	function render_calendar(section,month,year) {
		$.post(
			"{path='lib/calendar'}",
			{ weblog : weblog, month : month, year : year },
			function(str) {
				$('#calendar').html(str).fadeIn();
			}
		);
	}

	$("#calendar a").live("click", function(){
		$('#calendar').fadeOut();
		month = $(this).attr('alt');
		year = $(this).attr('class');
		render_calendar(section,month,year);
	});

});

And that’s it!

As with all things, though, the evil IE6 makes you look like a fool when Corner breaks everything on your painstakingly crafted layout. I’ve deduced that the main bug with IE is that when applied to floated elements without specified widths, IE corners them as if their widths were 100% of the parent container. So, if you have an unordered list of menu items that are floated left of right, it will look horrible. Unfortunately, this scenario is the most common implementation of menu tabs where the widths are entirely unpredictable.

The solution I discovered was apparent only after I diagnosed that undeclared widths were the root problem. With a little more jQuery, there’s an easy fix.

$(document).ready(function(){ 

	jQuery.each($('.nav ul li'), function() {
	    var width = $(this).width();
		$(this).css({ width:width });
	});

	$('.nav ul li').corner("3px");

});

Assuming that .nav ul li is something like your floated list, before applying the rounded corners assign each matched element a width. This bit uses the each() selector to go over each list item, measure its width, and then apply that width with CSS. Now, IE6 has a specified width for each element, and you can stop pulling out your hair follicles.

And this idea extends to many other IE problems … if things are ugly, give them explicit widths.

I’ve only listed the array items that I think are typically important, but there are a few more available; there’s a full list of them here.

<?php
	$comments = get_comments();

	foreach($comments as $comment) :

		if ($comment->comment_approved == 1) : 

			echo $comment->comment_ID;
			echo $comment->comment_post_ID;
			echo $comment->comment_author;
			echo $comment->comment_author_email;
			echo $comment->comment_author_url;
			echo $comment->comment_date;
			echo $comment->comment_content;

		endif;

	endforeach;
?>

First of all, we want the images to be rendered on a template that is only visible to members of group-x. This is done easily within EE from the Template Access Restriction section of the control panel.

Typically, this would be good enough for protecting sensitive text content, but leaves images still at risk. A real jerk could look at the tag <img src="./images/confidential.png" /> and point all his internet buddies to the path, or take some other stuff he shouldn’t have his dirty little fingers on. The biggest hole is the simple <img> tag. So, to be safe we can protect the /images/ director with .htaccess … but now the upstanding citizens of group-x have to authenticate themselves again with credentials outside of EE to view the images. Annoying.

Here’s what we do. As long you’ve got an image library on your server (like GD, or ImageMagik), you can hide the real path to the images, and avoid the separate login box. Instead of an absolute or relative path to the image in the src parameter, just send it to a secret script that creates the image.

<img src="{path=lib/image}confidential.png/" />

This will output something like this when rendered in EE:

<img src="http://www.example.com/lib/image/confidential.png/" />

What’s cool in this case is that the image will generated from within this off-site script; the user cannot know the real location of the image. Better yet, because PHP can access protected directories, the user won’t be prompted to login via .htaccess. And … (yes there’s more) if we created the script as its own template in EE, it can be protected just like the main template so only members of group-x will be able to view it. For outsiders, the image will not be generated. It’s two-tiered protection.

<?php

$image = "{segment_3}";
$url_path = "{segment_4}";

switch ($url_path):

	case "image_bin":
		$path = '../../photos/';
	break;
	case "espionage":
		$path = '../../state/secrets/';
	break;
	default:
		exit();
endswitch;

if (is_file($path . $image)) {
    $f = $path . $image;
} else {
	exit();
}

header('Content-type: image/png');

$im = @ImageCreateFromJPEG ($f) or // Read JPEG Image
$im = @ImageCreateFromPNG ($f) or // or PNG Image
$im = @ImageCreateFromGIF ($f) or // or GIF Image
$im = false; // If image is not JPEG, PNG, or GIF

if (!$im) {
    readfile ($f);
} else {
    @ImagePNG($im);
}

?>

So now, what does this script look like? If you examine the <img> tag above, you’ll see that the file name (in this case confidential.gif) is actually being sent to the script as a URI Segment Variable … not as a relative path. The third segment in the URI is the file name. The segments give a lot of extensibility to this process.

For instance, if there were more than one directory that these images are being pulled from, just slap another segment on that represents the path, without giving it away. So, /confidential.png/image_bin/. In this particular case, I went a step further, and assigned a code name for the directory segment, which is then translated privately from within the script in the switch.

The script takes the info from the URI segments, and spits out an image. It’s that simple.

What’s beautiful is that, through using this method, you can protect sensitive images through both permitting only certain member groups and hiding the true directories. Oh, and you can still use .htaccess. Now it sounds more like three-tiered security. Sheesh.

Here is a little background on what I needed. My client supplies confidential information to subsequent clients. It would be easy to register all their clients as member, and then restrict access to the templates so only members could see them. However, in this case, the company has a handle full of data sets, and its customers subscribe to specific sets; they aren’t allowed to see the others.

First, it is useful to name associated member groups, weblogs, and templates the same. So if we have four member groups (north, south, east, west), they have each have corresponding weblogs and templates (north, south, east, west). Also, the groups are given access to only their respective templates, which is done through the simple Template Access Restriction.

When our members first arrive at the site, they are prompted to login, so we’ll need a template group specifically for logging them in, {login/index}. This one page will handle everything we need.

<pre>{exp:member:login_form return="login/index"}

	<p><span class="userpass">Username</span><br/>
	<input type="text" name="username"  maxlength="32" class="input" /></p>

	<p><span class="userpass">Password</span><br/>
	<input type="password" name="password"  maxlength="32" class="input"  /></p>

	{if auto_login}
	<p><input class='checkbox' type='checkbox' name='auto_login' value='1' /> Remember me</p>
	{/if}

	<p><input type="submit" name="submit" id="submit" value="Submit" class="submit" /></p>

	<p><a href="{path='member/forgot_password'}">Forgot your password?</a></p>

{/exp:member:login_form}

Notice how the script returns itself to the same template, {login/index}. It doesn’t really matter where it returns because the bit we are about to add redirects the members after they log in to wherever they need to go … before the {exp:member:login_form} is queried again. ExpressionEngine gives us a convenient set of global variables that aid our redirections quite nicely. They are {group_id} and {redirect="template/path"}.

{if logged_in}
	{if group_id == "1"}
    	{redirect='north/index'}
    {if:elseif group_id == "2"}
    	{redirect='south/index'}
    {if:elseif group_id == "3"}
    	{redirect='east/index'}
    {if:elseif group_id == "4"}
    	{redirect='west/index'}
    {if:else}
    	{redirect='login/restricted'}
    {/if}
{/if}

The loop determines to which member group the user belongs, and pairs template redirection with that specific {group_id}. Simply identify the id number for each member group (easily found through the CP), and that’s it! We conclude the {if} loop with an {if:else} statement that takes care of any users who sneak through the log in process.

The {if:else} statement redirects these folks (perhaps they are members, but aren’t in a member group privy to the information shielded by EE’s template access) to some other template that tells them, “you don’t belong here.” This is a nice system, because you won’t need to do any extra coding on the templates the members are redirected towards. EE can handle access to those on its own.

There are limitations, however, to setting up you member redirect in this way. First, it assumes that your member groups are rather static (they are not being created or deleted frequently). If you have a ton of member groups with a ton of corresponding template groups, this would make from a monstrous {if} statement. Another option you have is setting some PHP variables using the EE {group_id} global. To do this you would have to set the PHP parsing to ‘output’ on the {login/index} template.