Earlier this week, Theme Review Team at WordPress.org made an important announcement about Theme Customizer. Theme authors are now required to use Theme Customizer for all theme options. References:
This is excellent for users, whether it’s a beginner or an expert, none of them will need to search for theme settings/options. Having it placed in customizer will make it much easier to get started.
For developers, they will be able to make most out of the WordPress core, we will see new options and extensions for theme customizer soon. Above all, this will make it easier for theme reviewers to follow a standard pattern. With varied range of theme options that were being used earlier, it was little difficult to check for data sanitization and validation. But, with standardization of customizer, it will be much easier. Theme customizer’s settings and validation check have already been added to Theme Check plugin.
At IdeaBox Themes, we have been using Theme Customizer from the first day and there was a problem that I found while building the themes.
To use the Live Preview feature, we need to use
'type' => 'theme_mod' and then bind it with the customizer js. Now, the problem is
theme_mod is specific to the currently active theme. Which means that the current theme’s data/settings/options can not be accessed by another theme.
get_option(), all the data is globally accessible.
theme_mod approach, the problem comes in when you build a child theme. Since the data was earlier saved specific to the parent theme, it becomes unusable to the child theme. If you have setup a site with parent theme and later realize the need for some customization, you go ahead to build the child theme and after you activate it, you will need to re-do all the settings and options.
This is a big pain and it will be nice to have the next version of customizer which would check for theme mods of parent theme and inherit those to child theme.