NHP Theme Options Framework

NHP Theme Options Framework

NHP Theme Options Framework

The NHP Theme Options Framework was introduced to Github around two weeks ago by Lee Mason. It’s basically the same Settings API that’s already built into Core, but comes with a bunch of “field types” you can use.

Is it easier to use than the Settings API directly? Well, one might argue, but I’d say “no”. To get an option with WordPress you just call get_option, while in NHP you need to define the $NHP_Options global and then use its get or show methods. It looks like both methods will fail with a notice, if the array key does not exist, and the show method will fail silently if the requested option is an array, try and debug that!

Does it look sexy? Definitely. Is Lee reinventing the wheel? Looks like he is, and tabs are supposed to go on top, like on all the other screens in WordPress — future-proof, remember? Anyway, let’s see where this ends up in a month or two, I’m pretty sure it will find adopters.

Feel free to share your thoughts in the comments section below. Thanks for rating this entry, and don’t forget to follow the blog by e-mail or using your WordPress.com account.

34 thoughts on “NHP Theme Options Framework

    • Thanks for your comment Brad! One more thing I totally forgot to mention is that it all looks sexy with the Glyphicons which are CC-licensed and seem incompatible with the GPL, meaning you’d have to look for a different set, or design your own, if you’d like such a theme to make it into the WordPress.org repository. Bummer!

    • I don’t agree… it gives the author much more possibility to add additional pages… anyone with a 1024 wide screen and more then 5 pages will have issues… I think the current setup is great!

      Disclaimer: I just landed on this page and love the current screenshot… going to do some research into this tonight :)

  1. I saw this one the other day when it got a bit of exposure on Twitter. My first impression was that it looked quite good. Agree with both Brad and Konstantin though, would be good to see the tabs across the top.

    • Thanks for the comment Anthony :) Would also love to see how this works with a narrow screen. If the goal of the Core team is to eventually make the admin panel behave on narrow screens on phone and tablets (i.e. responsive), frameworks like these might easily break. That’s less likely to happen if they were to use the markup and styles given by the Settings API.

  2. In the docs it says, you can either use get_options() or $NHP_Options. So you’re not restricted to use the global, are you? Otherwise I totally agree: The vertical tabs sure look sweet, but (unfortunately) that’s not a valid argument. Btw, thanks for the hint with Glyphicons and CC. I’m working on a theme that uses FontAwesome which is licensed under CC also. Planned a public release, now it looks like I’ll have to redo the whole icon parade. Too bad, hadn’t thought of it. :/

    • Hey Caspar, thanks for the heads up on the options, you’re right, you can use the native API to retrieve options from the database, as long as we’re sure the wrapper method calls aren’t doing anything extra, like an action or a filter. And yes, licensing is one thing you need to always keep in mind when adding any third party assets to themes and plugins, that you’d like to distribute through the official directory. Even simple things like a Creative Commons-licensed reset.css file or a CSS grid framework can result in a rejection.

      • I can’t believe I hadn’t thought of it. Maybe I’ll keep what I have, sort of do a “soft-opening” release under CC (that is, not in the official theme directory), and release a GPL-compatible, FontAwesome-ready version later when it’s clear the whole thing finds adopters.

  3. Have to completely disagree on where the tabs should go.

    The WordPress tab navigation is horrendous. It’s big, it’s chunky and it does not scale well as far as number of tabs. Change the NHP navigation to horizontal tabs and you will see exactly what I mean.

    It works in situations where you have 2 or 3 tabs. Beyond that? Forget it. It doesn’t scale well. The more tabs you add, the worse it looks.

    As for the excuse that 2 or 3 tabs should be enough? I agree in some cases be it really depends on the situation. An advanced plugin that is a full featured application for something like ecommerce, etc. isn’t going to get away with the minimalist attitude as far as settings go because of all the moving pieces that are involved.

    For that reason I’m not a fan of the tab navigation UI in WordPress and prefer a vertical navigation like in this example as long as it still fits in the the WordPress look and feel.

    Just because something is mimicking what WordPress itself does does not mean it is the right way. WordPress does not do everything right, and I would say from a reusable UI perspective the horizontal tabs are one of the things it does horribly wrong.

    WordPress does provide another UI that can be used for inspiration for theme/plugin settings navigation… the new help interface. When you click help in the top right it displays help with a subnavigation that is positioned vertically on the left side.

    I would take inspiration from that for styling settings subnavigation over the use of the ugly horizontal tabs that aren’t going to scale.

    • I absolutely love comments that start with “Have to completely disagree on …” because they start a conversation and make me think. I agree that more than five tabs across the screen can make it look worse than it’s supposed to, however, I do believe in conventions, and I do believe that horizontal tabs will get better in the future, and so will the themes and plugins that will use tabs now.

      Anyway, if you have too many options to fit in a horizontal layout then yeah, a vertical navigation can be a life saver. Thanks so much for your input on this Carl, I really appreciate it!

      For reference, here’s the vertical subnavigation for contextual help that Carl was referring to:

      • Never really noticed the vertical subnavigation before, that’s a great find.

        Basically I was of the opinion that horizontal tabs is the way to go, keeping in mind that being consistent with WordPress’ UI is important not just in theory, but it really does help users if we don’t make them learn another new, unexpected custom UI.

        However now that I think of it, there are three aspects that make me think vertical tabs for theme options could work:

        • The main WordPress admin UI is a sort of vertical tab, so at least we can be sure users have some familiarity and know what to expect when looking at a horizontal tab menu.
        • Theme options are not necessarily a new feature of WordPress themes, and popular theme shops like WooThemes might already give a good percentage of users some familiarity with vertical tabs.
        • Lastly, that there *is* an example of vertical tab inside WordPress as mentioned above

        So yeah, I’m now in favor of vertical tabs as long as the styling is consistent with the vertical subnavigation example.

  4. I meant to refer to the sub-navigation on the LEFT side of the newer WordPress in Dashboard help system, not right, in my comment above. That’s what I get for trying to type a long comment real quick on my iPad. My fingers aren’t always in synch with my brain.

    • Marked as wontfix. Oh well, at least we tried… It’s a pity though, since he could have gone with a simple filter or option that would change the layout. Ideally a horizontal layout by default (because it’s WordPress) and a vertical layout on demand (for themes with half a billion options):

      $args['navigation'] = 'vertical';

      However, as I published earlier, it’s easier to create your own reusable controls with the Settings API. Thanks for taking the time to comment Cosmin :)

  5. I completely agree with Carl here! For example: just install the (free) WooCommerce plugin and a few extensions (some are adding new tabs to the horizontal tab section): and you get exactly what Carl is trying to say! It is really user-unfriendly this way.

    I am not saying, WooCommerce does it the wrong way, it’s just so much neccessary settings but with the approach of the above NHP Framework it would be MUCH MORE user friendly.

    The WP Tabs API is great for up to 4-5 tabs maximum. All other stuff is better managed vertically… just like the screenshots above.

    • Hey David, thanks so much for your comment! I think WooCommerce can easily just use their existing submenu in the main (left) WordPress menu, since they’re using a top-level item anyway, it won’t hurt them more than it already does ;)

      One thing I just thought of, if anyone ever wrote an iOS app for the iPhone, they have a tabbed navigation control with five slots for buttons. As soon as you drop the sixth button to the control, it turs the fifth button into a “More…” button which opens up a list UI with the rest of the entries. I’m not saying WordPress should implement the same or a similar UI, I’m just saying that I like the way it works :)

      Cheers and thanks again!

  6. Hi there Hafiz! Thanks so much for your comment. It’s interesting to note how all this “debate” about vertical versus horizontal menus, reminds me of the Ozh Admin Drop Down Menu plugin.

    It has over half a million downloads, hasn’t been updated in a while, but it actually works even with the latest trunk. Not that I like it, just came to mind :)

  7. I came across this framework a few weeks ago and was glad to see the UpThemes Framework as inspiration for Lee’s new option framework. I think our sidebar approach for the design ended up working well but our next major release of the UpThemes Framework features full integration with the Settings API and sticks to the standard WordPress UI. Glad to see some good discussion about these UI patterns though. It’s tough to get changes like this into WP core without a lot of advocates behind it.

    • Hey there Chris! Thanks so much for your comment, I’m really excited to see what you guys can do around the standard UI patterns, feel free to spam me with screenshots, even if it’s work in progress. Yes, the above screenshot and the UpThemes Framework screenshots do look alike. I like your sliders, though input type="number" seems to be the new standard… Thank you for stopping by!

  8. Oh my! A whole blog exclusively about theme options! What a better testament to inadequacy of WP’s API? You guys still manually coding options arrays? In Joomla, you just setup a simple xml file and the rest is done automatically – standard system params on the left and custom params on the right. But if that’s, not enough, one still has an option to custom code everything and make it look as messy as any given WP theme layout.

    Vertical Carl Hancock vs. horizontal Konstantin Kovshenin debate is very exemplary of limited mindsets. Why does it have to be one or the other? Why not a combined approach to better utilize the strengths and mitigate shortcomings of each layout?

    Let’s face it, the preponderance of theme options chaotic layouts is a result of WP’s week back-end support, both for API and CSS.

    • Hello Joomla fan :) I disagree, but I don’t think you care anyway. As for vertical vs. horizontal vs. both vs. diagonal, vs. upside down, I think that it’s all about where the end user would expect the navigation to be, and how the user would expect it to work.

      Anyway, this is not a place to start a Joomla vs. WordPress debate, so thanks for your comment and have a great day!

  9. Pingback: Options Framework Theme | Theme Options Gallery

  10. I did a quick screenshot that shows exactly why the WordPress Tabs UI convention is not appropriate for theme and plugin settings from a UI scalability standpoint.

    At the same time, it shows an existing WordPress UI convention that does. They are both visible on the same screen at the same time so you can seem them right next to each other and why one would make more sense than the other.

    Here is the screenshot:


    I’m not saying do it exactly like the Help as far as the way the Help functions. I’m strictly referring to the adoption of the UI and styling, which is far more scalable for things such as settings.

    Things like this should be scalable so additional settings pages can be added AND so it can take into account hook usage where developers may be adding additional settings page via customizations applied on top of the theme or plugin who’s settings are being displayed.

    One scales gracefully, one does not. The one that does not is the one that is being advocated as the right way. I guess i’ll do things the wrong way.

    • Hey Carl! The main navigation menu on the left can gracefully scale too, but WooCommerce really needs only two tabs on that page — “Basic” and “Advanced” :) Also, I don’t see anything wrong with two or three rows of tabs:

      And no, I’m not a Windows user ;) Cheers and thanks for your comment!

      • Thats great Konstantin, but the Windows tabs scale and stretch so that 2 rows of tabs are displayed so that both rows are a consistent width with the tabs dynamically sized so that things don’t look out of whack.

        The same can NOT be said of the chunky horizontal tabs UI in WordPress. The tabs look terrible when they wrap to a new line, and typically when you see tabs on a web site that have wrapped to create a 2nd line things look wrong. Broken. Bad.

        This is clearly displayed in my comparison screenshot in my comment above which clearly illustrates the scaling limitations of the WordPress tab UI right next to a vertical solution that WordPress already uses that not only scales, but looks much better while doing it, in the Help interface.

  11. This is a great blog. Some really good discussions and opinions to help us decide what direction to go in with theme options layouts. Nice one Konstantin – keep up the good work. And thanks to all contributing commenters.

  12. The top selling premium wordpress themes never have option tabs strung across the top, they are always listed on the left side.

  13. hi,
    I started liking this framework and currently implementing in my site which is under construction.

    I stumbled across one problem with it. I don’t know how to retrieve the array options like multiple select, multiple check boxes values.

    Any help or advice is appreciated.

  14. only just noticed this post. thanks for posting my framework (wait for replies about the tabs, : -) ).

    just thought i would add that you dont need to use the built in methods for getting the options. its a simple array of options exactley the same as when you use the settings api, so:

    $options = get_option(‘option-name’);

    works totally fine as well, the built in methods are there if you need them.

    theres also an update coming soon when 3.4 comes out (changes have been made for 3.4 compatability), this one enhances the tabs feature.

    basically they shrink to just the icon when on lower screen sizes, and hovering over them displays the section name (ala wordpress)

    see here:


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s