[wp-trac] [WordPress Trac] #38114: Make it easier to visualize where to put your content in a given theme (aka "dummy content")

WordPress Trac noreply at wordpress.org
Wed Oct 12 00:47:16 UTC 2016


#38114: Make it easier to visualize where to put your content in a given theme (aka
"dummy content")
----------------------------+------------------
 Reporter:  helen           |       Owner:
     Type:  task (blessed)  |      Status:  new
 Priority:  normal          |   Milestone:  4.7
Component:  Themes          |     Version:
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:
----------------------------+------------------

Comment (by westonruter):

 I just came across this ticket. There are some really great overlaps
 between dummy content and customize changesets (#30937). As the patch for
 changesets currently sit (Make Core post forthcoming), there is the
 introduction of being able to stash theme mod changes for themes that
 weren't ultimately activated, allowing those theme mod changes to pre-
 populate the customized state the next time that the theme is live
 previewed.

 For example, if you go into the customizer and set the background color to
 red for Twenty Fifteen, but then switch to Twenty Sixteen and set the
 background color there to green and then activate, the next time you
 switch to Twenty Fifteen in the customizer you'd see the red background
 color restored as you had last set it.

 I see dummy content being a natural extension to this pre-population of
 the customized state. In addition to unstashing the theme mods when
 previewing a theme switch, any dummy content could also be added to the
 customized state as well so that it appears in the preview and would go
 live with activation.

 The changesets patch stores data as JSON in the DB. All data represented
 in customized state must be JSON-serializable. However, for the sake of
 translations I think that @davidakennedy's example of encoding in PHP is
 good, as long as the values in the PHP array are JSON-serializable
 (strings, numbers, booleans, positional arrays, associative arrays).

 Actually, even without changesets dummy content could be incorporated into
 a theme today with something like this:

 {{{#!php
 <?php
 function twentyeighteen_customize_register_default_setting_values(
 $wp_customize ) {

         // Only pre-populate customized state when doing a theme switch.
         if ( $wp_customize->is_theme_active() ) {
                 return;
         }

         $default_values = array(
                 'operating_hours' => __( 'Monday-Friday, 8am-5pm',
 'twentyeighteen' ),
                 'address' => __( '123 Main St, Anyplace, USA',
 'twentyeighteen' ),
                 'owner_name' => __( 'Jane Smith', 'twentyeighteen' ),
         );

         // Only set dummy values for settings that don't already have a
 value supplied.
         $existing_customized_state =
 $wp_customize->unsanitized_post_values();
         foreach ( $default_values as $setting_id => $default_value ) {
                 if ( ! array_key_exists( $setting_id,
 $existing_customized_state ) ) {
                         $wp_customize->set_post_value( $setting_id,
 $default_value );
                 }
         }
 }
 add_action( 'customize_register',
 'twentyeighteen_customize_register_default_setting_values' );
 }}}

 As for pre-populating actual posts and pages, this is also facilitated by
 #34923 where page/post stubs can be created in the customizer and
 previewed but which are represented in the database with an `auto-draft`
 status until the changes are saved. This ensures that these posts get
 garbage-collected if the changes are never saved. In any case, these stubs
 could also be created in such a
 `twentyeighteen_customize_register_default_setting_values` as well. In
 order for them to be fully previewable in site as if they were published
 (so that they appear in `WP_Query` results as expected) then additional
 preview filters would be needed, such as have been implemented in the
 [https://github.com/xwp/wp-customize-posts Customize Posts] feature
 plugin.

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


More information about the wp-trac mailing list