Theme settings Page: Settings Api vs Update_Options

Question

I’m a new WordPress developer trying to start a carrier selling Premium Themes.

In the last week, I’ve been confronted to many difficulties trying to understand how to create a theme options page. At the end I’ve finally understood the way I should do it using the settings api.

Then, I tried to customize the setting page style, to add some jQuery functionalities and make the page more userfriendly. I found that there is no hooks to do that and the only way was to override some functions (Like the do_settings_sections()), or to do some Hacks.

After a long way trying to look for a tutorial that would help me to do what i’m looking for in the right way, i tried to analyze the anatomy of the most sold themes in the net. What I figured out, is that they are not following any so called Good way to create their theme settings. It’s like if they are developing the page settings in their own way, well they are using all the possible hooks and filters. But to create and save the settings, here is how they do it:

• They start by saving the default template options using the function update_option.
• Then they create their own form that will send the data using Ajax.
• Finaly, using the specific functions, they validate the data and save it using update_option.

What I can say, is that:

• The setting api method is the regular and the valid way to create a WordPress settings page in the right norms, valid and secured. But as far as I know, this method is so limited for the developer making him less creative.
• The second method is more flexible and will allow the developer to create as many functionalities a he want, in any way he want.

So which way should I start using for my template, and why.

Thanks All.

Answer 1

You are not wrong about conceptual limitation, but any development convention is inherently about constraints. Constraints are "bad", but they are also often good and important.

In this specific case it's slightly soured by Settings API being especially nasty snowflake, which historically led people to reinvent this particular wheel a lot.

However, your estimate of flexibility seems very off base.

Any admin page can be uniquely identified, otherwise they wouldn't work in first place. You should look at functions like get_current_screen() and work through admin-header.php.

Since we are talking in context of commercial themes in the end it's your business decision. Some people would insists on following same guidelines and conventions as free themes. Some would say it doesn't matter, as long as quality and security don't suffer.