What’s New in IgnitionDeck 1.1

If you’ve looked through the official release notes for IgnitionDeck 1.1, you’ll notice that from a feature standpoint, the new additions are rather light.

But you’ll also notice that 1.1 lists more changes than any version we’ve released in our history. So what gives?

In order to break down these change notes, and share improvements that could be of value to you, I’m going to break the edits into a few major categories:

• Developers
• Core Stability
• Preparatory Changes

Core Stability

Let’s get the boring stuff out of the way first.

Up until 1.0, the IgnitionDeck codebase was a mix of old code, modern code, and code that had no place in our plugin at all. Prior to 1.0, we would have loved to have upgraded the code base, but as we were working on stability, rewrites would be the worst thing we could have done at that time.

Then, at last,  1.0 was released and we could begin the arduous process of refactoring our code.  First, we wanted to reduce duplicated functions and code; remove redundancies if you will. Second, we wanted to better name our functions, classes, and variables based on true values and functionality. Lastly, we wanted to develop naming conventions that would carry through the plugin.

While the job here still isn’t complete, we’ve made significant progress in this regard, cutting thousands of lines of code from the codebase, while improving the stability and extensibility of the code that remains.

With 1.1, you’ll find that we’ve gone through every single line of code in order to delete it, improve it, or mark it for rewrite later. This provides you with the most stable and efficient version of IgnitionDeck yet.

Developers

Building extensions and themes for IgnitionDeck has shown us where we can improve our codebase in order to make it easy for developers to tweak, hack, and customize it to their liking. So new classes like  ID_Project, Deck, and ID_Purchase_Form now make it 1000x easier to create custom loops and get all of the values you need to display data the way you want to.

We’re also adding filters and hooks to everything we can. In 1.1, we’ve added the following new API items:

Filters

• id_purchase_form
• id_widget
• id_mini_widget
• id_level_after
• id_postmeta_boxes

Hooks

• id_order_update

We’ve also introduced changes to the purchase form that will enable the recognition of level id’s in the URL (e.g. ?level=1), which we’ll talk about in the next section.

Lastly, we’ve added a box for short level descriptions, in the event your clients/themes need to display two different level description formats. This is especially handy if you want to display html on the deck, but not break the purchase form.

Preparation for New Features

Many of you have been asking for level selection straight from the deck, especially after we demoed it on the IgnitionDeck Fund the Future page. While the interaction on that page is created via our new MemberDeck plugin, we’ve upgraded the purchase form and deck handlers in 1.1 in order to allow for similar interaction going forward.

The reason this is delayed is that we also need to upgrade Theme 500 to accommodate it, which we’ve almost completed. You’ll find that if you modify your current purchase levels to include a level url (e.g. myurl.com/?purchaseform=1&prodid=1&level=1), your purchase form should respond by loading only that level.

While that isn’t our final solution, it’s one approach that we’re looking at. We’d love to hear what you think about it, but in the meantime, know that our final solution will be rolled out in one of the next few releases.

From a developer’s standpoint, I am very excited about this release. And though there aren’t a lot of new bells and whistles here, I think you’ll find that the product is vastly improved even without them. If not, have no fear, we’ll have plenty of new toys to share very soon.