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.