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

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

Favicon Rotator is a free plugin for WordPress that makes it incredibly simple to add a favicon to your site.  Favicon Rotator uses WordPress’ own media management features to upload and add a favicon to your site so there is nothing new to learn.  If you know how to add an image to a post, you can add a favicon to your site!

What’s in a name…

Favicon Rotator gets its name from its unique support for multiple icons.  If you add more than one icon to the list, Favicon Rotator will rotate through the different icons, randomly displaying a different icon when someone visits the site.

How to Use

1. Install and Activate plugin
2. Go to the Appearance > Favicon page from the administration menu
3. Click the “Add new” button to upload or select icons to use from your media library
4. Click the “x” button in the upper right-hand corner to remove any icons you no longer what in the rotation.
5. Save changes and you’re done!  The favicon(s) you’ve selected will now be displayed when someone visits your site.

Screenshots

Favicon submenu in Appearance Admin Menu

Favicon Management

Download

Download now from WordPress.org

Favicon Rotator was originally published on Archetyped on August 12, 2010 07:33pm

Question of the Day – August 9, 2010 was originally published on Archetyped on August 9, 2010 11:07pm

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

The idea came about as a way to allow people to write without any filtering while still having piece of mind that they aren’t fully disclosing all of their personal information with the rest of the internet.  Personal journals, freewriting, and partially declassified government documents are all perfect places for Redactor.

Today I setup the plugin framework, created the shortcode to wrap around text that should be redacted, and added a button to the HTML text editor to automatically wrap selected text with the shortcode.

Example

Say an author wrote the following:

Hello, my name is Joanie and I love Chachi

This might be a bit too revealing for just anyone to see so, the author redacts some of the text

Hello, my name is [redacted]Joanie[/redacted] and I love [redacted]Chachi[/redacted]

When this post is viewed publicly, it will be displayed as

Hello, my name is XXXXXX and I love XXXXXX

Personally-identifying information redacted!  Take that ID thieves!

Pretty spiffy right?  The benefit is that the author (and any other logged in user with sufficient permissions) will still be able to see the original unredacted text in all its glory.

Of course, the plugin will be customizable, allowing authors to change the text used in place of redacted text.

Next

I have a bunch of ideas for this plugin, but my plan is to get the basic functionality working and release the plugin quickly.  To this end, the next step is adding a TinyMCE plugin so that authors can specify text to be redacted from the visual editor without having to manually write out the shortcode.

Redactor: A New Privacy Plugin for WordPress was originally published on Archetyped on August 6, 2010 07:30pm

Question of the Day – August 6, 2010 was originally published on Archetyped on August 6, 2010 06:56pm

I completed the changes to this site that I started yesterday but didn’t finish because of some last-minute bugs (glad to have found them before uploading).  The main issue keeping me from updating the site was that the featured posts functionality of Cornerstone was not working properly.  Featured posts in Cornerstone are similar to WordPress’ own sticky posts functionality in that it lets you place specific posts in front of the normal chronologically-sorted posts, which is useful when you want to highlight certain content.  Featured posts in Cornerstone differs from WordPress’ sticky posts in that it offers somewhat more customizability and control over how/when featured posts are displayed.

However, due to some changes last night, the featured posts weren’t being retrieved for output on the site.  To be quite honest, I wasn’t sure what I could have changed yesterday that could have broken the featured posts functionality, so I had no idea what to expect when I started investigating it this morning.  Thankfully the issue was relatively minor and was causing the wrong section ID to be used when attempting to retrieve featured posts for a specific section of the site.  I tightened up a couple conditional statements to make sure the section ID is properly retrieved and featured posts were once again working!

With that out of the way, I proceeded to prepare for deploying all updates to the production server.  Since everything had been updated to work with WordPress 3.0+, the first order of business was upgrading the production server to WordPress 3.0.1.  After that, I updated Cornerstone and the site’s theme files.  I cleared my cache, hit refresh, and held my breath.  The site loaded up fine and everything is working great on the production server!  The final step was changing the Dump section to Know, which basically entailed adjusting the section’s title, slug, and icon.

It took longer than expected for such a small change (all I originally intended to do was change the name of a section), but in the end the site is much better and more stable for the work that went into it.

Lessons learned

As with any situations that require troubleshooting, there are always lessons to be learned.  Here are some I lessons learned or reaffirmed today:

• Test, Test, Test – before any update big or small, I always follow the same workflow:
  1. Develop and test the code on my computer
  2. Upload updates to the offsite staging server (basically a private mirror of the public production server) to test for issues not found while testing locally
  3. Upload updates to the production server (the public site) and run through tests to confirm no issues exist

  The goal is of course to avoid any downtime on the public site and this basic workflow has saved me many headaches on all of my projects.  I should note that prior to each step I also backup all relevant files and databases so that I can revert to a working version very quickly and start fresh if things get too messy while I troubleshoot an issue.

• Exercise caution when manipulating WordPress’ post queries – Cornerstone hooks into the post query process in several modules (permalink rewriting, content types, featured posts, etc.) and I feel rather comfortable manipulating the query variables to retrieve the posts that I want, but it is also very easy to invalidate the query with just a small change.  Vigilance is key when manipulating post query objects.

I enjoy troubleshooting because I like the challenge of finding elegant solutions to problems.  Nonetheless, I am glad that I was able to work out the issues rather quickly today because it feels good to have my production site running the latest version of WordPress.

Next

I’m about to start working on 2 small WordPress plugins that I have been thinking about recently (one of them since this morning).  One is intended to improve privacy and the other will make it easier to customize a site’s favicon from within WordPress.  I’m looking forward to it.

What you should know now is that Dump is now Know was originally published on Archetyped on August 5, 2010 04:40pm