Custom designed WordPress options screens need to go


There are more WordPress themes now than ever before, including commercial themes. More and more developers are spending their time and their talents to develop WordPress themes to sell to customers. These are great things.

But a trend that picked up steam, and doesn’t seem to be letting up, is the custom theme options screen. Instead of using the standard WordPress user interface for a given options screen, a number of developers have gone their own direction, creating custom screens with their own design and their own techniques.

This stuff needs to stop.

Most times that I see a custom options screen it is being marketed as a feature to the user. Rather, I would consider non-standard options screens to be far more hostile to the user than they are features worth marketing.

I’m far from knowledgable when it comes to user experience (quite far), and only somewhat grasp what most of these words mean. But I do believe that part of good design is working within the user’s expectations. When something works the way a user expects it to, it’s magic for everyone involved. When magic doesn’t happen the user has to learn something new.

When something works the way a user expects it to, it’s magic for everyone involved.

It’s not that I don’t think a lot of thought and work goes into these panels, clearly a good deal does. However the work has gone into adding something to WordPress that it doesn’t need.

WordPress actually has a standard style for admin screen elements. Multiple admin screens? Check. Upload forms? Check there too. Form elements and submit buttons? Check and check again. When there aren’t standard styles in place for an element, there’s a place to go for that too.

There are other more exciting places to innovate when it comes to WordPress themes and plugins. Don’t waste the creativity on your settings pages. When it comes to admin pages, the points go to those who stick to the standard the platform has already established.

This isn’t WordPress-specific. Do you enjoy when application developers break the standard menu and setting screen designs that your operating system has established? In just about every case, the sign of success for these screens is that theyΒ give you what you expect. Funny enough, when an application goes out on its own and gets creative it typically makes the developer seem new to the platform.

The community is a handful of years into serious WordPress theme development at this point. Let’s make sure we’re interested in maturing our themes as much as we are making more of them.

114 thoughts on “Custom designed WordPress options screens need to go

  1. Ryan,

    Do you have examples of themes that get their options screens right, and follow the standard WordPress styles, while presenting the necessary options in an easy to use manner?

    • Hi Travis. I avoided naming names in the editorial because custom options screens are by far most common, and maintaining the standard WordPress UI is the exception. Off the top of my head, I believe Genesis, WP Framework, and Startbox are a few themes (frameworks, mind you) that do theme options right.

      Virtually everyone else, I would argue, is doing it wrong.

      • FWIW, I will confirm Ryan’s claim – this is a decision that Nathan and I made when we started building Genesis, and one we certainly don’t regret.

      • I may be biased here… but when you build a system, and you force that system into someone elses’s constraints, you’re no longer building your system. You’re smashing squares into triangle-shaped hole.

        Should the user interface, and how things work, be similar?


        Does it need to blend into the rest of the WordPress backend?

        Absolutely not.

        (P.S. Your custom comment system, with bold, italics, and del, and link, and all those cool options, does not look right on chrome or safari. Funny how that works, heh)

        • Thanks for pointing out the bug Derek, it should be fixed now.

          Regarding systems and constraints, I suppose I go the other way. If you’re building something within another’s ecosystem, it’s usually best to abide by the UI standards of the ecosystem. I would related building theme settings screens to following standards for settings screens when building a Mac or iPhone app. In those ecosystems following UI standards (for app settings, though arguably elsewhere too) is regarded as the professional expectation. I think of WordPress in a similar way.

        • I get the idea of building a system, and wanting to (somewhat) brand it inside the WP UI. Even though Thesis has it’s own unique style, it’s not far off from the way WP handles default UI. My guess is that the post is aimed more at folks who radically brand every element of their options pages. In other words, for the people who dress in grunge and are trying to attend formal dance. They stick out.

        • I completely agree, and I’ll add that WordPress has these best practices in place for more than just ease of use. If you speak the WP language in your code, your theme will never break with an upgrade. Who’s to say your custom coded image upload box won’t conflict with code introduced in the next version? You can take the already existant media uploader and tailor it to your needs. And it’s something WP users know how to use because they use it everywhere else. Done.

    • I think you better try out themes by woothemes. They are filled with custom settings pages. Sometimes it’s useful but some parts of it are just too like it doesn’t belong. It makes me feel that the theme like software. Everything is there including SEO. Just try for your self. There are couple of free theme in woothemes. I honestly love their work but the settings pages not so much.

      • I’ve dealt with several premium WordPress themes in my time and I, too, had problems with their options panel. Wasn’t sure if it was my lack of knowledge or just a usability issue on their part.

        I think creating custom options panel is a part of the prestige and marketing game. It’s like buying a new car and putting a “third-party” fan inside, with your name written on it.

    • I would offer my own Theme, Oenology, as an example of a Theme that has gone to great lengths to implement settings – both using the Settings API in the back-end, and integrating core WordPress settings UI in the front-end – using current best practices.

  2. +1 I think most themes that justify their own options page have too many options in the first place.

  3. I just figure custom option screen styling is too much work. Why worry about that when there are default styles that work just fine. I’d rather spend on my time developing useful features.

  4. Been saying this for a long time. Here’s my thoughts:

    1. Theme Options screens need to be simple. Use the standard UI elements. Use the Settings API if you have to. Don’t include ridiculous functionality. Example: I’ve seen themes that have a box where you can type in text to customize the footer of the theme by putting in one of a dozen shortcodes specially understood by the theme. I mean, how is making your user learn esoteric shortcode stuff any easier? A theme options page should contain no more than maybe a dozen input elements, and virtually none of them should be a textarea. Examine the custom header and custom background screens.

    2. Make the options page about ONE thing. Examine the custom header and custom background screens again. Notice how they’re short, simple, easy to understand? Your theme options page should be like that. If you need to make multiple options items in the Appearance menu to separate things, do so. Should be no more than 4-6, max.

    3. If you don’t want to use the Settings API, that’s fine. But at least use set_theme_mod and get_theme_mod. This avoids all sorts of problems, it’s fast, it’s easy, it supports sane defaults, etc.

    4. Speaking of defaults, NEVER SET DEFAULTS IN THE DATABASE. Not ever. The theme options you store in the DB should always, always, *always* be something the user has selected. If the user selects the default, then that’s fine to set in the DB. but you don’t set it in the DB just because it’s not set at all. get_theme_mod has a second option for the default value. So does get_option for that matter. Use this.

    5. Finally, don’t make an option for every blamed thing on the whole site. Seriously, the user of your theme wants it to work, they don’t want a frickin’ NASA like control panel to operate the thing. Most thing in a theme should NOT be customizeable. If the user wants to customize something esoteric, they can make a child theme and learn some minor coding. Code for 90% of the users and let the other 10% change the code to suit themselves.

    On the whole, it’s not hard to create beautiful and easy to use designs. Just think simple = better and you’ll be fine.

  5. Thank you for saying this.

    Any theme developer who is creating custom settings screens and not sticking to the standard UI is doing a disservice to their users. Big name theme developers who are doing this are doing a disservice to the community as a whole by perpetuating this trend.

    It’s really not that hard to stick the standards. I guarantee it will cut back on development time tremendously, allowing theme developers to spend much more time building other useless “features”.

  6. Couldn’t agree more, even though I have been guilty in the past of doing it the “custom” way. I will for sure adhere to the standards in the future, no question about it πŸ™‚

    • I have to second this. Clients I have worked with freak enough when new functionality and options are introduced via plugins etc. but when it looks out of harmony with what they are already used to it just exacerbates the situation.

    • Even more — it confuses the heck out of the ALMOST-new user. The one who’s gotten far enough to have a feel for how WP looks and behaves, but doesn’t really know what’s going on behind the scenes. In other words, exactly the sort of people who are ready for some customizing and tweaking beyond just what they started with. Sigh.

  7. Amen. More reasons the WP Plugin Dev book rocks – a whole section on integrating into WordPress and making use of the native UI πŸ˜€ Just as useful for themes as for plugins!

    • Awesome! A plug for Pro WP Plugin Development!

      Ozh put some awesome work into the settings chapter, which covers properly creating settings pages in great detail. It’s definitely worth a read for theme developers.

  8. YES! We desperately need a standard options screen. I’m tired of spending two hours learning each authors’ custom admin every time I download a new theme.

    • Second that. I’m traumatized by custom admin panels that cost more time figuring out then if I would have built from scratch. I’m finding myself hesitant now when purchasing themes.

  9. I tend to be an extremist on this particular idea, as in I do not think Themes really need an options panel; but, I agree with the overall commentary that if an options panel is to be built into a theme then it should be using standard UI components and leveraging the Settings API.

    This editorial and the comments coming forward is one of the major reasons the WordPress Theme Review Team strongly pushes for the Settings API to be used for all themes submitted to the Extend repository.

  10. I’m not agreeing with this Ryan πŸ™‚ In fact I think WordPress is doing an absolutely horrible job at keeping things organized and in the right place for a casual user to manage. You can build a theme options panel the “WordPress Way” without trying to interfere with the way WP does it, but here’s what happens:

    Custom background: Set this on wp-admin/appearance/background
    Logo Upload: Set this on my My Theme options page
    Header BG: Set this on wp-admin/appearance/Header

    If your theme or install also needs plugins like social sharing buttons or forms you have those put in different pages as well. How can someone new a WordPress make any sense of this? It’s a mess! If you’re running a MultiSite community and have all these options screens all over the place for your themes, you will have a support nightmare. Trust me.. I’ve been there πŸ™‚

    Theme Options panels are made by theme developers because it greatly improves the usability of the theme. People should be able to manage everything related to their front-end appearance through one options panel. If this option panel is organized properly, the user knows exactly where to go if something needs to be changed to the front-end of their site.

    Do these themes sometimes contain an overload of options? Absolutely… are some of them organized in such a way that they still make thing confusing? Probably.. But Options Panels itself are absolutely essential for someone who just wants to be able to manage, edit and customize their front-end appearance easily.

    The biggest issue a lot of themes have though, is that sometimes you don’t even want to have all these options. You love the front-end but feel that 80% of the options are either not useful, or are not meant to be changed for your client. They are overkill and add another layer of complexity to the admin panel, that you (or your client) confuses. Ideally, as a developer, you would be able to enable and disable sets of options that are related to a feature (like disabling all the options that are tied to the Header customization, or social buttons).

    Me and a buddy have been working on a theme that has a custom dashboard which allows you to do exactly that, and gives developers the ability to add, remove and extend upon every option/theme feature. This means if you want to disable a feature or options you can easily do this through a config file. You can also add new options like an uploader, color picker to it. All the options are neatly divided into features, so it’s easy for the user to find what they are looking for. To make things even easier a developer can easily attach docs to any option.

    All of this also works for child themes, so you can disable options or entire features from the parent theme for a certain child theme in your network only. We’re launching the theme called Infinity pretty soon as GPL, and it would be cool if you took a look at it Ryan, and hopefully you like the approach we’ve take regarding the entire theme options situation πŸ™‚

    There is absolutely room for progress in this regard, but currently doing it the “WordPress” way is absolutely not the best way to make this stuff easy for the casual user!

      • Sure that might be right in a lot of cases.. also because you’re forced to use the setup that the developer has set. If this setup does not match your requirement you’re screwed πŸ™‚

    • “Logo Upload: Set this on my My Theme options page”

      No, it should be on wp-admin/appearance/Custom Logo.

      If you fit things in with the existing UI, then it’s not confusing at all. It’s much simpler.

  11. I like that theme developers have given thought to providing options for the technically challenged (like me) and in providing DYIers with the ability to make theme customizations without being a developer. But it is also annoying to use a theme that has too many options or that convolutes the admin area with “custom bling”. This is just one reason I love working with Genesis and Startbox. They keep it simple.

    People want options but that doesn’t mean you should give them endless ones. Plus I would rather dig into learning better platforms/frameworks over figuring out NASA designed control panels. It is getting out of hand!

  12. There is something that you are ignoring…. Theme buyers want options, even though they don’t need most of them, for some reason or the other they want as much pointless input boxes as the can have, just in case they may need!

    • So put all the “pointless input boxes” as you want – just implement the standard WordPress settings UI, rather than rolling a custom UI. This editorial isn’t so much about having too many options, but rather about how those options are presented to the end users.

  13. are you saying the theme options panels should be out done with alltogether? or just theme options with their own custom “styles” like modifying css etc and keep the default?

    i see no problems with keeping theme options the default style as the rest of the admin.

    • I certainly don’t mean to say that options in general should be done away with. Options for themes have their place (although that is another discussion worth having).

      Here I’m just talking about options screen user interface, and how many most create their own version of it, rather than following the WordPress UI standards.

  14. While I do agree with the general idea of the concept not everything can be integrating using just the default styles. Why? Simply because there are better ways to do it.

    I’m talking here about plugin dev. I don’t want to pollute the menu with a top level menu item and multiple submenus when I can create a tabbed navigation and have all the settings there. The alternative would be to have a huge page with boxes and inputs.

    What we need is UI guidelines for stuff like drag and drop, multiple tabs, multiple columns integrated in the core or a core plugin for demo. Simply put you can’t do everything with the default styles or should I say there are better way to do it UX wise.

    • First: the standard WordPress settings UI includes tabs. So, if you need tabs, use them.

      Second: if there’s a “better way to do it UX wise”, then why not get involved with the WordPress UX team, and get those improvements directly into core, so that everyone can benefit from them?

      That brings up another reason to implement core UI: when such improvements are made, if a Theme has implemented its settings page UI consistent with core, then those improvements automatically propagate to the Theme.

      • I couldn’t agree more! Let’s improve the UI together, from the ideas of those of us who develop new themes/plugins. Thus everybody can benefit from UI improvements.

  15. Everyone wants their own framework. An epidemic that is only getting worse now with custom “content builders” and such.

    I know a lot of theme developers (myself included) are using the Options Framework plugin by Devin Price. It’s a great solution for adding unobtrusive theme options to your theme while maintaining the aesthetic feel of the WordPress admin menus.

    Personally, I try to code my themes to have as few theme options as possible. This prevents me from having all the (often unnecessary) bells and whistles that some of these cracked out options pages have, but it’s much easier on my customers in the end.

    Another thing to consider is options dependency. If the user ever wants to move past your theme and try another (which they always do), it’s nearly impossible for them to easily do so since you required most of the site be setup in YOUR options panel or custom content builder.

    Definitely a lot of work to be done to standardize the theme options process.

    • I disagree. The Options Framework does not follow the rest of the WordPress admin UI. It was actually based on the custom WooThemes options page. It does use some of the same colors as the WordPress admin, but the page layout is definitely custom.

      • The Options Framework does not follow the rest of the WordPress admin UI.

        And therein lies the problem.

        It was actually based on the custom WooThemes options page.

        Check that. Therein lies the problem.

      • Hey Mate. It sure is nice. Why did you use those big ole ugly tabs as opposed to the tabs in the Admin > Appearance > Menus page? I think that the tabs on the Custom Menu page seem to be more inline with the new WordPress 3.2 look and feel.

        Would love to know your thoughts :))

        • Core has four different ways of doing tabs or sections that I’ve seen:

          /themes.php (tabs at the top)
          /nav-menus.php (tabs attached to menus metabox)
          /plugins.php (text links at top)
          /index.php (dashboard meta boxes)

          I decided to go the tab route, though I think metaboxes could be equally nice.

          The tabs in nav-menus.php and themes.php use the same class “nav-tab”. However, the tabs in nav-menus.php get their appearance from being a descendant of #menu-management, whereas the tabs in themes get theirs from being a descendent of an h2.

          This indicates to me that tabs in the menu management are a more specific implementation, whereas tabs in an h2 are a general implementation. I also think it looks better, though that’s obviously up to interpretation, :0.

          • Devin, you made the right choice with the same tabs from the themes page. Dan, it doesn’t have to do with how it looks, the decision should be based on smoothing out the user experience by following core’s lead.

            The text links (plugins.php, edit.php, etc.) are not for separate screens — they’re filter links, and they’re always just filtering the list of objects in the table. They don’t switch out screens. The menus UI is a unique situation, but either way, it’s switching out a single UI element, not entire screens.

            Meta boxes are not used to divide a screen into sections visually. (An exception would be the Link Manager, which is very old and shouldn’t be used as a guideline.) They’re designed to provide flexible layouts for the post and dashboard screens.

            So, the only choice for this would be the tabs on themes.php — these switch out related screens. You made the right choice and I’m thrilled to see an options framework move closer toward core UI.

          • Thanks for your feedback. I appreciate your thoughts on this, totally glad to hear you say that the metaboxes could be as equally nice, especially if there are lots of tabs.

            And I agree with you about the H2’s, they do look nice in WP 3.2, I think the overall design for those tabs has been tightened up a little since those tabs were introduced in earlier versions of WP πŸ™‚

          • Most excellent!

            Thanks for sealing the deal Nacin. Up until now, in fact the second you clicked Post Comment, I don’t think there was an official stance on this. It was at the very least visually open to interpretation, and since I think a lot of people work on a visual level, then you can understand why it was open to interpretation. So its nice that you’ve made it clear what people should do. Ka Pai!

            p.s. I still like the look of the meta box tabs though, not that I think it matters what I think, since the goal is to align any Plugin we make with WP core πŸ˜›

  16. Wow. It’s amazing how many people seem to be commenting on the title of the post without having read it.

    A summary of this post would be:
    1) Nothing is really said at all about whether adding an options page for your theme is a good idea or a bad idea.
    2) If you do include an options page (or multiple options pages) for your theme, use the UI that’s built into WordPress.

    I couldn’t agree with you more, Ryan. It can be a bit daunting trying to integrate into the native WordPress UI at first, but once you get the hang of it, it’s well worth the initial time investment. When I use the native WordPress UI and the settings API, I know that my options pages will continue to fit in with the rest of WordPress, and that they will even keep up with custom admin style changes (if any users choose to make those). For instance, the backend of WordPress 3.2 is going to look a good bit different than the backend of WordPress 3.0-3.1.x. All of the plugins and themes that use the settings API and/or the native WordPress metabox API will be automatically updated to continue matching the look of the rest of the backend.

    It just makes good sense, for the most part. Are there instances where a custom UI might be necessary? Probably. Are those instances as prevalent as custom UIs are in plugins and themes? Not even close.

  17. Another vote for using the standard UI.
    However, I’d like to see some talk on useful resources for getting started with theme options that are more native.


  18. I looked at the options panel in Thesis the other day… so many square buttons I thought I was looking at a soundboard.

    I seriously had to take 3 minutes to read everything and get my bearings. Took me another 10 clicks to figure out which one I actually had to click on to change what I wanted.

    Now *that* is a fail.

  19. As a theme designer ‘wannabe’ I can’t imagine not being able to use the woo options panel, or themify for that matter. Do I wish they looked the same as the default WP UI? Not really, never really thought about it much. I suppose a point can be made for a uniform looking back end, but I have yet to ever have a customer complain about it. Frankly most if not all love the custom options panels.

    I suppose that in a perfect world, they would look the same, but until someone shows me a tutorial where I can replicate all of the functionality provided by either Woo or Themify, I’ll stick with them. I don’t think they are the ‘problem’ but the solution. It is so much easier for me to add in or remove new user options to the panels than it has ever been using the wp system.

  20. This goes without saying. A lot of the time, my decision is based on the admin scheme, and whether or not it’s that beneficial. Do you believe there will ever be a standardization for the platform?

  21. Oh, I don’t think it’s what developers want to do – I think it’s what they feel they have to do. When WordPress makes it as easy to create custom options as plugins like OptionTree do everyone will gladly take advantage of that functionality and forget those plugins ever existed. But until then those plugins add great value for developers by cutting out the cost of doing it themselves. Who cares if WordPress has built-in CSS styles for their UI? That’s not the issue. It comes back around to what we’ve all been saying for years – WordPress should release its death-grip on the idea of being the world’s foremost blogging software and get in the race of being the world’s foremost CMS.

  22. I don’t have a problem with custom options screen. I have a problem with option OVERLOAD! Custom options screen is user-friendly to some extent as long as everything is clear and concise.

    I believe WooThemes was one of the first to do this. Having everything organized in custom tabs is a brilliant idea. Now when you make each of those tabs extremely long causing a theme setup to take more than 15 minutes, then we’ve got a problem.

    Folks can divide it like how WordPress does it: Custom Headers Panel, Custom Background etc… but why do multiple pageloads when it can all be done via jQuery tabs?? Perhaps SPEED can be one issue, but I believe its a minor one. Or they can even take the Genesis route, but for beginners its not the most ideal. Having too many drop down widgets is not the most organized way.

    It would be nice to see if WordPress default styles actually has some way of doing multi-tab display that matches the whole UI while keeping the structure of WP Touch Pro or WooThemes options panel..

    • I’m with you. I’m fine with an options panel and sometimes even prefer it (as long as the panel isn’t overriding or needlessly duplicating a setting found elsewhere — that’s just annoying), but options overload is a huge problem.

      I know it’s popular to think that offering a drop down menu or a selector for every conceivable option means that the user has the ultimate choice and flexibility, but to me, it just says that the designer/developer didn’t know enough about what he or she wanted to do and is trying to get away from making a strong decision about the software.

  23. Interesting post! I am certainly not a big fan of custom UI elements within a system that already has a well thought UI and a team working on developing a homogeneous and instinctive interface.
    But you gotta admit, they can’t think of everything. There are so many things you can do with WordPress, and there are so many new ideas coming out every week, the UI team just can’t follow. I can’t imagine how the UI could fit to everybody’s needs.
    So why not taking the problem the other way around? Yes, custom panels are not the best solution. So what is it that the theme developers can’t do with the existing UI elements? What is it that the UI team could develop to propose the tools theme devs need? I am sure there are lots of potential great ideas to improve the UI out there.
    Let’s gather ideas, propose to theme devs to bring their concerns to the UI team, instead of telling them to fit their new ideas into the existing UI shape.

    What do you think?

  24. I try to combine it a little. I like the jquery UI stuff so I made a ui theme that matches WordPress in style.
    Can make more extravagant options pages/, plugin UIs and still match the overall feel of WordPress.

  25. The reason theme and plugin options screens are so diverse in WordPress is because there aren’t standard functions for outputting the actual options html.

    If you haven’t built out an options panel before, “A Sample WordPress Theme Options Page” by Ian Stewart is a great example for how its done . I also paste-binned the code over here if you want to quickly see what’s involved.

    Currently a developer if forced to do something like this in order to output a simple text option on an admin page:

    <input id="sample_theme_options[sometext]" class="regular-text" type="text" name="sample_theme_options[sometext]" value="" />

    Notice that this leaves all this html in the hands of the developer (Oh, and the lovely tables! Has this changed in 3.2?)

    If there were built in methods of registering different options we would see much more uniformity here. Developers are generally a lazy bunch and don’t want to write code if they don’t have to. I really like the direction Ptah Dunbar took with WP-Framework. Here’s a link to the code that sets up options for the framework.

    Instead of writing a bunch of html to output, an option is set up like this and the correct html automatically outputted (and the options registered):

    * Register an option:
    * Options get registered to a metabox. Once you've registered a metabox, you can now register an option under that metabox.
    * wpf_add_option( 'general', 'option_id', array( 'type' => 'textbox', 'label' => __( 'This is a sample textbox', t() ) ) );

    I took a different path with the Options Framework Plugin– but its the same basic idea. Create an easy way to register options and don’t force anyone to muck with the html.

    Developers (and front end developers) really don’t want to make all this stuff themselves. Let’s create some easy hooks and functions for making options pages, and most options bling will disappear.

    • If one fully implements the Settings API, then no need whatsoever exists to write HTML tables. Calling do_settings_sections() handles all of that dirty work.

      In Oenology, I originally output hard-coded the form-field markup in explicit add_settings_field() calls for each of my Theme options; but in Version 2.0, implemented a loop so as not to have to write repetitive form-field code. It’s probably similar to what Ptah Dunbar has done, as you referenced above. All of my add_settings_section() and add_settings_field() calls are dynamic, as is all of the user-input data sanitization/validation. Here are the guts of the functionality.

      All it really takes is a bit of pre-planning – which, really, should be a prerequisite for any Theme settings implementation. And as I’ve said before: if I can learn how to do it, then anyone can.

      Is there a way to standardize all of this, and somehow add it to the Settings API? I don’t know how feasible it would be, but the idea is interesting.

      • The dirty work I’m referring to is like what you have in oenology_setting_callback. The actual looping and outputting of html inputs, select buttons, uploaders, color pickers, etc. There’s also a lot of sanitization to manage.

        Even though there’s great 10 page tutorials out there for this sort of thing , it seems like there’s gotta be a simpler way. Helper functions to set up tabs, create fields, etc.

        Again, I’d take a closer look at what Ptah has done. With 10 lines of code that simply define the options and everything is taken care of to create a theme options page and meta boxes. Same thing by defining an options array in your theme if you use Options Framework.

    • I do something similar in my AoiSora framework.

      //register_settings('optionname'); store options in array with key value pairs.
      'thumbnailWidth' => __('Thumbnail width', 'plugin')
      ,'showCategoriesFrontPage'=>array(__('Show categories on frontpage', 'plugin'), 'checkbox')
      ,'color'=>array(__('Default color scheme','plugin'), array('dropdown'=> array('blue'=>'Blue', 'orange'=> 'Orange')));

      • The main difference for me (aside from not using a Class) is that I don’t put all of that static content into the DB; rather, I just store it in an array function (from which I also pull my defaults). The only things that go into the DB options array are associative $key => $value pairs.

    • You’re overthinking it.

      Is the Settings API excellent? No. There’s lots we can do to make it better. But using it is far better than not using it. Especially given what many themes are churning out, which is best described as muck (insecure muck, typically).

      Have you ever looked at the settings sections/fields aspects of the Settings API? I’ll be perfectly honest, Twenty Eleven doesn’t even use it — and I’ll take the blame for never getting around to it, but expect it to happen in a point release of Twenty Eleven — but it’ll code up the table markup for you, without you ever typing a table/th/tr/td tag. Check out this slidedeck from Mark Jaquith for the basics.

      The table markup will go in 3.3. If you’re using the settings sections/fields bits, you’ll get the change to divs and CSS for free. One more benefit to using the core API.

      Often I’m asked why WordPress doesn’t have a form/input builder API. Because we already have one, and it’s called HTML. HTML is not a programming language. It’s a semantic markup language that is universally understood by those who work on the web and don’t use Frontpage. When you start to reduce basic markup into a specific programming syntax, it gets much more complicated for developers to understand what you did. Keep it simple. Copy and paste even just the slightest bit. The world (at least the developers thereof) will thank you.

  26. I get what you are saying about custom styling of themes and not using standard wpress form elements, but the problem with the rest of your argument, is it assumes the standard toolbox given by WordPress is good enough. It isn’t, and it is far from it.

    1)Users like options, they like being able to change aspects of the theme without delving into the code.
    2)There is no inbuilt decent way to build an options panel. To do so you must jump through extraordinary hoops, seriously – its ridiculous. People will use the common (non standard) options panel frameworks because it is easier, quicker and better by a looong way.
    3)In no way (on this earth) is it better to have a user have to go into an image editing program just to identify what color a hex code looks like. There is no inbuilt color picker in wordpress, can you seriously be suggesting it is more ‘user friendly’ just to have a text box? :O Or should premium themes not let users adjust color?
    4)Tabs and ajax saving are all huge usability improvements over the WordPress default. Less page refresh = waiting less time = better for the user.
    5)Remember that nifty menu manager that is now part of the core? (it has its issues ofc, but its better than nothing)
    6)Premium themes are sold via marketplaces that cater to the wants and needs of buyers. Buyers are users. They are voting with their wallets. Users want to be able to change things from the admin, and not wade through code to do it. If they didnt, why are they buying these themes?

    • Yes, the point is that WP UI is very, very limited to make comprehensive options panels for themes or plugins. And the fact is that users WANT options when they buy themes. I wanted to have less options for my themes, but than I got emails and requests for more and more settings allowing easier interaction with the theme. Users want to change colors for some elements, to use color pickers, they need easier way to do things. Also, some features I have in my themes can’t be implemented using normal WP UI.

      AJAX should be used for all panels, and WP doesn’t use it for own panels, they are far, far from completed for custom use. I like the idea of standardizing interface, but right now WP lacks many, many standard controls to make easier to use interface panels. Look at WP options: you have 5 or 6 pages, that can be a single page with 5 or 6 tabs using AJAX to save everything. I recently made something like that for a user who needed easier way to handle WP options: one panel, tabs and saving with AJAX. WP UI is far, far from completed when custom use is in question, and until we get everything need for UI, very few themes and plugins will use WP UI.

    • Like I wrote higher up. I use jQUery UI theme to style all my custom stuff so they have the same feel as the rest of WP UI. Then you can combine easy development, much more advanced tools and UI conformity,

  27. Right on time and lots of great comments, I definitely would love to see more devs using the built in settings UI. I tweeted about this before, hoping to encourage others, hopefully this post will be an eye opener for those who are not aware. Great post Ryan!

  28. This is a progression we’ve begun to make over at UpThemes. I don’t think having a custom theme options panel is an atrocity, but why not at least use the WP standard functionality for theme settings and image management? Rather than introducing your own code that then needs to be maintained separately, you can build on APIs that already exist and will exist forever. The extra time needed to write a ton of custom code and the overhead of maintaining that code just isn’t worth it to output your basic theme options.

  29. An interesting debate: to option or not to option. As many of you have already stated, an options panel can be useful. But as a wordpress developer over at FuruThemes, the heart of the argument, or at least what I gathered from Ryan, is less about the usefulness and more the growing trend of panels not using or resembling any part of wordpress’ core.

    Truth is, developers need them. Well, now, that is a half-hearted truth, because we don’t need them for much and what I see in Wordress dev is almost an attempt to show it off what can be done within it rather than focusing on the panel’s ease of use and integration with the system. Case in point, a basic uploader. I have seen countless themes integrate an their own uploader when wordpress already offers one. Or, the need to add color changes and tons of stylesheets as though wordpress doesn’t allow any admin level user to change CSS directly from the backend.

    With that said, when developing, there are tons of things that cannot be accessed within a wordpress loop or from post-specific custom fields. This is where the options panel comes in handy. Everything else, friends, just overkill…grease-fried overkill.

    Either way, having a CMS that puts us all in knowledge group to enjoy such a debate (looking at you Joomla), is pretty awesome. So, party on Garth.

  30. Hi Ryan, It’s just a request, if you can please also integrate a Poll System in these kind of blogs so that we can see results faster apart from reading long list of comments (it’s not like i am saying reading comments are boring, but still when you are in a hurry it’s better to see results or you can say numbers are sweet) because every time we come back to read, the list is grown up more & it’s difficult to catch up where we left.

  31. There is a Codex page for Theme Options. It’s a placeholder right now that I created so that the contextual help tab for Theme Options in Twenty Eleven would have a specific documentation link. Additions to talk about best practices would be welcome.

  32. Ryan,

    Quite simply I disagree with almost every tenant of your article, and most especially your statement “This stuff needs to stop”.

    Creativity and diversity have been key elements in the growth of wordpress. You might like everything standardized and transparent, but many don’t. Custom option panels help developers and users, and if you don’t understand that, then it truly suggest to me that you have not had much interaction with business customers who have no interest, and do not under any circumstances, desire to learn the necessities of coding necessary to perform the functions custom options screens typically achieve.

    This is yet another article I have felt compelled to comment as it once again seemed quite self serving by a portion of the develop community determined to keep the gravy train rolling on custom work from clients.

    • I don’t have any problem with custom options screens themselves, only that they seem to (more often than not) strike out in new UI directions that just aren’t needed or helpful.

      Creativity and diversity are fantastic, and I don’t mean to say otherwise. I only wish the creative efforts were put toward something other than reinventing what is already a solid WordPress user interface.

    • You know, usually it’s helpful actually to read the article before commenting on it.

  33. Nice post Ryan.

    If you are making a Theme or a Plugin that needs more then one page to accomodate all your settings, like many do these days, then the best tabbed menu approach would be to mimic / hook into the tabbed menu styling that comes free with WordPress. More specifically the styling used at the top of the Menus page in the WP 3.2 admin.

    Surely the best approach is to utilize what comes with WordPress – tabbed menu’s have been a problem up until now because before Custom Menus WordPress did not use tabs.

    I think it could should look something along these lines:

    Food for thought πŸ™‚

  34. I totally agree with the point you are making here. When I first started learning themes, I was (like alot of novices) impressed with slidey movey rounded, etc. So I did all kinds of whacky crap in my theme options, because I could. Like I was showing off to myself or something. Then I realized that I hated when a plugin or theme didn’t follow WP UI conventions….. it felt like I was kind of ‘jarred’ from the WP experience. Even if it was tastefully done, it didn’t feel like it fit in. Then I realized I was guilty and started revisiting my options. Options are great if you need/want them, but keep them within the WP UI, make it feel like you are working with the WP panel, not fighting against it.

  35. Custom Theme Options pages are here for now, but like with a lot of WordPress development they have been filling gaps in the core functionality. Another recent trend is the rise of the drag and drop page builder – they’ll be everywhere soon and there won’t be standard one either. Even though I’m sure the widget system could meet this need if it was improved.

    Generally though, I’m finding themes need less options than they used to. With widgets, menu builder,post types and meta boxes there are better ways of incorporating functionality than there was a couple of years ago, meaning less is required of theme options. Still a long way to go but people are doing all sorts of cool stuff with WordPress – often when something else would do it much better.

  36. I think an issue here isn’t so much with the theme developers but with the buyers. A lot of buyers are looking for overall quality when it comes to themes, by having a very well developed/designed admin panel it shows that the author cares about overall quality and not just basic functionality.

    And in no means are all buyers equal…

    Ultimately though, what most sellers are thinking is… “what sells?” And whatever sells is what they are going to do.

  37. I feel the same way about these overwhelming, custom interfaces as I do when I see similar treatment in iPhone apps.

    Apple is a *very* bright company, and has poured countless hours of effort into creating a user interface style that is clean, crisp, attractive, flexible, and very usable. When someone messes with the interface elements, or worse yet creates their own, it’s the same problem.

    You work against the end user when you force them to learn different styles of UI. That’s a bad thing in WordPress, and it’s alarmingly prevalent.

  38. I’ve seen some really nasty and confusing theme options panels – these should die quickly!
    I’m all for standardisation about how theme developers approach this. I think developers should also be free to innovate and come up with new ideas and innovations on top of the existing UI standards.


  39. Pingback: How to load JavaScript in the WordPress admin

  40. I’m late to add my comment here, but I totally agree Ryan.

    But it’s all EGO. Vast unfathomable depths of ego on the part of these premium theme and plugin companies that want to do things their way.

    It won’t stop. Unfortunately.

  41. I’ve been thinking a lot about this post recently…

    I simply don’t know how you would accomplish all the theme options great themes offer without custom option screens? What are your recommendations for where to place content like this?

    For instance, the management of custom color schemes, dynamic side bar creation, etc…

    Many things do have places, like layout options for pages/posts (widgets on the edit page), but what about global changes? Where do you want to see these feature options located?

    I subscribed to this comment’s responses. I would love to hear from you.

    Thank you for an awesome site!

    Ellis Benus
    Small Business Web Guru
    [email protected]

    • Ellis,

      The post isn’t saying that Theme Options pages themselves shouldn’t be used, but rather that Theme Options pages shouldn’t be creating their own custom UI. The point is that Theme Options pages should be using the core-provided UI, wherever possible.

      • Good point. I guess I was throwing out the baby with the bath water. πŸ™‚

        This is definitely something that I’m going to take under heavy advisement for my own custom work.

        Just a check to consider, could this be put somewhere in native WordPress?

        That will be a great question for force myself to consider each time.


  42. I totally agree with the point you are making.
    We are developping a simple wpmu network and we would like to offer to our clients the same
    simple option panel for all the themes available in the network.
    Problem is that we are not able to use premium themes because of the complexity and heterogeneity of option panels.
    In the case the developper licence allows any modification of the theme, has anyone tried to bypass the theme’s option panel and use their own panel?
    I wonder if that’s possible with the option framework plugin ?


  43. Pingback: WP Admin is an Experience too | Noel Tock

  44. Totally agree with this.
    Recently i’ve been taking on a lot of work where sites and their owners have outgrown a stock theme they’ve purchased and now want something custom or fancy a few changes to the current template.
    Many of these changes could have been made using the themes options but these have been hidden away in their own section and for what reason?

    WordPress has an awesome system in place so i never understand why some developers go out of their way to smash it to pieces.

    Of course i’d never go as far as to call for WordPress to lock things down but the developers who commit these types of wrongs need to know it’s a pointless task and then nudged in the general direction of some admin UI guidelines πŸ˜‰

  45. Pingback: WPCandy’s Completely Unofficial Guide to Plugin UI | Theme Options Gallery

  46. This is the tug of war that happens with open source and commercial products that build products on top of open source. You’ll probably notice that the worst offenders are typically commercial theme/plugin developers (with some exceptions) because their goal is to essentially build their own commercial platform on top of an open-source platform. I’m looking at you WooThemes and the likes. They don’t want to blend in because they are trying to build their own platform and set of loyalists because it makes it harder to switch for the user. Now, maybe this is not intentional and they just have some designers that want to dress up their options screens and leave their creative mark on a theme or theme framework, but I would venture to say this IS an intentional commercial and capitalistic decision by most.

    I have found that some of the best adherence to standards is in free plugins/themes mainly because of it’s a matter of necessity – they don’t have the time or desire to reinvent the wheel when it comes to their theme or plugin options screen(s), so they use what the framework (WordPress) provides because it is both convenient and necessary from a time and resource perspective.

    While it would be nice to have iOS-like adherence to standards, that enforcement comes at a great cost to Apple to act as a gatekeeper to every single app submission made to the app store. The same could happen with WordPress themes/plugins, but it would require a huge commitment from the open-source community or a commercial entity to curate themes/plugins based on adherence to WordPress standards which would introduce cost to the users of WordPress, theme and plugin developers, or both.

    Food for thought…

  47. I see this “discussion” has been going on for a while!

    I have bought 6 different Custom FRAMEWORKS over the past two years from some “respected” developers. Their installations allow Real Estate sites, Classified Sites, Product Ad sites, etc. One installation of WP on one database by one site owner. All of these Frameworks are built on the Registered Memberships model. The last one I have tried for Real Estate types and categories gives each Member the standard Author Role to Add their Posts and Edit their own posts.

    The Custom Admin “screen” for this and all these other Frameworks is simply a stripped down Form. Content is created with a stripped down text editor. The User Management views are just form views for Members with Author privileges.

    However, the frustration for me is that I want to give Members more Post options that come from Plugins. These plugins are in the minority compared to most plugins which interface with the Admin or Super-Admin ONLY. The plugins I want to “embed” into my frameworks are those few that give MEMBER OPTIONS.

    For instance, a Booking Calendar that is designed to allow Post Authors to create their own modified instances of a booking or Availability Calendar for the Real Estate framework in the Rental type or category of post. In the default Twenty Twelve Admin screen for these Authors the lefthand native menu column this plugin name shows up with sub-menu links to Options and Settings. The plugin sees Authors and assigns a “manage_options” capability to Authors.

    Now each Author can use this Menu to make their own Calendars with different days selected for different states “Available, Booked, etc.”. They save their instances while logged in to Administer their own Posts.

    Then, in the WP default Admin view the select a post and will see, in this case, a dropdown selector installed above the Text Editor. Selecting one of their own Calendars from the list generates shortcode to the Content which is viewed by the outside End User.

    Custom Admin Screens destroy this environment. They are glorified forms designed to parse out the “barebones” view to a Registered Member. They have no provision for passing along the customizations that User plugins can provide.

    While people are discussing these developers going off on their own, why haven’t the WP core developers simply made a class or classes that any framework can use in their functions or forms that passes along the full editing environment inside any framework?

    One comprehensive Class wrapping up all the functionality of WP UI core with a one line install/require once into a Framework?

    Perhaps it is like an IFrame but whatever it is it ought to be so simple for a framework to inherit all the capabilities of the WP UI, yet, style it for their own look and visual design.

Comments are closed.