Simple Lightbox and Cornerstone share a lot of code (along with the rest of my WordPress plugins).  One of the nicest things about this is that work and time spent on one plugin can benefit the rest of them.  I spent a good deal of time developing Cornerstone’s Content Type functionality, so when I saw the similarities between it and the options management functionality that I’m planning for SLB, I was hopeful that the aforementioned time and effort could extend to and benefit my other plugins as well.

But Content Types are pretty major aspect of Cornerstone’s functionality.  Can this code really transfer over to SLB?

That’s what I set out to determine today.

The Big Question

The big question on my mind at the start of the day was: Is using CNR’s Content Type code simply going overboard for options management?

The answer?  Absolutely.

CNR’s Content Type’s functionality is way beyond what you’d need for creating and managing options.

However

However, as they say in real estate, it has good bones.  That is, the code for CNR’s Content Type functionality shares a foundational similarity to what I want for managing options.  Aside from the basics that I previous listed, CNR’s Content Type code has hooks for custom fields, hierarchical relationships between elements, nesting, etc.

These are all things that I see as valuable for making options management as flexible as I envision.  Remember, once completed, this code will go out to all of my other plugins and will make creating new and more robust options far simpler.

There’s a Future for this, I tell ya

Put simply, CNR’s Content Type functionality is all about dynamically generating forms for capturing different types of metadata for a post type.  Ultimately, once I’ve abstracted the common code out into it’s own class, I will have laid the groundwork for a fairly robust dynamic form builder.

I’m not saying that I’ll end up with a completely new plugin for creating custom forms at the end of this, but I am saying that I won’t be too far off from one 🙂