Cornerstone’s content types now have the ability to hook into WordPress with actions and filters, making it easy to fully customize how post fields are retrieved, displayed, and saved.

Background

With the release of WordPress 1.2, customizing WordPress has been greatly simplified by the inclusion of a plugin API.  This API is comprised of actions and filters that provide specific points in WordPress for plugins to “hook” into and customize how WordPress functions.  This makes WordPress an incredibly flexible platform for any type of project ranging from simple blogs to complex web applications.

Similarly, Cornerstone’s content types are like mini plugins that customize posts for a particular use or purpose. Thus, content types would also benefit greatly from the ability to hook into WordPress’ actions and filters.

Explore

I openly admit that while I had this on my to-do list for a while, I was actually tricked into implementing this functionality into Cornerstone when I wanted to create a rich text (aka WYSIWYG) field for use in content types.  This would make it simpler to format content in text fields, since the standard textarea field is simply plain text (no formatting).

Since WordPress uses TinyMCE as its rich text editor by default, it was a logical choice for Cornerstone’s richtext field, so I did some exploratory work to determine how TinyMCE is implemented in WordPress itself.

As I said, I was tricked into enabling actions and filters for content types.  When I started looking into using TinyMCE in a field, I assumed that it would require adding Javascript to a page (since this is how TinyMCE is implemented by default), which Cornerstone’s content types can already do:

$field->add_script($context, $handle, $uri, $dependencies);

However, WordPress uses an action to call a function that handles all of the configuration and Javascript loading separately:

add_action( 'admin_print_footer_scripts', 'wp_tiny_mce', 25 );

I was already committed.  Cornerstone’s content types would need to have access to actions and filters.

Experiment

There were a couple of questions that needed to be answered before hooks would be enabled in Cornerstone.

1. Which content types to register hooks for?

During initialization, all content types are registered so that WordPress has access to them.  However, not all content types are used in every request, so it would not be a good idea to register the hooks for all content types, but rather only the ones that are used in the current request.  Therefore, the first step is to determine which content types are used in the current request.

2. When to register hooks for content types?

Once we’ve determined which content types are currently in use, we can register the hooks for them.  The issue here is that we need to use a hook to register the hooks for the content types, so we’ve already lost one potential hook for content types to use.  We also need to make sure that WordPress is far enough along in its initialization process to be able to accept a content type’s hooks (i.e. environmental variables set, default post types registered, etc.), which may remove yet more hooks from those that content types can use.

After a bit of research and testing, the optimal hook to use for registering actions and filters for content types was init:

add_action('init', 'add_hooks', 11);

This means that the init action and any hook that precedes it will not be available for content types.  I’m not particularly fond of this limitation, but it is mitigated by the fact that there are only a few hooks before init and the vast majority of content types will use hooks that come after init. Nonetheless, I would be happier if init were available to content types (since it’s a pretty common hook), so I’m still looking at some options for bringing it back into the fold.

In the end, enabling action and filter hooks for Cornerstone’s content types was not as involved as I imagined it would be (hence why it sat on my to-do list for as long as it did), and the ability to hook into WordPress with content types was well worth the time and effort.

Payoff

The payoff for the work is that hooking to WordPress is as simple as this:

$richtext->add_action('admin_print_footer_scripts', 'wp_tiny_mce', 25);

Even better is that the possibilities are now endless.  Just as with plugins, it’s really now down to our imagination to use Cornerstone’s content types to customize WordPress to the needs of our projects.

Cornerstone: Now is the Time for Action (and Filters) was originally published on Archetyped on August 25, 2010 11:47am

The other day, I fired up WordPress to write a new post, added the title, and started to write the post’s content, when I noticed something strange was going on with the permalink preview:

Oops

The Bug

One of Cornerstone’s main features is Structure.  Structure allows a site to have sections and for authors to add posts to any of these sections.  When a post is added to a section, Structure makes sure the post’s permalink is logically connected to the section’s permalink.

• Section: http://site-name.com/section-name/
• Post: http://site-name.com/section-name/post-name/

Cornerstone adds a new permalink structure to Settings > Permalinks in the site’s admin area which lets users enable this type of logical connection between posts and sections.

• Structured: /%postpath%/%postname%/

On this particular occasion, I had not yet selected a section for the post, which is was fortuitous because it revealed that Structure’s permalink modification was not working quite right for drafts.  In truth, it was not working at all because Structure was disabled for drafts.

function post_link($permalink, $post, $leavename = false) {
	global $wp_query;
	if ( !$this->using_post_permastruct()
		|| ( !$this->util->check_post($post) )
		|| !$this->util->property_exists($post, 'post_name')
		|| empty($post->post_name)
		|| !$this->util->property_exists($post, 'post_parent')
		|| 0 == $post->post_parent )
		return $permalink;

//	...continue modifying permalink...

According to this code, the custom permalink structure will not be used if any of the following conditions are met:

• Cornerstone’s custom permalink structure is not enabled
• Valid post not passed to function
• Post has no name (e.g. drafts)
• Post is not in a section

Since the function stopped before making any modifications to the draft post’s permalink, the permalink generated by WordPress remained.  However, since Cornerstone’s permalink structure contains a custom structure tag (%postpath%), WordPress did not know what to do with it and simply left it in the permalink (only replacing the standard %postname% tag).

Posts without sections are simply supposed to be located at the site’s root level (e.g. http://site-name.com/post-name/), but the conditions that were set to determine whether a post’s permalink should be modified were overly aggressive.  The result was that any post that wasn’t in a section would have an invalid permalink.

The Fix

Thankfully, the solution to this issue was quite apparent– simplify!

function post_link($permalink, $post, $leavename = false) {
	global $wp_query, $cnr_content_utilities;

	if ( !$this->using_post_permastruct()
		|| ( !$this->util->check_post($post) )
		|| ( empty($post->post_name) && empty($post->post_title) ) )
		return $permalink;

//	...continue modifying post permalink...

Now the custom permalink structure would be used for a post except under just a few conditions:

• Custom permalink structure is not activated by user
• Valid post not passed to function
• Post has no name or title (e.g. drafts)

We check for the existence of the post’s title if there is no post name (i.e. the post’s slug) because in certain instances, the post passed to this function may not yet have a slug, but it will have a title (which we can still work with).  Only if the post has neither slug nor title will we halt further processing (since we can’t build a full permalink without at least one of those values).

Finally, since custom post types made their full debut in WordPress 3.0, we need a small addition to support them as well.  Cornerstone allows putting items with custom post types into sections as well, so the same permalink structure is used for items that have a section selected (i.e. /section-name/post-name/).  However, by default, the permalink structure for items with custom content types is /post-type/post-name/, so if an item is not in a section and it has a custom post type, then the default permalink structure should be used.

So our final conditional statement looks like:

function post_link($permalink, $post, $leavename = false) {
	global $wp_query, $cnr_content_utilities;

	if ( !$this->using_post_permastruct()
		|| ( !$this->util->check_post($post) )
		|| ( empty($post->post_name) && empty($post->post_title) )
		|| ( !$cnr_content_utilities->is_default_post_type($post->post_type) && empty($post->post_parent) ) )
		return $permalink;

//	...continue modifying post permalink...

Now post permalinks work just fine and Cornerstone’s Structure is even more structured than before.

Cornerstone: Structure Now More Structured was originally published on Archetyped on August 20, 2010 06:03pm

Why?

The primary purpose of Favicon Rotator was to make it simple to upload a favicon for a WordPress site.  So in version 1.0, the plugin basically loaded the image as it was uploaded by the user.  This works perfectly fine, especially if the user uploads an image meant to be a favicon (i.e. 16×16 resolution).  Larger images were properly loaded as well, but it was left up to the browser to resize the image to fit in the 16×16 space in the browser’s address bar.  The other issue was that if the user selected a large image to use as a favicon, then the site’s loading time could be increased since the entire image needed to be downloaded (regardless of how small it was being displayed).

I definitely am not a fan of slower loading, but I was initially hesitant to create additional files since WordPress already automatically creates thumbnail files for all uploaded images, which is a waste of disk space if the user will never use them.  However, due to the potential for increased load times and the hit-or-miss results when letting the browser resize large images, I decided that Favicon Rotator should create an image optimized for use as a favicon.

Thankfully, WordPress is not stupid (quite smart in fact), and it will not create additional intermediate files (thumbnails, etc.) if the original image is smaller than the intermediate sizes.  This means that if a user does upload a 16×16 image file that is already optimized for use as a favicon, no additional files will be created.  Therefore, only images that would benefit from an intermediate file will have one created.

When?

Favicon Rotator doesn’t create favicon-sized files for all images uploaded to WordPress, but rather only when certain criteria are met:

• Images that are uploaded via Favicon Rotator’s admin page
• Images that were uploaded by other means, but are selected for use as a favicon

This minimizes the number of extraneous files in WordPress since optimized icons are created on-demand and saved for future use (so icons for an image are only created once).

How?

Adding a new intermediate size for uploaded images is very simple.  It only takes one quick line of code:

add_image_size($image_size, $width, $height, $crop);

Then, you simply add a hook to register this new size once WordPress has loaded.  Basically any hook including and beyond init will do, but I chose to hook into intermediate_image_sizes so that the favicon image size is added only when the available intermediate image sizes are requested (otherwise the favicon image size would be added during every request whether it was needed or not).

add_filter('intermediate_image_sizes', 'add_intermediate_image_size');

The custom function to add the favicon image size can be very simple:

function add_intermediate_image_size($sizes) {
	add_image_size('favicon', 16, 16, true);
	$sizes[] = 'favicon';
	return $sizes;
 }

However, since we only want to create an optimized file when uploading or selecting a file specifically for use as a favicon, we need to add a bit more code:

function add_intermediate_image_size($sizes) {
	$img = array('width' => 0, 'height' => 0, 'crop' => true);
	if ( $this->is_custom_media() ) {
		$img['width'] = $this->icon_dimensions['w'];
		$img['height'] = $this->icon_dimensions['h'];
	}
	add_image_size($this->icon_size, $img['width'], $img['height'], $img['crop']);
	$sizes[] = $this->icon_size;
	return $sizes;
 }

This updated function does the following:

1. Creates a default array with zeroed-out values for the intermediate image (more on why later)
2. Checks if the current request is initiated by Favicon Rotator (e.g. uploading/selecting an image via the admin page).  If so, set actual width/height values for favicon image (using object variables)
3. Adds image size to WordPress
4. Adds size name (e.g. ‘favicon’) to array of intermediate images sizes (using an object variable)
5. Return updated array of intermediate image sizes to filter

The reason why we create an array with zeroed-out values for the image dimensions is because the intermediate image sizes may be requested in multiple situations (e.g. when deleting an image attachment from WordPress) so we need to add a valid size to the list of intermediate sizes whenever it is requested.  However, since we don’t want to actually create an additional favicon file for images unless they are uploaded/selected via Favicon Rotator’s admin page, we set the width/height to 0, which WordPress will then skip when creating intermediate images.

That’s a wrap!

By adding this functionality, favicons from large images look better and load faster, which makes this a worthwhile update for me.  As with most updates, I don’t really know where I’m going next (since I usually include everything I want to before updating), so any further updates will likely be based on user feedback.  If you have any requests, make sure to leave a comment to let me know how Favicon Rotator can be improved.

Favicon Rotator 1.1: Optimized Icons was originally published on Archetyped on August 20, 2010 02:10pm

In general, I’m not a huge fan of WYSIWYG editors because what-you-see-is-not-always-what-you-get, and TinyMCE is no exception.  It’s neither the fastest nor the most lightweight editor out there, but it is quite capable and the plugin API is rather robust.  Over time, I have given the visual editor some leeway and have become accustomed to letting it handle my paragraph tags and bolded text.  Honestly, it’s not half bad and I find myself writing in the visual editor more and more often, only switching to the HTML editor when I need to make sure the proper markup is written.

At any rate, since I use WordPress’ visual editor fairly regularly (along with the majority of WordPress users out there, I’d assume), I decided to add redaction support to TinyMCE.  I could do it quick and dirty and just add a button that wraps the redact shortcode around the selected text, but that wouldn’t be fun.  Instead, redacting text in the visual editor will function very similarly to the way you would make text bold or italic.  Basically, click the “Redact text” button on the toolbar and the text styling is changed to indicate that it is redacted.  I think this is one of the benefits of the visual editor as visual cues make navigating through a post’s content far faster for most users than looking at the HTML source.

So far, I’ve:

• Added a button to TinyMCE’s toolbar to activate/deactivate redaction
• Setup CSS to provide visual cues to identify redacted text
• Started work on wrapping selected text in the redact shortcode

The interesting bit about TinyMCE is that you can add additional HTML markup in the post content to help with the visual cues in the visual editor, but when you view the source, you can swap out the presentation markup for the markup you want to be saved with the post content.  This makes it incredibly customizable in terms of presentation and final markup.

The main thing that’s left is to refine how selected text is wrapped with the shortcode.  Some things to consider when manipulating the selected text:

1. Is the selected text part of a larger chunk of chunk of text that has already been redacted?
2. Should the selected text be wrapped or unwrapped with the shortcode?
3. What should happen when no text is selected?

We definitely want to avoid nesting redaction shortcodes within each other so I’m going to take some time on this to make sure it works the way one would expect it to in the different situations.

I’m planning on putting together a tutorial on making a TinyMCE plugin for WordPress once I’ve released this plugin.  Even though I’ve done a fair amount of TinyMCE plugin development specifically for WordPress, I think having a quick step by step reference for creating a plugin for the visual editor would be a nice way to jump start development on the next one.  Hopefully others will find it useful as well.

On a different but related note, I was surprised today when I noticed that WordPress was telling me to update Redactor as a new version has just become available.

I found this perplexing at first because I was sure I hadn’t published an updated version of the plugin that I didn’t know about on my own development version of WordPress.  It appears that the “Updates” section of WordPress merely looks for matching plugin names on WordPress.org (as opposed to checking the plugin URI as well) as it turns out that I was being notified of a new version of a different plugin with the same name.

I checked whether there was already a plugin called “Redactor” on WordPress’ website last week to avoid confusion when I first started writing about my plugin.  I figured this other plugin must be very new.  It is, it was released today.

What’s cool is that it has many of the same features that have or am planning to implement in my plugin (from manual shortcodes to automated text replacement).  It’s always nice to have more than one option.  While Redactor is just a code name for the plugin during development, I was considering the possibility of using it as the official name (since it’s rather descriptive of it’s functionality), but I guess the decision has been made for me.  Thanks!

Redactor – Quality time with TinyMCE was originally published on Archetyped on August 9, 2010 10:46pm

Well that didn’t take as long as I expected it to. While I still have some tests to run through, all work has been completed to make Cornerstone compatible with WordPress 3.0!  I was expecting this to take at least 2-3 days due to the amount of code I had to check, but after finishing what I had scheduled for today, I decided to just keep chugging along and ended up finishing everything on my list without much delay.

Here’s a rundown of what I did today:

Structure

Permalink Structure

The first thing on the list was adjusting the permalink structure for posts with custom post types.  By default, the structure for posts with custom post types is /post-type/post-name/, which doesn’t cut it when posts can now be added to a specific section regardless of their post type.  What we want is for all posts to use /section-name/post-name/ as their permalink structure.  I didn’t think this would be too difficult to rectify, and thankfully it wasn’t.  A quick look at get_permalink() (which Cornerstone hooks into to filter a post’s permalink) revealed that posts with custom post types were processed separately from standard posts:

elseif ( in_array($post->post_type, get_post_types( array('_builtin' => false) ) ) )
	return get_post_permalink($post, $leavename, $sample);

So in addition to hooking into post_link for standard posts, we also need to hook into post_type_link (which is called in get_post_permalink()). Thankfully, both filter hooks pass the default permalink along with the current post’s data (except that post_link supplies the entire post object while post_type_link only supplies the post’s ID) so the same handler can be used for both:

add_filter('post_link', $this->m('post_link'), 10, 2); //Standard posts
add_filter('post_type_link', $this->m('post_link'), 10, 2);  //Custom post types

With this additional hook added, posts with custom post types now have /section-name/post-name/ as their permalink structure.

Post Sections

Next on my list was providing the UI on the edit forms for custom post types to select the section the post should be saved to.  Prior to WordPress 3.0, I added the section selector to the edit form sidebar by hooking into the do_meta_boxes action. This works exactly as it should on the edit form for custom post types in WordPress 3.0, save for one difference– the action hook now passes the post type of the post currently being edited (as opposed to being hardcoded as “post” in earlier versions of WordPress). Since we only wanted the section selector to be added to the sidebar of the post edit form, that’s exactly what the handler looked for before adding the section selector meta box:

if ( 'post' == $type && 'side' == $context )
	add_meta_box($this->add_prefix('section'), 'Section', $this->m('admin_post_sidebar_section'), 'post', 'side', 'high');

Since the post type can now be variable, the condition for adding a the section selector meta box needed to be expanded a bit:

$child_types = get_post_types(array('show_ui' => true, '_builtin' => false));
$child_types[] = 'post';
$side_context = 'side';
$priority = 'high';
if ( in_array($type, $child_types) && $side_context == $context )
	add_meta_box($this->add_prefix('section'), __('Section'), $this->m('admin_post_sidebar_section'), $type, $context, $priority);

Basically, all custom post types that would have an edit form are retrieved, the “post” post type is added to the array of possible post types, and a check is performed to see if the current post type is included in this array. If so, the meta box is added and the section selector is displayed on edit form’s sidebar. I also took this opportunity to move some of the values in the add_meta_box call out into separate variables to further simplify future maintenance.

Taxonomies

I honestly thought it would take longer than it did to go through and fix the compatibility issues with permalinks and section selection so that was really all I had intended to work on today.  After finishing them so quickly, I decided that I would work on getting the rest of the edit form for custom post types to work properly.  The first thing was adding access to the standard post taxonomies (specifically, categories and post tags) on custom post type edit forms.

Once again, I thought I was in for some digging through WordPress’ code, and once again, it turned out to be incredibly simple.  WordPress provides the register_taxonomy_for_object_type() function that makes it very simple to connect a previously-registered taxonomy to a post type.  I could have used this, but WordPress also provides the ability to automatically register a taxonomy with a post type at the same time the post type itself is registered.  This is accomplished by adding a single item to the arguments array passed to register_post_type() when registering a new post type:

//...additional arguments for the post type being registered
'taxonomies' => get_object_taxonomies('post')

By using get_object_taxonomies('post'), we can be sure that any taxonomies registered to the standard “post” post type is also registered to our custom content types. In the future, I may add functionality to enable more control over which custom content types will inherit the taxonomies from WordPress’ built-in post type, but for now this makes the edit form for custom content types functional and useful for those wanting to use the same basic taxonomies with all content types.

Content Type Fields

The final thing that remained to make Cornerstone compatible with WordPress 3.0 was displaying a content type’s predefined fields on the edit form.  The implementation prior to WordPress 3.0 employed multiple hooks to make it all work (since custom post type functionality was not as fully fleshed out as it is in 3.0), but now all I needed was one hook:

add_action('do_meta_boxes', $this->m('admin_do_meta_boxes'), 10, 3);
//Build UI on post edit form

The handler is also very simple. Once it confirms that the context is appropriate for building the fields for a content type, the processing is handed off to an instance object of the content type definition which has a method to build the fields in meta boxes for output on the edit form:

function admin_do_meta_boxes($type, $context, $post) {
	//Validate $type. Should be 'post', 'page', or a custom post type for our purposes
	if ( in_array($type, array_merge(array_keys($this->get_types()), array('post', 'page'))) ) {
		//Get content type definition
		$ct =& $this->get_type($post);
		//Pass processing to content type instance
		$ct->admin_do_meta_boxes($type, $context, $post);
	}
}

Coming up next

With the compatibility work on Cornerstone out of the way, I can now continue where I left off before upgrading to WordPress 3.0 and start developing additional features and functionality for Cornerstone.  Here’s my basic plan:

1. Complete compatibility testing, fixing any small issues I missed
2. Develop UI for managing custom content types and their fields

The content type/field management UI will be heavy with “drag and drop” functionality to make adding and customizing content types very quick and simple.  This is one of the last major milestones I’m working towards before Cornerstone enters the public beta phase, so I am pretty excited to get started on this.

At the same time, I have a few other ideas for projects that have been dancing around in my head for the past few days and I’ve been itching to explore some of them.  I don’t intend to stay away from Cornerstone development for too long, but several of these projects will actually be using Cornerstone as the foundation of their functionality so I’ll still be working on Cornerstone as I explore these other projects.

Cornerstone: We have compatibility! was originally published on Archetyped on August 2, 2010 11:01pm

Today I began working on making Cornerstone compatible with WordPress 3.0.  Content types (whose primary role is to allow creation of additional metadata fields for post types) was first on the list.

Prior to 3.0, I had developed my own implementation for creating, editing, and managing different post types from the admin menu.  Now that WordPress’ own custom post type functionality was ready for these tasks, my first task was migrating the functionality of my custom implementation to use WordPress’ implementation.  I considered my implementation a stopgap since I knew WordPress would have custom post type management sooner or later, so it wasn’t an unexpected task.  Nonetheless, I wasn’t exactly looking forward to it.  In the end, it wasn’t all that bad.

Registering Custom Content Types

The first thing I had to do was integrate my custom content type definitions with WordPress’ own custom post type array.  While they are fairly similar at the base level, Cornerstone’s content types contain somewhat more data and functionality than WordPress’ custom post type objects (mostly because Cornerstone’s content types also contain metadata field definitions for the custom content type), so I couldn’t just use WordPress’ post type implementation.  In the end, it was a simple matter of calling the register_post_type() function during the registration of each custom content type in Cornerstone.  This way, custom post types are registered for each custom content type defined by Cornerstone and some of the work is handed off to WordPress.

Administration Menus

One of the main changes to WordPress’ custom post type functionality in 3.0 is that management functionality can now be automatically setup for each custom post type.  Simply put, each custom post type now has a section in the admin menu with functionality to manage, edit, and add new items of the custom post type.  Registering each content type with WordPress (using the same register_post_type() call as above) handled this, and I was able to offload a bunch of custom functionality in Cornerstone onto WordPress itself.

Content Item Management

WordPress now handles listing all custom post type items, so displaying all items with a custom post type was fairly straightforward (it mostly consisted of me removing my custom handlers for this functionality).

In my custom implementation, all content items (e.g. posts) with custom content types were still identified as posts in the database as WordPress’ custom post type functionality had not been completely integrated into the core prior to 3.0.  Instead, the custom type of a content item was saved as post metadata, which I felt was safer since I wasn’t sure how things would be changed in later revisions of the custom post type functionality.

Tomorrow

1. Including items with custom content types in default post query

   In 3.0, items with custom post types are not retrieved in standard post queries, meaning that they would not be displayed inline with other posts when content items chronologically (e.g. as in a blog).  The primary purpose of custom content types in Cornerstone is to allow different content items to contain specific metadata fields based on their content type.  This means that they should also have the option to be included in the standard post listing on a blog, so I’ll probably have to hook into the queries to make sure items with custom post types are included in the default post query.

2. Global edit form functionality

   Also, since all content items were basically still defined as posts as far as WordPress was concerned pre-3.0, it was easily possible to assign new functionality to the post edit form that would show up when creating/editing items regardless of content type.  I will have to look into this a bit to determine what best way to add functionality (e.g. extra meta boxes) to the edit form for all items regardless of content type.

Cornerstone: Content Types in WordPress 3.0 was originally published on Archetyped on July 28, 2010 10:42pm

I held off on this move for far too long.  WordPress 3.0 has been out for over a month now so I decided to finally update my plugin development environment with the latest and greatest version of WordPress.

I generally do not upgrade any production sites with the latest version of WordPress immediately just in case there are any zero-day vulnerabilities (e.g. bugs/security issues that were not detected during the beta testing stage), but the main reason I didn’t update my development environment to 3.0 is because I guessed (correctly) that it would break some of my plugins.  Some of the plugins I’m currently developing are quite large and hook into many areas of WordPress, so there are a multitude of possible points of failure depending on what has changed in the latest update.  I should have been testing my plugin during the beta phase for 3.0, but I resisted because I didn’t want to deal with trying to support two versions of WordPress that might have mutually exclusive plugin requirements.

However, since version 3.0 has been out for over a month now with nary a security issue or major bug reported, I decided it was only logical to upgrade my development environment to 3.0 and focus on the future.  Since my large plugins are not even publicly released yet, there’s no real reason to worry about backwards compatibility with older versions.  These plugins will now only support 3.0+.

Upon upgrading WordPress, I was not surprised (though still a little dismayed) to find that certain parts of my big plugin did break.  It’s not likely a major issue, and it’s not all bad because several areas of my plugin are now redundant thanks to some of the new features/functionality of 3.0.  This means I can optimize my code and deliver a smaller, faster, and more future-proof plugin.

The main thing I was dreading (since I was sure there would be some issues after the upgrade) was the huge amount of compatibility testing that would be required for the various features of my plugin on WordPress 3.0.  As I developed the plugin, testing was a regular part of my workflow whenever I updated a certain feature, so testing did not require a lot of time.  However, I now have to test the entire plugin before I can even start to think about continuing development.  This does not sound fun to me, but I hope to have the majority of the testing completed within the next 1-2 days.

A small setback in development, but honestly, it would have to have been done at some point in time anyway.  It’s better that I do it now rather than after I’ve developed even more functionality that would need to be tested and modified to be compatible with the latest version.   It’s also a good lesson for the future as I will now be including betas of upcoming versions of WordPress into my development workflow so that there will be a smoother transition when the next version of WordPress is released.

Pulling the Trigger was originally published on Archetyped on July 26, 2010 08:53pm

I spent some time today updating Simple Lightbox to make, well, simpler.

The three main things I focused on were:

1. Adding a link to the settings page from the plugins page
2. Enabling/disabling lightbox functionality based on the type of page
3. Automatically activating lightbox functionality for image links on a page

Adding a link to the settings page from the plugin’s listing

While it’s just a link under the plugin’s name, adding a link to the plugin’s settings page greatly enhances usability because it keeps the user from having to search through the sidebar menu for the settings page.  Since Simple Lightbox’s settings have been added to the built-in Media (options-media.php) settings page, it’s even more important that a direct link to the plugin’s settings are included so that users can easily customize the plugin after they install and activate it.

I’ve seen other plugins add the settings link at the end of the list of links, but I think putting it in front of the other links is a better option because it is link most users will want to click for a plugin from the plugins page.

Enabling/disabling lightbox functionality based on the type of page

Next up was adding options to allow users to customize what types of pages the lightbox would be loaded on.  Depending on the type of site someone has, they may not have any image links certain pages (e.g. the home page or archive pages), so it would be a waste to load the lightbox on these pages.

I identified three groups of page types that users may or may not want to include Simple Lightbox on:

1. The home page
2. Archive pages – Any non-home page that lists posts (e.g. by category, tag, date, search results, etc.)
3. Single Pages/Posts

In my mind, the last group (single pages/posts) was the main use case for this plugin as a post’s full content is often only displayed on single pages, while excerpts are used for other page types (home page, archive pages, etc.).

Adding support for enabling/disabling the plugin on different page types was fairly straightforward and now users can choose when to load the client-side code.  I also cleaned up the code for building the admin settings UI so that only one function is needed to build the UI for all the setting fields instead of a separate function to build each field.  This extra step will make adding additional options to the settings menu incredibly quick and simple.  Simple for me, simple for you

Automatically activating lightbox functionality for image links on a page

The whole point of Simple Lightbox was for there to be an incredibly simple way to get a lightbox image viewer working on your site.  Version 1.0 greatly simplified the normal process by letting users customize the lightbox’s behavior from WordPress’ admin menu and keeping users from having to dip into Javascript.  However, though users were free from mucking about in Javascript, version 1.0 still required users to edit their template files and add rel="lightbox" to any image links that they wanted to be displayed in a lightbox image viewer.  I’m more than confident that most users could handle this, but the plugin just didn’t feel simple to me with this additional step.  In version 1.1, all links to images on the page are automatically activated to open in a lightbox image viewer.  This is done by adding one line of Javascript to the page:

$$('a[href$=".jpg"]:not([rel~="lightbox"])', 'a[href$=".jpeg"]:not([rel~="lightbox"])', 'a[href$=".gif"]:not([rel~="lightbox"])', 'a[href$=".png"]:not([rel~="lightbox"])').each(function(el){var rel=(el.rel.length > 0) ? el.rel + ' ' : ''; el.rel=rel + 'lightbox';});

This code is run once the page is loaded and adds the necessary rel="lightbox" attribute to all links on the page that point to image files (e.g. jpg/jpeg, gif, and png files).  I’ve also added an option to the settings page to let users disable this automation if they want the plugin to keep its dirty hands off their pretty links.

All in all, I think these additional features make Simple Lightbox truly simple.  Check out Simple Lightbox now and let me know if I need to add anything to make it even simpler

Simple Lightbox: Adding Options and Automation was originally published on Archetyped on June 2, 2010 05:05pm

Thankfully, Eclipse offers an easy way to greatly minimize the amount of scrolling you have to do.  Simply hold down the CTRL key on the keyboard when scrolling with the mouse wheel in an editor and you will now be able to scroll an entire screen at a time.

This simple addition makes scrolling an excellent choice for navigating through a file of any size.

Scroll though files in Eclipse at light speed was originally published on Archetyped on February 3, 2010 06:23pm

I spent some time yesterday working out the specifics of storing connections between content types and connections between different items (posts) and I’m pretty happy with the result.

An example of how connections can be useful:

Say you have 2 content types:

1. Recipes
2. Ingredients

Of course, all recipes must contain ingredients, so we need to tell the CMS that these two content types are connected. We can also define the type of connection between these items (“One to One” or “One to Many”).

• One to One: One item of one content type can connect to one item of another content type
• One to Many: One item of one content type can connect to several items of another content type

Will a recipe need to connect to just one ingredient, or will it need to connect to several? In this case, we would want to be able to connect a recipe to several ingredients, so we’re going to create a One to Many relationship between Recipes and Ingredients.

Now, when I’m adding a new recipe, thanks to the connection between these two content types, a list of ingredients will be displayed in the form to select ingredients that the recipe uses. Since this is a One to Many relationship, each ingredient has a checkbox next to it so that I can select multiple ingredients from the list. If it were a One to One relationship, the ingredients would be displayed as a drop-down list, which would only allow for one ingredient to be selected.

I really like the possibilities of this feature, but I think the goal now is to make it usable. In my opinion, it’s quite powerful as a feature, but it’s also somewhat abstract. So I’ve got to find a way to make it instantly clear how this feature could be useful to a user.

WordPress as CMS – Making the Connection was originally published on Archetyped on February 3, 2007 11:03am