Theme Customizer > Theme Options #115

Merged
merged 4 commits into from Dec 28, 2012

Projects

None yet

7 participants

@obenland
Member
  • Removes sample theme options
  • Adds Theme Customizer enhancement (actually working!)

Goal: Emphasize the use of the Customizer versus out of style Theme Options.

@obenland obenland Theme Customizer > Theme Options
* Removes sample theme options
* Adds Theme Customizer enhancement (actually working!)

Goal: Emphasize the use of the Customizer versus out of style Theme
Options.
181c363
@grappler
Contributor

The way I see it the Theme Options are good for Layout and the Theme Customizer for the styling. I would keep the Sample Theme options as _s is supped to be a reference and base theme.

A middle way would be to have the Theme Customizer on by default and have to edit the code so to activate the Theme Options like it has been up till now.

P.s
I think there needs to be a short explanation how to incorporate the settings into the theme content.

I found the Theme Options code here easier to understand.
https://github.com/tommcfarlin/WordPress-Settings-Sandbox

@mfields
Contributor
mfields commented Nov 30, 2012

I really like the postMessage transports for the Site Title and Tagline. I really like how you have removed the theme-options.php! While the file has served it's purpose for quite a while, the Customizer has shown itself to be an amazing alternative. I do not like the idea of keeping the theme options template around because:

  • The customizer provides a much better user experience.
  • The customizer api is soooo much easier to use.
  • Having both an admin screen and customizer options that do the same thing can lead to duplicate and sometimes conflicting code.

Quick Question:

  • What do you think about changing theme-customizer.php to customizer.php?
@mfields mfields referenced this pull request Nov 30, 2012
Closed

Customizer Support #41

@kovshenin
Contributor

+1, I think theme options have to go away. If I could, I'd fire _doing_it_wrong() when a theme called add_theme_page.

What do you think about changing theme-customizer.php to customizer.php?

Since the Customizer components are called WP_Customize_*, the instance is $wp_customize and all the file names are customize-*, and the UI is "Customize" I'd follow the convention and just call it customize.php. customizer.php is okay too though.

@obenland
Member

I really like how you have removed the theme-options.php!

Pretty sweet, huh!

What do you think about changing theme-customizer.php to customizer.php?

I'm indifferent about it. Let me update the patch.

@mfields
Contributor
mfields commented Nov 30, 2012

Right on. The important part in my mind is omitting "theme-".

@obenland
Member

@obenland - do you think #115 is ready for merge?
@mfields in #125

IMO, yes.
Just as a heads up: Customizer support is activated by default ;)

@sabreuse
Contributor

+1! Anything to help make the Customizer the expected way of doing things!

@obenland obenland merged commit de29437 into Automattic:master Dec 28, 2012
@NobleWP
NobleWP commented on 181c363 Jan 6, 2013

I didn't understand the Goal here, "Goal: Emphasize the use of the Customizer versus out of style Theme Options".

I mean what are the pros and cons of using Customizer over Style Theme Options?

Could anyone tell me?

This should be included back, in rare cases but it happens like it just happened to me. A actual theme page is needed for stuff that the theme customizer can't do, like a text field for a "static" block in the home page

Contributor

I do not think that the settings page should be included back into _s. The Customizer is a much better solution for custom visual settings. It is also capable of producing a text option if necessary - it actually takes much less code than using the Settings API would. If you would like to use the code we removed, you can download it here: https://gist.github.com/4678999

I agree about the visuals being way better to use through the Theme Customizer, the options page would just be for theme options in case they are needed. It seems to me that having the option is nice.

Again I agree with you, made about 5 themes now with _s and this is the first time I actually needed it, thanks for the link I had all ready pulled it from the file history.

wow I got a response after one month. Thanks for ur work and I'll sure check that Gist.

@mfields
Contributor
mfields commented Jan 16, 2013

The removal of the options screen was mainly inspired from this post from Otto:
http://ottopress.com/2012/theme-customizer-part-deux-getting-rid-of-options-pages/

Here are a few resons that got us started thinking in this direction:

  • Users get live feedback. This is awesome!
  • The amount of code that it takes to create a custom page is ALOT OF CODE! Using Otto’s approach would cut this down drastically.
  • Theme mods are automatically scoped to the theme and are more semantic than options IMHO. Less custom code for us to write.
  • There are a few UI elements included in the Customizer already which means that it could really cut down on the code we need to write and review. No html FTW!
  • We currently do everything twice: Make (and test) the settings page and then work these settings into the customizer. Why do this twice? I think we should pick the best of the two IUs and focus our full attention on making that experience as best as possible.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment