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

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

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

After declaring compatibility with WordPress 3.0 for Cornerstone a couple days ago, I of course found a few bugs.  I spent some time squashing those bugs and ended up finding a couple more.

Cornerstone

So far, I’ve only found one new compatibility-related bug in Cornerstone (I did say I still had testing to do), but it was one that had me digging through a lot more code than I would have liked to get to the root of the issue.  As I was running through my tests, I noticed that all page permalinks were coming up as “page not found”.  I initially thought that this was due to some overzealous permalink rewriting, but the issue was still there after disabling all rewrite rule modifications.

After disabling about half of Cornerstone’s functionality to determine the cause of the issue, I narrowed it down to a conditional statement in the recent update I made to the Content Types module.  The conditional was supposed to determine the different situations where the additional post types should be added to the query so that all posts (regardless of their post type) were retrieved and displayed.  While most of the bases were covered, I forgot to exclude the situation were only one content item (i.e. a post, a page, an attachment, etc.) was requested.  I added an additional statement to the excluded situations,

is_singular()

and pages were loading up as good as new!  I then just re-enabled all of the modules that I disabled while I was troubleshooting the issue and we were back in business.

Archetyped

I recently decided to change the name of the Dump section since the content I’ve been adding to has been more resource-based as opposed to just brain dumps that I initially imagined I would be using that section for (turns out that’s what the Blog section is good for).  While WordPress makes this a fairly painless process, as it provides the UI to change the section’s title and slug (used in the URI) as well as handling redirects for links to posts in the old section, I still had a bit of manual work to do.  Specifically, I had to change the icon used to specify the section content belongs to.

Old Dump Section Icon

Since I was changing the icon text, I also decided to rectify something that started bugging me about these icons.  With text this small, Photoshop’s antialiasing causes the icon text to appear blurry and dull.  I don’t feel that they are clear enough, so I decided to remove the antialiasing all together since small text will generally be sharper and easier to read without any antialiasing applied.  However, it obviously would not do to have sharp text  just for one section, so I decided to change all of the icons.  It’s not really that bad, since there aren’t that many sections.

I think the new icons are much clearer and more readable so it was worth the time to rebuild all of the section icons.  All I really had to do to add them to the theme was overwrite the old image files with the newly generated ones.  Easy.

However, as I was testing the new icons, I noticed that the section descriptions were no longer showing up.

Section title and description

I initially wasn’t sure why this was, but it seemed to be related to differences in WordPress 3.0 and earlier versions of WordPress as my test server (using 3.0) was having this issue, while another test server (that uses an earlier version of WordPress) does not.  By inspecting the query variables for the page, I was able to see that the global $pages variable was not being populated with the current page’s content, which caused an issue because the get_the_content() function used in the theme uses this variable to retrieve a post’s content.  To resolve this issue, I simply wrapped the page’s output in the following conditional statement to pre-populate all of the necessary variables with the page’s data.

if ( have_posts() ) : the_post(); //Setup page data
/* Page Output */
endif; //End page output

Finally, it appears that my featured posts are no longer being properly retrieved.  As it stands, I’m not sure why this is, but it will have to wait until tomorrow as I’ve run out of time today.

Finding bugs is not always fun, but it is always good because it means that I’m able to fix an issue that I previously didn’t know about.  As much as I’d like my code to be perfect right out of the gate, I know there will always be room for improvement and optimization, so I’m thankful I at least came across these bugs before deploying my updates to my production server.

Names Taken, Bugs Squashed was originally published on Archetyped on August 4, 2010 11:21pm

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

My main goal today was including all content items (regardless of post type) for display on the front end.  This would return content type functionality to what it was prior to WordPress 3.0.  Custom post types are now 1st-class citizens in WordPress, each with their own place in the post_type column of the wp_posts table.  They’ve been promoted to the big show and are no longer relagated to the wp_postmeta table with all the other secondary post data.

For my purposes, custom content types (Cornerstone’s extension of WordPress’ own post types) should generally not interfere with the retrieval of content, but serve primarily to indicate the types of metadata a content item can/should contain.  Since I’ve decided to synchronize custom content types with WordPress’ custom post types for better compatibility, we now have a small issue since the default posts query (e.g. used on the home page, etc.) only retrieves content items with “post” as the post type, so items with other content types are left in the dust and not retrieved.  Isn’t that just how it always is?  You get a leg up in the world, only to be pushed back down.  I say equality for all content types!

To rectify this and allow all content items regardless of content type to be retrieved in default post queries, I’ve hooked into the pre_get_posts action to modify the query before any posts are retrieved.

add_action('pre_get_posts', $this->m('pre_get_posts'), 20);
//Calls internal method

When the pre_get_posts action is fired, Cornerstone’s pre_get_posts method:

• Checks to make sure the query is a standard post query
• Retrieves all custom content types and adds them to the post_type query variable

/**
 * Modifies query parameters to include custom content types
 * @param WP_Query $q Reference to WP_Query object being used to perform posts query
 * @see WP_Query for reference
 */
function pre_get_posts($q) {
	$qv =& $q->query_vars;
	$pt =& $qv['post_type'];

	/* Do not continue processing if:
	 * > In admin section
	 * > Single object requested
	 * > More than one post type is already specified
	 * > Post type other than 'post' is supplied
	 */
	if ( is_admin()
	|| is_singular()
	|| ( is_array($pt)
		&& ( count($pt) > 1
			|| 'post' != $pt[0] )
		)
	|| !in_array($pt, array('post', null))
	) {
		return false;
	}
	$default_types = $this->get_default_post_types();
	$custom_types = array_diff(array_keys($this->get_types()), $default_types);
	if ( !count($custom_types) )
		return false;
	//Wrap post type in array
	if ( empty($pt) || is_null($pt) )
		$pt = array('post');
	if ( !is_array($pt) )
		$pt = array($pt);
	//Add custom types to query
	foreach ( $custom_types as $type ) {
		$pt[] = $type;
	}
}

With the additional content types added to the query, all content items are now retrieved in standard post queries (ultimately, each custom content type will have the option to define whether it is included in standard queries or not).  All is now right with the world and I can sleep soundly knowing that custom content types are getting a fair shake.

Next

Work on content types continues as permalinks for content with custom post types need to have the ability use the section-name/post-name permalink structure enabled by Cornstone (by default it’s post-type/post-name).  Once that’s sorted, I’m heading back to the admin section to work on the edit form for items with custom post types.

Cornerstone: All Content Types Aboard! was originally published on Archetyped on July 30, 2010 08:36pm