Themes and the WP Settings API

The Settings API was initially introduced in WordPress 2.7, and is incredibly powerful. Part of its power is its automation of settings security (nonces, etc.), as well as automation of most of the admin options-page generation. Thus, use of the Settings APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. helps ensure more robust data security and more consistent user experience.

Unfortunately, it doesn’t seem to have met with much widespread adoption in Theme development. Granted, very little documentation exists for proper implementation of the Settings API, and thus the learning curve is somewhat steep. To that end, Otto has an excellent tutorial, and Press Coders have a great write-up as well.

I will be adding a Theme-centric Settings API tutorial to my to-do list. Given the increasing exposure to WordPress security issues – both real and perceived – I believe that, as we go forward, ensuring the robustness of data integrity and security of repository-hosted Themes will become increasingly important. Further, I believe that adoption of the Settings API will eventually prove to be requirement toward those ends.

So, Theme Developers: have you tried to use the Settings API? What issues have you encountered? What difficulties do you envision in attempting to migrate your Themes’ current settings functionality to use of the Settings API? How long do you believe would be reasonable before the Theme Repository begins encouraging Theme developers to use the Settings API, either as a recommendation or as a requirement?

Please note: this is an extremely early-stage discussion. At best, use of the Settings API might show up as recommended when the Guidelines are revised for WordPress 3.2. But, we want as much input as possible, as early as possible, so that we can begin addressing whatever concerns may exist.

So, what are your thoughts?

#settings-api, #theme-options

Discussion on menu locations for theme options.

This post is to discuss the use of add_menu_page and add_submenu_page usage for theme options.

When reviewing themes, the thoughts of usage are in several different camps at the moment and we’re looking for your opinions as well.

The first thought is that the dev and theme team want to strongly push developers to utilize as much of the consistency of the UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. and APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. as possible which means when locating the options for a theme it should be found under the WP-ADMIN -> Appearance section of the menu.

Another thought is that if the theme itself is large enough to warrant using it’s own top level menu option, what would be the criterion of that, how much is enough? could those submenu pages inside the top level (add_menu_page) be necessary to be placed as a top level and not options tabs of some sort inside the theme options page itself.

What are the cons of using a top level?

  • It could be using an menu anchor # that a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the Plugin Directory or can be cost-based plugin from a third-party uses to display it’s menu on, so one or the other will disappear.
  • It’s not conducive to the consistency that some people would like to see the wp-admin steer towards, the commonality of finding options in the appropriate places.

What are the pros of using a top level?

  • Can be described to end users easier? (rough one)
  • Can be used to attach theme-based plugins to, for example a plugin can create a top level submenu item *onto* that top level theme add_menu_page to keep everything nicely bundled together.

In my opinion a theme developer if they have theme options, it should indeed be found in the appearance -> section of the wp-admin; if that top level itself doesn’t have sub menu pages

  • Looking for feedback, opinion’s and idea’s towards finalizing a recommendation, requirement for the theme review process.

#menu-location, #theme-options