[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