Add function or filter to send all customizer setting default values to the database upon theme installation

[curtiskessler]

I am learning theme development and developing my first WordPress theme from scratch.

My new theme contains many customizer settings, most of which include default values.

I discovered recently that upon theme installation, these customizer default values only appear in the customizer view, but are not entered into the database and are not shown on the front end.

To insert the customizer default values into the database so that they display on the front end upon theme installation, I believe (?) each theme mod must be manually entered into the database by using set_theme_mod().

This requires duplication of every default value twice within the theme code, and the addition of many lines of code for themes that create many new customizer settings.

I recommend creating a function or filter that theme developers can activate within functions.php to send all default customizer values to the database upon theme installation.

This will avoid having to duplicate default values in both add_setting() and set_theme_mod() and reduce lines of code in themes.

[joyously]

To insert the customizer default values into the database so that they display on the front end upon theme installation, I believe (?) each theme mod must be manually entered into the database

The theme should use the default value so it is displayed, regardless of what the database contains. The second parameter of the function call is the default value, already.

This requires duplication of every default value twice within the theme code

No, it doesn't.

function or filter that theme developers can activate within functions.php to send all default customizer values to the database

No, activating the theme should not have side effects in the database. The options should only be saved when the user chooses to save.

The easiest way is for the theme to have a function that is filtered (for child themes) to supply the default values. This function would be called when the defaults are needed, which is when Customizer options are set up and when using each option.

[curtiskessler]

My new theme has 100+ customizer settings, most of which have a default value which is intended to be displayed in both the customizer view and the front end when the theme is installed.

Is there any way to do this without having to define the same default value in the add_setting() array and in every instance of get_theme_mod() that uses the setting in my theme files?

This is my complaint: duplication of these values is very tedious, from a development standpoint.

It would be great if I could define them once and have them appear both on the front end and the customizer view, upon theme installation.

[joyously]

Every option should have a default value (not just some).
I told you how to do it: define a function that applies a filter for child themes, and all it does is supply the defaults. (In my theme, I broke it into several functions to supply values that are needed together.) The theme likely won't be using any one option multiple times, though.

It is not a good idea to write defaults to the database, because the theme should not affect its environment like that. The theme doesn't know (although it can check) if it's in preview mode or being used temporarily as a test to isolate a problem or being shown in the .org Theme Previewer or being used on a per-page basis by a theme switcher plugin.
Themes are for output, and should only save when the user is choosing that.

[dlh]

At the outset, I'm somewhat inclined to agree with @joyously that a higher-level approach to this problem than the Customizer might be best. Marking with the 2nd-opinion keyword to bring in some other thoughts.

[joyously]

I forgot to mention that the theme should not be calling set_theme_mod() since the Customizer handles writing to the database at the correct time.

[curtiskessler]

I decided to explicitly declare every default value in each instance of get_theme_mod() across my theme.

This worked fine, although it was tedious. And if I ever decide to change the default values, the development process will require changing it in two locations instead of one.

Declaring a default value in two locations seems needlessly redundant, and should probably be avoided if possible.

I've just had an idea for how to solve this problem in the future. Perhaps the function get_theme_mod() could have an option for the default value argument, which instructs get_theme_mod() to fetch its default value from its customizer setting at the time the function is run.

This would mean that if a theme developer sets up an instance of get_theme_mod() with the "fetch customizer value as default value" option enabled, during the rest of the development process, the developer can change the default values that display in both the customizer view and the front end view by only changing it in one location.

Does this sound reasonable and feasible? I believe it would reduce the development work load while creating themes with high quantities of customizer settings and instances of get_theme_mod(), such as mine.

[dlh]

Replying to curtiskessler:

Perhaps the function get_theme_mod() could have an option for the default value argument, which instructs get_theme_mod() to fetch its default value from its customizer setting at the time the function is run.

This is an interesting thought, but since Customizer settings should be created on the customize_register action, and customize_register fires only in the Customizer, it seems like the settings would not exist to be referenced for defaults values in other contexts like requests to the frontend. Additionally, it would be difficult to extend such a feature to Customizer settings created within the JavaScript API.

As suggested in comment:1, the need here seems to be in the direction of an independent function in the theme that can supply defaults to both the Customize and settings APIs, plus any other APIs that come along later.

[joyously]

I wanted to say exactly what @dhl said about the availability of the Customizer data.
Also, hard-coding the default values is not child theme friendly. Be sure to try to make a child theme with different defaults before you consider your theme "done".