[wp-trac] [WordPress Trac] #30988: Setting's default value doesn't apply on preview window

WordPress Trac noreply at wordpress.org
Tue Feb 3 01:18:03 UTC 2015


#30988: Setting's default value doesn't apply on preview window
--------------------------+-----------------------------
 Reporter:  Aniruddh      |       Owner:  ocean90
     Type:  defect (bug)  |      Status:  reviewing
 Priority:  normal        |   Milestone:  4.1.1
Component:  Customize     |     Version:  4.1
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  administration
--------------------------+-----------------------------

Comment (by westonruter):

 Replying to [comment:19 ocean90]:
 > I could reproduce this issue or at least a regression from 4.0.

 This is actually expected. Remember in 4.1 via #29983 we only `POST` dirty
 settings (ones that have changed), so the default value attached to a
 setting will always be directly used in the Customizer preview as opposed
 to the post value if the setting was not changed.

 I think your plugin code needs to be tweaked, for instance:

 {{{#!patch
 --- 30988-plugin.php
 +++ 30988-plugin.php
 @@ -1,6 +1,13 @@
  <?php
 +$foo_color_default = '#f00';
 +$foo_text_default = 'Lorem';

 -add_action( 'customize_register', function() {
 +// These add_option() eliminate the need for supplying default values for
 settings,
 +// and it eliminates the need to supply the 2nd $default arg to
 get_option()
 +add_option( 'foo_color', $foo_color_default );
 +add_option( 'foo_text', $foo_text_default );
 +
 +add_action( 'customize_register', function() use ( $foo_color_default,
 $foo_text_default ) {
         global $wp_customize;

         $wp_customize->add_panel( 'foo', array(
 @@ -15,7 +22,7 @@ add_action( 'customize_register', function() {
         ) );

         $wp_customize->add_setting( 'foo_text', array(
 -               'default'    => 'Lorem',
 +               'default'    => $foo_text_default, // not really needed
 because add_option() call used with default supplied
                 'capability' => 'edit_posts',
                 'type'       => 'option',
         ) );
 @@ -27,7 +34,7 @@ add_action( 'customize_register', function() {
         ) );

         $wp_customize->add_setting( 'foo_color', array(
 -               'default'    => '#f00',
 +               'default'    => $foo_color_default, // not really needed
 because add_option() call used with default supplied
                 'capability' => 'edit_theme_options',
                 'type'       => 'option',
         ) );
 @@ -38,7 +45,7 @@ add_action( 'customize_register', function() {
         ) ) );
  });

 -add_action( 'wp_head', function() {
 -       var_dump( get_option( 'foo_color' ) );
 -       var_dump( get_option( 'foo_text' ) );
 +add_action( 'wp_head', function() use ( $foo_color_default,
 $foo_text_default ) {
 +       var_dump( get_option( 'foo_color', $foo_color_default ) ); //
 second argument not needed since add_option() call used
 +       var_dump( get_option( 'foo_text', $foo_text_default ) ); // second
 argument not needed since add_option() call used
  });
 }}}

 https://gist.github.com/westonruter/1717cadbb3ef581291ba

 Without doing `add_option()` or supplying the default arg to the
 `get_option()` call, then the frontend would not get the default values to
 display without first visiting the Customizer.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/30988#comment:20>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list