Speed Up WordPress Development With The Titan Framework

The Titan Framework is a new WordPress options framework that was released on WordPress.org this week. This set of tools was created to make it easy for WordPress theme and plugin developers to add options to their projects. This first release contains more than 20 options, including meta boxes, Google font selector, a media uploader, multicheck categories and taxonomies, theme customizer options and more.

Titan claims to be the easiest options framework you’ll ever use. With just a few simple lines of code you can quickly add customization options that are easy for clients to use and understand. For example, to get an instance of the Titan Framework for your plugin, you’d add just one line to the the main plugin file:

[php light=”true”]$titan = TitanFramework::getInstance( ‘my-plugin’ );[/php]

Setting up an admin page and menu for your options is as easy as adding a couple lines of code:

[php]$panel = $titan->createAdminPanel( array(
name => ‘Theme Options’,
) );[/php]

This helps to keep your code clean with the Titan engine powering the details related to building options.

The Titan Framework Was Built For Efficiency

me2I had the chance to speak with Benjamin Intal, Titan Framework’s creator, to ask him why he decided to put another WordPress options framework out into the wild, despite the fact that there are already so many. Intal said that Titan resulted from a bit of spring cleaning he completed on his themes.

“When I started creating WordPress themes 4 years ago, as my number of projects grew, I had a hard time managing all the code from the different themes I had,” he said. “By instinct, I started unifying all the similar code to make things more manageable. After months of work, I ended up with a huge framework that handled everything the theme needed.”

From there his private framework evolved as he learned more about WordPress best practices. Intal began removing much of the functionality and turning it into plugins:

My mindset was that every feature should be included with the theme. As I learned more and more about the ins and outs of WordPress, I learned that what I did was a big no no. So now, I’m dissecting those themes, and turning its innards into plugins. One of those is the Titan Framework.

Intal’s spring cleaning resulted in a powerful set of options that speed up development. He uses it regularly in client projects. In one example he needed to provide information on various locations on a map, so he created a custom post type for locations and Titan powers most of the meta box options for inputting custom fields such as latitude, longitude and other location properties.

While Intal maintains the framework for the purpose of efficiency in his own work, it’s now something that anyone can use. “Titan Framework focuses on ease of use,” he said. “For me, that translates to minimal coding and fewer things to remember.”

When creating the Titan Framework, Intal wanted to make a standardized way of adding options, so that it’s easy for developers to remember how to accomplish common tasks. He described the problem he was trying to solve and how Titan can improve your workflow:

In WordPress, admin options, custom fields and theme customizer controls are all different from each other. These are set up differently and getting the saved values for each type is performed differently. Titan Framework unifies all these so that you won’t really have to know whether you’re using an admin option, a custom field or a customizer control. Everything is just an option. Because of this, getting your saved values is just one simple method: the getOption method.

How to Include the Titan Framework in Your Project

Currently, if you want to use Titan with your work, you’ll need to have the plugin activated alongside your own theme or plugin. This will allow you to call the framework’s functions inside your project. Refer to the developers’ documentation on the Titan project page for further instructions and a snippet for checking to see if Titan has been activated.

“Ideally, Titan should always be a plugin that’s separate from your theme or plugin so that Titan can be updated for bug fixes or new features,” Intal said. However, he recognizes that some developers might want to bundle the framework within their projects. He plans on performing an update soon that will make that possible.

Future Additions to the Titan Framework

Intal has plans to expand the number of options in the framework, which currently includes most of the basics. He’ll be adding a palette selector, widget area selector and menu selector further down the road.

He also plans to include functionality for easily creating and selecting widget areas, as well as new functions for creating shortcodes.

Ital said that what he’s trying to accomplish with Titan is not based on a desire to improve deficiencies he’s seen in other frameworks. “When I was in the process of creating Titan Framework, I honestly did not dive into the other existing frameworks since I already had everything I needed to complete it,” he said. “I’ve just started now to check out what’s out there and I’m finding that there are a lot of great frameworks such as Redux and OptionTree.”

Of course, if you’re trying to learn how to code plugin and theme options from the inside out, then using an options framework is not the way to go. The idea behind using a framework is to save yourself time in development and focus on building your project. There’s no need to reinvent the wheel every time you need to add a few options. Titan saves you the hassle of having to code them from scratch. For more information and examples on how to use it, check out the Titan Framework homepage and documentation.


17 responses to “Speed Up WordPress Development With The Titan Framework”

  1. There are so many development frameworks now – and I’m sure this one is a great addition to the list. That said: I wish the framework developers would work together to create something awesome for core, which is where much of this really needs to be.

    Core needs standard markup for option data types, to be output via do_settings_sections(), standard sanitization/validation callbacks for option data types, and the same for custom post meta boxes and meta data. I think the best people to make that happen are the developers who have put so much time and effort into defining all of those things for their frameworks.

    Maybe we can lock Benjamin, Devin Price, et al in a room, and tell them they can’t come out until they have a patch? :)

      • As with everything in core, it should be extensible (via filters), but could feasibly cover the vast majority of use-cases.

        Reviewing Themes, I’ve seen so many ways to reinvent the same wheel; it’s wasted effort for something that can and should be standardized.

        • That’s the thing with Open Source. There are virtually no standards but people don’t want to be constrained or restrained with standards. Standards provide reasonable expectations of a specific kind of behavior but it seems no one wants that. Great example is Post Formats. Talk about something that needs standardized :P

          • Most of the big wins are at a low-enough level that personal coding preference would have little bearing on the “standard”. There are only so many ways that you can create form field markup for a given data type, and only so many ways that you can properly sanitize that data type.

            And don’t even get me started on Post Formats; I’m still crying over Mark Jaquith ripping my heart out when he pulled out the standard from WordPress 3.6 during beta…

          • Standards are good, so long as they don’t restrict what you are able to do. There’s an API for adding an options page to WordPress now, but it’s not restrictive as you can bypass it if you really need to (which you do need to for some edge cases), so people don’t mind that type of thing. It’s when the standard stops you from doing things that you want to, or at least actively discourages you from doing something outside of the box, which begins to annoy people.

            All this talk of standardising things is motivating me to try to figure out a patch for core which would setup a (reusable) API to implement header images (rather than the current system which seems to be hard coded in). Then we could use that same API to implement other theme wide images, things like banner images, footer images, sidebar images etc. rather than having to custom code them all.

    • This could be done in bits perhaps, as implementing all of this stuff for core in one hit would be quite an undertaking.

      The thing which annoys me the most, is how much jumping through hoops I need to do to create a simple meta box. But having said, there are a huge number of different types of potential meta boxes, so anything created to do that would need to be fairly extensible in itself. I’m not sure off the top of my head what the best approach to doing that would be, but it must be possible to at least make a system which handles validation callbacks and nonces automatically to ensure developers aren’t bypassing security systems (which often happens due to developers not figuring out how to handle those things correctly).

      Do you have any ideas on how you would go about implementing this type of thing Chip?

  2. I’d rather use a code generator at this point that spits out code according to the official API, vs adding an additional 3rd party API that tries to cover all these areas. Reason being is that it adds an additional API to learn. So far the track record of these solutions isn’t overwhelming, they all tend to get stale (right?). And I know it’s very minor and trivial, but it looks like the naming conventions don’t follow the recommendations set out by the PHP coding standards page.

    Or, like Chip said, something that can land in core at some point that helps to make common operations easier. The post meta api is already getting worked on by a fantastic group, it seems like a lot of things that will come out of that could be used across these other settings areas. Maybe Benjamin should join them?

    • A code generator would be a good idea, but isn’t that sort of the same thing with frameworks like Titan? A benefit with a framework is that when a new feature is added to it, you can benefit from it readily with just an update. Unlike with a generated code where you might want to re-generate it again.

      Yes there’s a new API to learn, although Titan tries to minimize the learning curve. A code generator that spits out code for Titan might be a good idea :)

  3. with a website which used to be unavailable, http://wp-labo.tendoo.org/wp-content/uploads/2014/10/titan-shit.png i got some doubt about this framework stability, either the current document is not enough provided. There is not a step by step guide for this framework. I have any way started reading provided documentation till i get lost within.

    Maybe, i’m wrong, but the author should really care about this.



Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: