implement options framework

[roots]

implement options framework

[twaiiiin]

I totally agree. I'm trying to do that since yesterday...

[twaiiiin]

The problem is, @devinsays's work is a plugin. I think it's complicated to integrate into roots. But before make a plugin, he worked from a theme (http://wptheming.com/2010/11/thematic-options-panel-v2 & http://wptheming.com/2010/12/options-framework). We should based the integration on that work. BUT, it's not maintain anymore. @devinsays does the updates only on the plugin version...

[retlehs]

hmm, hopefully we can implement the plugin version somehow since it's the one that's actively maintained. still haven't gotten a chance to really try it out yet though :(

[devinsays]

I'll update the theme version once I'm sure there's no hidden bugs left in the plugin.

I'd suggest building your theme to use the plugin, and then when a theme version is released you'll be able to very easily integrate it if that works better for your project.

[johnraz]

I started implementing this today.

After looking at how the plugin works and because it involves quite a lot of changes i thought creating a branch would be cleaner. So you will find a "with_options_framework" branch in my fork. I haven't pushed anything yet (still not enough material to push).

I suggest that I first port everything as it is now and then we could start talking about improvements.
I'm not available tomorrow (my bro's brithday), but I will put in some effort this week-end.

That's it for now ;-)

[twaiiiin]

It's a very good news.
I have already some ideas of improvements to sugest. :)

[johnraz]

Ok - The options are all in the backend now and the roots page in the admin menu points to the new theme options page.
Nothing is done in the front-end yet, I prefer we validate the use of the options framework now, before i go forward.

@retlehs : could you give this a look - and validate that the look and feel suits you ? This way I can finish this task and submit a pull request ;-) thx.

[retlehs]

just checked it out john, good stuff! style looks good. we can remove the 'roots' menu item since now there's the 'theme options' item

i really wish we could implement this without requiring the plugin, but like devin says above maybe we should just implement it like this for now, and then once the theme version is updated we can integrate that.

i also noticed that clicking on labels for checkboxes and radios didn't toggle them - is that an issue with the options framework markup?

thx a lot for working on this :)

[johnraz]

Great!

About the label + for attribute in options framework, I already reported an issue to devin on his github page.

I will move on to the next step.

[retlehs]

https://github.com/valendesigns/option-tree from @valendesigns is another option, i'm going to give it a try soon

[valendesigns]

Since 1.1.6 OptionTree is more theme friendly so you can have default options built in when you activate the plugin. I know a lot of people want to go the framework route vs the plugin route but updates for clients or just people using the framework in general gets a bit weird. Also, I'll be adding options to allow layout switching so you can save multiple option data sets and revert back and forth between them in the next update. The codes done I just need to test for bugs and clean it up.

[johnraz]

That looks great.

But guys, let's not loose focus here, the all purpose of this is to include a "tool" to help developer.

So it can either be a plugin, then it should install itself and be ready to use after install. In this case roots is out of the
problem and we only need to recommend it in the plugin section.

Or it can be a framework, and then we have to make the theme ready for the framework.

So we have to decide which way we go. Because the talk is getting a bit blurry.

Just my 2 cents.

edit: I personally agree with @valendesigns that the plugin way allows easier update process.

[retlehs]

i never really wanted to use a plugin to implement theme options, my intentions were to integrate it fully into the theme. ideally that's what we'll do..

if we have to depend on a plugin to be installed in order for the theme options to work, then we'd have to make sure the plugin is installed upon activation of roots/before letting the user to anything

we don't have to use options framework or option tree but i figured it'd save us some work

[valendesigns]

One day I'll probably create a framework from OptionTree and completely refactor the code, but till then a plugin is the easiest solution for maintainability across my client base. There are ways to make sure the plugin doesn't need to be installed to run the theme and fallbacks for the cases when it gets deactivated. So that shouldn't be a contributing factor to the reasons not to use a plugin.

[johnraz]

Back to business.
Considering our talk, and having already made a part of the work with options framework,
I recommend we stick with it for now.

That way I can finish the integration so that we can move on other features.

If later we find a better way, we'll have to split roots in 2 versions to keep backward compatibility.
But git is powerful - it shouldn't be a big problem.

Cheers

[johnraz]

pull request submitted #39 in my brand new fork \o/

[retlehs]

after testing this out i'm thinking the direction we're going to have to go is one that doesn't involve a plugin. we've got a few options and can discuss this further in a new issue (will create shortly)

thanks for the work on this john