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.