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.

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;
?>

There are only a handful of things that need to change in order to brand the administrative backend with a unique logo.They are:

/wp-admin/images/logo-login.gif
/wp-admin/images/logo-ghost.png
/wp-admin/css/login.css

logo-login.gif

Replace this image with another logo; this asset is the image you see upon logging in to the dashboard. The image is normally 310×70 pixels. If the new logo has the same dimensions, you won’t need to alter login.css.

login.css

Change the attributes of h1 a to fit your new logo if it’s necessary. Most likely, the height and width attributes are good enough, but you might want to add a margin-bottom too.

h1 a {
	background: url(../images/logo-login.gif) no-repeat top center;
	width: 326px;
	height: 67px;
	text-indent: -9999px;
	overflow: hidden;
	padding-bottom: 15px;
	display: block;
}

logo-ghost.png

Again, replace this one with your new logo. I would recommend leaving this guy at its current dimensions (25x25). If you have trouble with the transparency factor, fill the background with #464646.

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.