Chip Bennett

The most problematical part was the rewrite from the option framework to the customizer and the different default values if an option was not set.

This is an issue with the options framework itself, not properly handling default option values. It has to do with an incomplete implementation of the Options API (or Theme Mods API), in which the framework either did not define, or did not specify in the get_option()/get_theme_mod() call, the default value for the option being used.

It has nothing at all to do with the Customizer, which can seamlessly interact with both the Options API and the Theme Mods API, and will use default values, if those defaults are provided.

This isn’t a problem isolated to ThemeKraft. Several of the options frameworks in wide circulation weren’t properly implementing defaults (what the TRT refers to as “sane defaults”). It was so much of an issue that, some time back, the TRT had to implement a requirement that Themes use sane defaults for all options.

(As an added bonus for users, part of “sane defaults” implementation is that Themes are required NOT to save option values to the database, unless the user does so, via explicit action to save settings.)

So, is the Customizer *causing* any new problems? No. But it very well may be *exposing* problems that *already existed*.

Name *

Email *

Website:

Topic Title (Maximum Length: 80):

Forum:
— No forum —AI and WordPress Articles Blocks Showcase Discussions Events Introductions Jobs and Working in WordPress Podcast Episodes Site and Block Editor