Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Theme Customizer > Theme Options #115

Merged
merged 4 commits into from Dec 28, 2012

Conversation

Projects
None yet
7 participants
@obenland
Copy link
Member

commented Nov 28, 2012

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

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

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.
@grappler

This comment has been minimized.

Copy link
Collaborator

commented Nov 29, 2012

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

commented Nov 30, 2012

+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

This comment has been minimized.

Copy link
Member Author

commented Nov 30, 2012

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

This comment has been minimized.

Copy link
Contributor

commented Nov 30, 2012

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

@obenland

This comment has been minimized.

Copy link
Member Author

commented Dec 17, 2012

@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

This comment has been minimized.

Copy link
Contributor

commented Dec 28, 2012

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

obenland added a commit that referenced this pull request Dec 28, 2012

Merge pull request #115 from obenland/master
Remove generic Theme Options page in favor of the Customizer.

Having a set of sample options encourages their use — we shouldn’t do this, it’s simple enough to code options up whenever we need them.

Customizer support is activated by default and comes with a working sample implementation. For more information about the Customizer and how to leverage it's API please see http://ottopress.com/tag/customizer/

@obenland obenland merged commit de29437 into Automattic:master Dec 28, 2012

@NobleWP

This comment has been minimized.

Copy link

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 comment has been minimized.

Copy link

replied Feb 3, 2013

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

This comment has been minimized.

Copy link
Contributor

replied Feb 3, 2013

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

This comment has been minimized.

Copy link

replied Feb 3, 2013

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.

This comment has been minimized.

Copy link

replied Feb 3, 2013

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

@mfields

This comment has been minimized.

Copy link
Contributor

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
You can’t perform that action at this time.