Settings API vs. Old School Theme Options

bitfade said
with settings API , you have to use php for everything.

Is that supposed to be a good thing?

landonw said

bitfade said
with settings API , you have to use php for everything.

Is that supposed to be a good thing?

fillerspace said

landonw said

bitfade said
with settings API , you have to use php for everything.

Is that supposed to be a good thing?

i think he was saying that’s a bad thing…why go through the hassle of using php to generate your JavaScript and CSS when you could just write it directly?

Two questions:

1) What do you mean you have to generate JS and CSS with PHP ? (sub-question: how does it generate it?)

2) What do you mean by writing JS and CSS directly?

JS and CSS are things completely unrelated to how you make the theme options panel. You create a CSS file and a JS file then using add_action() and WordPress enqueue functions insert them on the page.

I think that if you were creating a simple theme that’s not loaded with options, you can save yourself a lot of time by just using the Settings API . You don’t have to plan out any of your HTML markup, create any CSS or javascript, etc. Wam, Bam, finished, and the user has a simple interface they already know how to use. However, for me personally, I like to jazz everything up, so I’ll continue to stay away from the Settings API … and apparently people in the WordPress community will continue to dislike me, I suppose

ThemeBlvd said
I think that if you were creating a simple theme that’s not loaded with options, you can save yourself a lot of time by just using the Settings API . You don’t have to plan out any of your HTML markup, create any CSS or javascript, etc. Wam, Bam, finished, and the user has a simple interface they already know how to use. However, for me personally, I like to jazz everything up, so I’ll continue to stay away from the Settings API … and apparently people in the WordPress community will continue to dislike me, I suppose

Well from what i can see none of us is a fan of the Settings API

And you can build your own “framework” for the theme options panel and reuse it for every project. Much easier to just populate an array with options you need then to create it from scratch every time

using php to generate form markup can be ok if you don’t need complex layouts

but when you start using widgets like tabs, accordions, etc and/or need to alter layout/options values at runtime in response to user action, this approach is very limiting

no matter how much you extend your framework trying to deal with all possible situations, you’ll often find yourself in a point where you need more control

I rely on ajax/json to exchange data, using static html for the layout and javascript to handle runtime changes/dynamic data is a natural choice and gives me the control i need in all possible sitations.

bitfade said
using php to generate form markup can be ok if you don’t need complex layouts

but when you start using widgets like tabs, accordions, etc and/or need to alter layout/options values at runtime in response to user action, this approach is very limiting

no matter how much you extend your framework trying to deal with all possible situations, you’ll often find yourself in a point where you need more control

I rely on ajax/json to exchange data, using static html for the layout and javascript to handle runtime changes/dynamic data is a natural choice and gives me the control i need in all possible sitations.

I actually think for complex theme options panel using PHP to make it all dynamic (automatic) is the best way to go.

I keep only the js and the css outside, obviously.

The html of my options is printed by php. I find this solution the only way to go. I set my options in multidimensional arrays, that I can use them to create forms for the theme options, for the metaboxes and for the shortcodes generator… each form element has a dedicated function for the ouput, simple or complex… so if I edit an element it has effect everywhere.

I don’t think you can do all this by using the settings api, that is dedicated only for the options. So if i have to use that for the options and my framework for shortcodes and metaboxes I would need useless additional work and code.

WPScientist said
I actually think for complex theme options panel using PHP to make it all dynamic (automatic) is the best way to go.

bitfade said

WPScientist said
I actually think for complex theme options panel using PHP to make it all dynamic (automatic) is the best way to go.

Opposite side of the coin here.

to store fields, rules, error messages, behaviours in object/arrays and add tons of server side code to generate all the possible form markup variations it may work for others but has always failed to me

What variations, you need: input(text), textarea, select, checkbox, radio and upload. What else is there.

Adding a new option is like:

$options[] = array( 'title' => 'Field title',
                    'desc'  => 'Here goes the description for this field.',
                    'id'    => 'the_field_id',
                    'std'   => 'default value',
                    'type'  => 'text' );

The system takes care of everything else for this option.