Simplifying WordPress Settings

Though I still this project may be useful for some, I've updated my personal opinions on this.

When it comes to working with WordPress, it’s no secret that I’m a fan of using the WordPress APIs as much as possible, and not circumventing the built-in functionality with vanilla PHP.

Arguably, one of the most complicated APIs to work with is the WordPress Settings API. It’s unintuitive, requires some small details to manage, and also requires a bit of repetitive code.

For many developers, the unintuitive nature and the way in which sections, settings, and options are built begs for a cleaner interface. And if you’re one of those developers, then you should check out Clif Griffin’s WordPress Simple Settings project.

WordPress Simple Settings

WordPress Simple Settings

WordPress Simple Settings on GitHub.

In short, WordPress Simple Settings is a library that provides a facade, or a cleaner interface, to the WordPress Settings API making it possible to build settings, sections, and options that communicate with the WordPress API and that are themed in the native WordPress skin, but without requiring as much code.

In short, the project offers the following functions:

  • add_setting
  • get_setting
  • update_setting
  • get_field_name
  • the_nonce
  • save_settings

All of which are self-explanatory.  Of course, project’s like this are always open for addition discussion and code contributions.

To that end, you can read more information and discuss the project on Clif’s original announcement post, and you can download and/or contribute to the project on its GitHub page.

Category:
Resources
Tags:

Join the conversation! 17 Comments

  1. “When it comes to working with WordPress, it’s no secret that I’m a fan of using the WordPress APIs as much as possible, and not circumventing the built-in functionality with vanilla PHP.”

    Sorry, but WTF springs to mind… Why would vanilla PHP be something to avoid… you realize wordpress is built in older, poorly formed PHP right?

    I can understand that statement if someone is going to code something that already exists into wordpress, but what about performance and portability of non-WP coupled code?

    Don’t get me wrong I appreciate what wordpress can do as a platform, but it’s not the only one out there and should not be used as a hammer for all nails… In fact most of my day seems to be spent on projects where people don’t realize you can have something that uses wordpress sure, but actually exists in nothing but vanilla PHP, which is pulled in and wrapped by wordpress into a plugin… I would suggest re-thinking that statement, as long before WP and long after WP, PHP will still be updating adding features that all users can rely on…

    • Sorry, but WTF springs to mind… Why would vanilla PHP be something to avoid…

      Vanilla PHP isn’t something to avoid all together – it’s something that should be avoided when you’re working with WordPress and an API already exists for what it is that you want to do, then you use the API.

      The same is true for any other framework or library:

      • If you’re working in .NET, then use the .NET libraries. Don’t take the long way around and re-invent the wheel by writing some C\C++ based library to meet your needs.
      • The same can be said for Ruby on Rails: If Rails offers a function or API, then use it versus writing your own in Ruby.
      • …and so on.

      Basically: Don’t reinvent the wheel to do what a built-in function or library already offers.

      I can understand that statement if someone is going to code something that already exists into wordpress, but what about performance and portability of non-WP coupled code?

      But “WP-coupled code” is exactly what I’m talking about. The WordPress Settings API doesn’t work nor apply to anything outside of WordPress, so why would I be concerned about it’s portability outside of the application?

      Don’t get me wrong I appreciate what wordpress can do as a platform, but it’s not the only one out there and should not be used as a hammer for all nails…

      If WordPress is the hammer, then everything looks like a nail. I’ve never claimed that WordPress is a hammer nor do I think it’s a one-size-fits-all solution.

      It’s got its uses for which it can be used just like anything else that’s available today.

      I would suggest re-thinking that statement, as long before WP and long after WP, PHP will still be updating adding features that all users can rely on…

      You’re right in that PHP will still be evolving as a language, but this isn’t about PHP. It’s about WordPress, it’s about making certain things easier within that economy, and it’s about sticking with best practices for the specific application.

      If I wanted to discuss why we should use vanilla PHP, the pros and cons in using features built into the latest version of the language, its compatibility with the variety of hosts that are available, and when it can, should, or shouldn’t be used, then I would’ve done so in a post that wasn’t about a WordPress-specific plugin.

      • Right… Nice one, very abrasive…

        The settings API if difficult to use (I don’t agree with that either) is a part of wordpress, what I was commenting on was writing a solution that is virtually useless outside of this rather small use-case, so is not just coupled to WP… It was entirely a suggestion based upon your post…

        The code you were linking to is not PHP generic (or vanilla) with a wordpress adapter (which you seemed to make sound like a bad thing), but a specific implementation of a specific sub-set of the settings API, so it is literally useless! There are tonnes of parts of WP that are not WP specific, issues such as setting, checking, updating options, settings etc, are entirely outside of wordpress and I would think are present in 90% of dynamic websites regardless of language… So unless you are saying wordpress invents problems, I cannot see the problem or why anyone that would be so abrasive about the suggestion…

        If I wanted to discuss why we should use vanilla PHP, the pros and cons in using features built into the latest version of the language, its compatibility with the variety of hosts that are available, and when it can, should, or shouldn’t be used, then I would’ve done so in a post that wasn’t about a WordPress-specific plugin.

        Also special Thanks for not being a dick, $me->status = UNSUBSCRIBED;

        • I dare to interfere.

          My oh my, why do you unsubscribe after one post? It seems that you cant stand different point of view. That kind of attitude isn’t going to lead you anywhere. What about your emotional intelligence mate? It’d be wiser to lecture those lecturing instead of simply giving up. I personally think that you’ve got a point here, however the way you treat your interlocutor makes your opinion lose it’s arguments. (the people will get annoyed by the tone, instead of reading your not-so-bad arguments – please bear that in mind)

          Following your answer I dare to say that WordPress is useless (as it can’t be used outside of WordPress). Heck, even WP plugins are useless, they can’t be used outside of WP.

          Following what Tom had said Settings API is hard to use, especially by beginners. That is due to the fact, that each function takes a lot of arguments – which are required. It’s really easy to get lost and frustrated.

          @Tom thanks for the link to the library. I actually have been working on something similar on my WP Base Theme (trying to create a declarative way of defining settings API fields: https://github.com/gicolek/WP-Base-Theme#theme-options), however I’ll probably revise this and maybe collaborate with Barry on that topic :-)

          • The real irony of course is that even the core devs agree the Settings API needs an overhaul: http://core.trac.wordpress.org/ticket/18285

          • Following what Tom had said Settings API is hard to use, especially by beginners. That is due to the fact, that each function takes a lot of arguments – which are required. It’s really easy to get lost and frustrated.

            Yeah – in my experience, it’s the number one thing that I’ve had others ask me for help with and it’s all because the pieces don’t often “click” for sections, settings, options, and so on.

            And I think Clif is right in his post that the diagram that’s required is a little much for a single API (not to mention the bit about the Core Developers agreeing ;).

            Anyway – I’m glad I was able to share it. Having a base theme like you linked up is really useful especially whenever you’re doing a lot of work with theme development and you find yourself just making the same boilerplate stuff over and over.

            At any rate, yeah – I think collaborating with “Barry” is a good idea ;P.

  2. This is pretty neat! I was unaware of @clifgriffin’s WordPress simple settings project. I will definitely end up using this sometime soon.

    Also, if it’s any consolation, I am unsure of what @LewisCowles1’s problem is, but sure that his complaints were baseless conjecture.

    Thanks for this post!

  3. Thanks for sharing something valuable as always Tom.

  4. Thanks for sharing this, looks like it could be the answer to my frustration working with the settings API. I like that it is designed to work like the Options API, which is so easy to work with.

    • Yeah – the Options API, Meta Data APIs, and others generally are easy to understand and get stuff done.

      The Settings API isn’t completely terrible, but the learning curve is steep so it is a bit worse when compared to some of its counterparts.

  5. This is great! Using less code to generate what is needed with the WordPress Settings API is fantastic in my opinion.

Leave a Reply