They both actually refer to the same thing.. i think the term settings is left over from older code that referred to settings instead of options…
Both refer to data stored in the options table.. and both require admin level users in order to manage them..
With the settings api you don’t need to add_option or update_option as these two scenarios are covered with your setting registration, eg. register_setting which registers/adds a given option and provides a callback argument(function) that deals with saving the option(s).
Essentially Esmi is correct, the Settings API would be appropriate, i simply wanted to point out they both deal with data in the same place..
However, having recently moved over the the Settings API for storing and manipulating theme options, I have to say that the approach feels quite different. I find I’m having to do far less code “drudge” work.
For sure, registering a setting(option) definately is a simple process, though i can’t say i know the old way.. the settings api was introduced whilst i was coming into WordPress(perhaps even before)… 🙂
Something that alluded me for a while though, was that although there are accompanying functions for registering setting fields or sections, these two functions don’t have to exist alongside registered settings(i had this crazy idea they did at one point).. but that was purely related to how i needed to print the nonces for registered options/settings …(further experimentation and code examination made that more clear)..
I like how it works, but the thing i feel let’s it down is that it’s not necessarily suitable(in all cases that is) for use with theme options. Why? Options, or any registered through the settings api require that the user saving them have the manage_options capability (and rightly so when it comes to options in general), but that may not necessarily be the case for theme options(edge cases maybe, but there’s still some limitation there when compared with privs for other theme related tasks which have seperate caps).
…but anyway…Yes!… less drudge work for sure(i’ve seen the older methods, it’s not always pretty)… 😉
Most theme options tend to have pretty far-reaching effects on the site (look at Suffusion, for example, where you can completely change the site’s layout) so I can understand why a possibly rather conservative approach was adopted in terms of permissions. My biggest bugbear with themes and the Settings API is that, unlike plugins, themes can’t run a clean unregister on deletion. I really dislike leaving even a single unnecessary line in the wp_options table.
I remember reading a ticket to the effect of theme’s not having a register_deactivation hook.
Most likely one of these, been an ongoing discussion for a while by the looks for things.
http://core.trac.wordpress.org/search?q=theme+activation
🙁
I agree though, theme’s should be able to remove options on deactivation (and authors then using the hook to make removal optional – for users that switch themes about and want to retain settings saved)..
