Inspiration

When designing this site, I created several different favicons. I narrowed it down to the icons that I liked best, but in the end, I couldn’t decide on just one.

Favorite Favicons

Then I thought, “why not both?” and so with a simple line of code, I rewarded my indecision and setup the site’s theme to randomly choose between the two different favicons each time the site was loaded.

<link rel="icon" type="image/gif" href="<?php bloginfo('template_directory'); ?>/images/favicon_<?php echo rand(1, 2); ?>.gif" />

It was a quick solution and I was happy with the end result, but maintainability is a big thing for me and I had thought that it would be great if a site’s favicon could be easily added or changed as simply as adding a photo to a post in WordPress. Even better, if multiple icons were added, it would automatically rotate through them, displaying a random icon each time the site is loaded. I’m not sure if anyone else does that or even wanted such an ability, but after adding multiple icons to this site, I knew it was something I dug.

Exploration

Once I reached a milestone in Cornerstone, I decided to spend some time exploring some of the other ideas I had swirling around in my head. Favicon Rotator was one of the ideas I decided to work on because I felt I could finish it quickly and would be good experience for the next phase of Cornerstone (administration UI’s, etc.).

Planning

The first step was planning out the plugin. The concept was pretty simple (add/manage favicon from admin page) and the ideas I had for implementation (mostly) clear, but I find that it’s a good first step to get those ideas out on paper or screen. Doing this helps to clarify the purpose and expectations for the project, making for a much smoother workflow overall.

I manage the majority of my projects using a customized version of TiddlyWiki (a small and fast self-contained wiki), so the first thing I did was create a new project and set about listing all of the features I envisioned for this project. Total time: 5 minutes.

Feature List: Different colors indicate feature progress

Wireframes

While not always necessary, wireframing is a quick way to iterate through ideas to optimize a layout. The goal was to make it incredibly simple to add a favicon to the site, so sketching out a few wireframes of the admin interface to make it as simple as possible would be time well spent.

Initial Wireframes - Rapid Iteration

I drew out the wireframes with a thick sharpie to keep focus on the overall UI design and to keep from getting lost in the little details at this point. I love to take the time to focus on the tiniest details, but at this phase the big picture was the priority so that I could move to the next phase quickly.  This worked out really well and helped me to arrive at an overall layout that I was happy to move forward with after a few iterations. Total time: 45 minutes.

Final Wireframes

Experimentation

Now that I knew what I wanted the plugin to do and how I wanted it to work, it was now time to develop it! This was the basic order of events during development:

1. Build administration UI
   • Setup layout (based on wireframes)
   • Add functionality to elements (“add new” button, “remove icon” buttons, “save changes” button, etc.)
2. Handle retrieving icon(s) from the database
3. Handle saving icon selection(s) to the database
4. Handle uploading and selecting images to use as icons
5. Randomly select an icon and display it when site is loaded

1. Build administration UI

Building the UI was quick and simple thanks to the wireframes. I’ve also used much of WordPress’ own CSS classes for many UI elements (buttons, headers, etc.), which I think is always a good idea because it makes it easier for users to use (since they’re already familiar with WP’s UI), it saves time when building the UI, and it will remain consistent with the rest of WordPress’ admin UI if they ever change the official design. For the icon containers themselves, I’ve decided to keep the design rather simple, but may decide to make them a bit more “WordPress-y” in the future so that it looks fully integrated.

Favicon Management UI

2. Handle retrieving icon(s) from the database

Since the functionality to actually add an icon to the list had not yet been developed (see step 4), I started off by adding some temporary data to the wp_options table where I would be storing the icon selections. Using that data, I developed the functionality to retrieve those values and build an element with the necessary icon information to be displayed to the user. Icon data was also added to a hidden form field that was updated whenever the icon selection was changed.

3. Handle saving icon selection(s) to the database

Though users added/removed favicons in a very visual “point and click” way, saving their changes was a much more straightforward process.  Data for the selected icons are stored in a hidden form field which is updated with a dash of Javascript whenever favicons are added and removed from the list.  When the “Save changes” button is clicked, the value from this form field is simply saved to the database.

4. Handle uploading and selecting images to use as icons

WordPress already has fairly robust media management capabilities built-in and since I’ve used it quite a bit in Cornerstone, I decided to use it in Favicon Rotator too. Mind you, this is not simply plug and play as there are a number of hoops to jump through to place nice with WordPress. Thankfully, no hacks are needed (mostly) because WordPress’ provides the necessary plugin hooks.

Launching the media upload UI

Launching the media upload UI is pretty straightforward. Just build a link to admin/media_upload.php with the appropriate URL query variables set.

<a href="http://archetyped.com/wp-admin/media-upload.php?post_id=0&tab=type&type=fvrt_icon&fvrt_action=1&TB_iframe=1" class="thickbox">Open Upload UI</a>

The necessary URL query variables are:

• post_id – The ID of the post that the media is being uploaded for. Media uploads are referred to as “attachments” in WordPress because they are attached to other content (posts, pages, etc.). In this case, we don’t want to attach the upload icons to a specific post, so we just set this variable to 0
• tab – The media management UI has several tabs, each with a different purpose (upload media, browse library, etc.). The upload tab is displayed by default, but in this case, this variable is set to type, which will cause the type URL variable to be processed (see below for why)
• type – The type of media being uploaded/browsed (image, audio, video, etc.). When the type is processed, WordPress fires an action formatted as media_upload_{type}, so in our case, an action called media_upload_fvrt_icon will be fired. I can then hook into this action to gain control over how uploads are handled.
• fvrt_action – Specifies that the media upload UI was launched by Favicon Rotator. This is a custom variable I add so that I can quickly determine whether to hook into the actions and filters fired by the media upload UI (e.g. when the UI is launched to upload images for a post, I don’t need to hook into it).
• TB_iframe – Whether or not the media UI is launched in an iframe (which it is in when used on the post edit form and in Favicon Rotator).

Also, by adding class=”thickbox” to the link, the resulting link will open in a non-modal popup (a lightbox) without leaving the current page.  I also needed to load the necessary files for the thickbox functionality:

add_thickbox(); //Adds thickbox files to page header

Add an “Add icon” button to uploaded media

Once the media upload UI is displayed, we need a way for the user to select an image and add it to the list of favicons.  To do this, Favicon Rotator hooks into the attachment_fields_to_edit filter to modify the fields/buttons that are displayed when viewing an attachment’s details in the media management UI.

Using this filter, all extraneous edit fields and buttons are removed (to keep things as simple as possible) and the “Add icon” button is added.

The end result is a clean UI with a simple button to add an icon to the list

Default Media Details

Media Details for favicon selection

Adding the selected icon to the list

Once the user has clicked the “Add icon” button for an image, the final step is sending the selected icon from the media management UI (in the “lightbox” popup) into the favicon list on the admin page. This is handled in essentially the same way that images are inserted into posts. The basic methodology is as follows:

1. User clicks “Add icon” button for an image.  This submits a form.
2. The form submission is evaluated to determine which image the “Add icon” button was clicked for
3. The image’s details (ID, source URL, and file name) are sent via Javascript to the underlying admin page
4. The media upload UI is closed

Once the admin page receives the image data, it builds a new icon container for the image and adds it to the list of icons. The image’s ID is then added to the hidden form field that corresponds to the icons in the list.

Finally (phew!), when the user clicks the “Save changes” button, the icon ID’s are saved in the wp_options table for safe-keeping. This is the other benefit of using WordPress’ built-in media management functionality– since attachments in WordPress are essentially posts, we can simply save their ID and reference it to retrieve the rest of their data. As a bonus, WordPress also has several functions specifically for retrieving attachment data (source URL, etc.) which saves us from having to develop those tools ourselves.

Development was clearly the longest phase in the entire process, but it was sped up greatly by the initial planning and wireframing that gave me a clear direction for the entire development phase. Total time: 19 hours

Wrap Up

The initial motivation for developing Favicon Rotator was to provide others with the capability to display multiple favicons randomly like this site does. However, during development, I realized that the real value of the plugin was quite a bit simpler and made it useful to a much wider audience.  Favicon Rotator enables anyone to easily add a favicon to their site (regardless of whether or not they want to rotate between multiple icons).  Users no longer need to edit theme files, manually upload images via FTP, or copy/paste URL’s to favicon files just to simply add a favicon to their site.

This is a capability that is missing in WordPress at the moment, so while I’m happy that I made a plugin that accomplishes my initial (though obscure) goal of icon randomness, I’m actually more enthused about the plugin’s potential to enable users to easily do something that may have been out of reach for them previously.

Making of: Favicon Rotator was originally published on Archetyped on August 17, 2010 10:46am

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

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