How to make sure that the default value and the conditional branch judgment are the same in the checkbox of the theme customizer.

How to make sure that the default value and the conditional branch judgment are the same in the checkbox of the theme customizer.

Thank you for visiting. This page is an English translation of the Japanese site [Knowledge Base] using Google Translate. Please understand that there are some points that are difficult to read, such as sentences and expressions.

Improved the phenomenon that the default value of the check box added to the theme customizer is set to true, and even though it is checked on the theme customizer, it is processed as false when the process is separated using conditional branching. A note about how.

The following pattern did not work for this process. The block-based widget added in WordPress 5.8 is turned off (disabled) by default so that it can be used arbitrarily.

/* Disable block-paced widget editing */
$wp_customize->add_setting( 'fulledit_widget_disable', array(
	'default' => true,
	'sanitize_callback' => 'habone_sanitize_checkbox',
) );
$wp_customize->add_control( new WP_Customize_Color_Control( $wp_customize, 'fulledit_widget_disable', array(
	'label' => __('Disable Full Edit Widget','habone'),
	'description'=>__('Disables the block-based widget editing feature introduced in WordPress 5.8','habone'),
	'section' => 'default_function_control_section',
	'settings' => 'fulledit_widget_disable',
	'type'=>'checkbox',
	'priority' => 80,
)));

Since “‘default’ => true,” is set in the above code, if you look at the customizer item in the initial state where the theme is installed, it is certainly checked.

How to make sure that the default value and the conditional branch judgment are the same in the checkbox of the theme customizer.|Knowledge Base (English edition)

However, when I opened the actual widget setting screen, the phenomenon that the block-based widget opened as shown in the figure below occurred.

How to make sure that the default value and the conditional branch judgment are the same in the checkbox of the theme customizer.|Knowledge Base (English edition)

Below is the code I added to functions.php to disable the block-based widget.

/***** Stop block-based widgets added in 5.8 by customizer *****/
if(get_theme_mod( 'fulledit_widget_disable') == true){
	add_filter( 'gutenberg_use_widgets_block_editor', '__return_false' );
	add_filter( 'use_widgets_block_editor', '__return_false' );
}

If fulledit_widget_disable is True in get_theme_mod, the filter hook that disables the block-based widget will be triggered.

I know that there are various ways to write this condition judgment, but it seems that consistency can be almost certainly obtained by the following method.

The surest and easiest way to match a checkbox that is set to true by default with the judgment of a conditional branch function

When you first encounter this problem, why not write the default value to the corresponding line in the database options when installing the theme? I searched a lot, but I couldn’t find a good document, and there was a concern that “maybe it ignites when updating or reinstalling the theme, causing inconvenience …”, so I postponed it for a while. I was doing it.

But after all it has been checked and I want to make it work properly! After investigating various things in, it will be possible to make an accurate judgment with a really simple writing method.

If you are looking at this page, I think that you are stumbling in the same place, so before I introduce the conclusion, I will explain in order how the WordPress customizer works (unnecessary one is appropriate). Please skip it).

Like the code described at the beginning, when “‘default’ => true,” is set in the functions.php that sets the theme customizer item, it looks like the theme customizer on the management screen. Although it is checked, this is a visual story, and in order to actually make it true, it will not be reflected unless you make some changes and click “Publish”.

The reason why it didn’t work this time is because of this, when the theme is installed (when “Publish” is never clicked in the customizer), the row (theme_mods_) that stores the theme settings on the options table Since nothing was recorded in the theme name), it was judged to be false, and even though it was checked on the customizer, it did not work like that.

The easiest and most accurate way to solve this is a conditional branch of whether the item is checked or not, as shown in the code example below, and the default value (true) if it is empty (if the data does not exist). Is to set to the second argument.

if(get_theme_mod( 'Customizer control name',true)){
What to do if true
}

Now, it will behave as follows.

  • If there are checked items and nothing is done after installation (public is not clicked), the default of the conditional branch function (true value of the second argument) is used for processing.
  • If there is a checked item, change any item other than this item and click Publish Theme Customizer, it will be recorded in the database as checked and processed with True.
  • If there is a checked item and you uncheck the item and click Publish Theme Customizer, it will be recorded in the database as unchecked and processed with false.

When setting with reference to this article, please try enough operation such as deleting the theme option line (theme_mods_theme name) of the options table and testing from the state before installation completely.

Note that this default setting can be used with get_option as well, so please try it.

Post Author: