Make it easier to visualize where to put your content in a given theme (aka "dummy content")

[helen]

When you spin up a fresh site or try on a theme that has many widget areas, it can be difficult to imagine how to shape what exists into what you have in mind. This is further compounded by mismatches in theme screenshots, .org demos, other demos, and live previews with your own (potentially sparse) content.

To that end, I would like to propose a system of "dummy content", where content can be provided that gives users an idea of what might looks best in a given area of a theme. This content should not be injected into the database, but rather appear during live previews (i.e. the customizer).

We will want to consider the following:

• What does the current default and fallback content landscape look like?
• What do themes and plugins currently do around preview or default content?
• What kind of format should this take? (i.e. JSON for cross-language/context compat)
• How do we make this translatable/localization-friendly, i.e. making sure that content is not just translatable into another language but also is culturally relevant?
• How do we allow for future-inspiring creativity while promoting consistent experiences and considering forward-compat?
• How might this impact the theme review team?
• Can this integrate with .org theme demos?

[celloexpressions]

One of the big challenges here is ensuring that the customizer preview remains an accurate representation of the customized state of the front end of the site. There would need to be a way to indicate being "done" with the dummy content and hiding it to see what you'll actually get before you can save and publish, or the dummy content that hasn't been customized would need to be written to the database to ensure that what the preview shows when you "save and publish" is what the front end would then show. Any divergence between the preview and the front end detracts from the value of the preview's usability as an accurate representation of the site.

If the solution here makes use primarily of the customizer preview, then this ticket should be in the customize component. If it impacts significant other areas (ie in the admin), then themes would make sense. We might have a better idea after the initial research. If we go the customize preview route, we should consider leveraging customizer partials as the mechanism for defining the fallback content.

[poena]

Currently, the theme review team does not allow large amounts of demo content. There are several reasons for this, including:
Theme authors using demo content that cannot be disabled: only removed by replacing the existing content.
Theme authors using demo content for advertising.
In these cases the user would have to "clean up" the theme before using it.
We encourage authors to use default content. For example if you have a slider that displays existing posts, then the default should be to display existing posts, and not static demo data.

-Some theme authors save their demo content as defaults in customizer settings.
Others add their demo content directly in the different templates, and show this content unless another option has been selected.
-We don't see a lot of theme authors asking the user to import demo content in the form of xml files, but it happens.

What kind of dummy content are we considering here? Populating widget areas? Dummy content with multiple posts or pages to showcase navigation and post formats?

[greenshady]

What does the current default and fallback content landscape look like?

The current landscape makes me die a little inside. The biggest problem I've seen via the TRT is that "dummy" content displays on the front end of the user's site. A theme should never be live on a user's site with dummy content because a site's visitors should see that site's content.

What do themes and plugins currently do around preview or default content?

Theme authors advertise how great their theme is or to upsell you on how great the pro version is.

Good theme authors will make their theme flexible enough to handle what to do when no content should be shown while defaulting to the user's existing content if possible.

[acosmin]

@greenshady What if that content doesn't exist and the only post the website has is "Hello World". Wouldn't it be nicer do display some "dummy content" and maybe let the user know where things are and how they can edit said content.

Again, I think we are talking only about themes designed for blogs. For more complex themes with (recommended plugins) there isn't a way to showcase extra features.

Basically, each theme released on .org is a blog theme which displays blog posts.

[greenshady]

Replying to acosmin:

@greenshady What if that content doesn't exist and the only post the website has is "Hello World". Wouldn't it be nicer do display some "dummy content" and maybe let the user know where things are and how they can edit said content.

A site visitor is not a "user" and definitely not an "administrator" (by default, only person allowed to manage options). Only someone with proper permissions should see that.

That's why I think, if setting up a system like what's being asaked about here in this ticket, the customizer is the best place for it, not the front end of the site for the whole world to see.

Again, I think we are talking only about themes designed for blogs. For more complex themes with (recommended plugins) there isn't a way to showcase extra features.

Basically, each theme released on .org is a blog theme which displays blog posts.

I've seen many themes where blogging is not a focus at all. I never assume we're working only with blog themes. I've worked with 1,000s of themes and sites in the 10+ years I've been doing WP and blogs are often irrelevant.

If we want to get rid of the requirement for accounting for WordPress' blogging features, that's a different topic. I'd love to see themes be able to do something like add_theme_support( 'blog' ) or something related to define whether they support a blog system. But, that needs to be handled in a different ticket because it's unrelated to this one.

[iandstewart]

I wanted to doublecheck on in my reading of this.

This content should not be injected into the database

— helen

the dummy content that hasn't been customized would need to be written to the database to ensure that what the preview shows when you "save and publish" is what the front end would then show

— celloexpressions

In the former idea it's preview only and, while the latter idea is only one option for dealing with the content, it sounds like an expansion that would potentially help set up someone's site, though the scope would be a bit wider there.

Is the idea here only to provide consistent previewing of a theme's potential? Or also to use that content to directly help with setup beyond being an example when a site is "fresh" without any edits beyond an about page and a Hello World post.

I've seen many themes where blogging is not a focus at all. I never assume we're working only with blog themes.

+1. A peek at the latest tab in the directory highlights how valuable it would be just to be able to sync up previews with theme demos.

[davidakennedy]

I wanted to share some of the default demo content used on a project somewhat similar on WordPress.com. There are other parameters in here, but most of it is content, and very basic:

<?php
$content = [
        [
                'post_title'     => 'About',
                'post_content'   => 'This is an example of an about page. Unlike posts, pages are better suited for more timeless content that you want to be easily accessible, like your About or Contact information. Click the Edit link to make changes to this page or <a href="https://wordpress.com/page">add another page</a>.',
                'post_excerpt'   => 'This is just a short excerpt for the about&nbsp;page.',
        ],
        [
                'post_title'     => 'Contact',
                'post_content'   => 'This is a contact page with some basic contact information and a contact form. [contact-form][contact-field label="Name" type="name" required="1"/][contact-field label="Email" type="email" required="1"/][contact-field label="Website" type="url"/][contact-field label="Comment" type="textarea" required="1"/][/contact-form]',
                'post_excerpt'   => 'This is just a short excerpt for the contact&nbsp;page.',
        ],
        [
                'post_title'     => 'First blog post',
                'post_content'   => 'This is your very first post. Click the Edit link to modify or delete it, or <a href="https://wordpress.com/post">start a new post</a>. If you like, use this post to tell readers why you started this blog and what you plan to do with it.',
                'post_excerpt'   => 'This is the excerpt for your very first post.',
        ],
];

// From elsewhere in the code, but more content.

return [
        [
                'post_title'     => __( 'Home' ),
                'post_content'   => __( 'Welcome to your new site!  You can edit this page by clicking on the Edit link.  For more information about customizing your site check out <a href="http://learn.wordpress.com/">http://learn.wordpress.com/</a>' ),
                'post_excerpt'   => __( 'This is the home page\'s excerpt' ),
        ],
        [
                'post_title'     => __( 'Blog' ),
                'post_content'   => __( 'This is the page where users will find your site\'s blog' ),
                'post_excerpt'   => __( 'This is just a short excerpt about your blog.' ),
        ],
];

Also, in terms of thinking of themes in types – as in each theme serves a primary use case, we at Automattic have created a new project that generates themes based on type right now: ​http://components.underscores.me/

The five types are the majority of the kinds of themes we build for WordPress.com and may be useful for thinking of how dummy content may be different depending on a theme's purpose.

[poena]

It was mentioned in chat last week that the demo content would only show if there isn't enough existing content.
But what about demo content for areas that are not posts or pages? I don't think I fully understand the idea behind this yet.
If we look at the previews it's often the custom front page that is the problem and not how the post content is displayed.

Would authors be able to combine the dummy content in any way they like?
Like would there be a list of headlines, images, icons, menus, widgets and content to choose from?

We don't want authors to be able to write their own texts, correct?

[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
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 ​Customize Posts feature plugin.

[poena]

This would solve some problems but from a reviewers perspective I am concerned that it would become another set of defaults that we need to review.

Would the added defaults overwrite the dummy content?

[matt]

Let's make decisions like this based on the end-user experience, not how it might impact reviewers, and how our review process arbitrarily happens to work at this point in time. Something like this is potentially very important in evolving how people experience themes and customization in WordPress.

[poena]

Yes, but I would rather see that the dummy content was not set by the theme developer, since this is
becoming a real problem.

[jcastaneda]

Just some thought from my personal years of reviewing themes:

What does the current default and fallback content landscape look like?

Not the greatest in that a lot will use a fallback to how great their theme is or even what the theme can do.

What do themes and plugins currently do around preview or default content?

Currently some themes set a default ( get_theme_mod( 'setting', 'This is an awesome theme' ) ) that can often require a user to edit a setting just to remove that. Not always ideal in certain situations. A lot of it is because it is information about the theme and what it can do or even what the "pro" version has to offer.

What kind of format should this take? (i.e. JSON for cross-language/context compat)

JSON is a potential one I could see being used for it.

How do we make this translatable/localization-friendly, i.e. making sure that content is not just translatable into another language but also is culturally relevant?

Avoid time specific events or things? Make it more a generalized content.

How might this impact the theme review team?

It shouldn't. Having a standardized method would actually help in seeing what the theme is actually doing with user content and what - if any - metadata it is trying to get and use. On a related note I actually haven't seen very many themes ( in the repo ) have support for custom fields plugins or even doing much with metadata.

Can this integrate with .org theme demos?

I don't see why it couldn't.

[karmatosed]

I am personally very keen to see something like this done. It's one thing us as the theme review team not allowing multiple, not so great ways of this. It's another us having one, core approach to this. We have to be flexible in our mindset and not just think or how this fits our current process. Things can change, things should change.

Sometimes it's hard to see what the experience is like outside our own experience, be that reviewer, theme developer or anyone else. There's a real issue with our current experience that this suggestion solves and we should focus on that.

[poena]

There is no disagreement on how badly this is needed, and I can't wait to try out solutions, but there hasn't been a lot of activity in the ticket. It is still very difficult to see how the dummy content would go together with the theme mods.

[helen]

Here's my general thought that was hashed out in a meeting a while back (sorry to take so long to document it here):

Core should provide a variety of content for theme authors to choose from. This would include things like media (hosted on .org perhaps?), business contact/hours for a text widget, sections of a multi-panel homepage, and so on as determined as necessary. We should look at default themes and perhaps a couple other very popular themes to see what kinds of content would best help those showcase their potential.

Some reasons for core providing a set of content are:

• Not adding (much) to the theme review tasks.
• A consistent experience for users as they preview/try out themes.
• Encouraging authors to best showcase their themes with content that inspires users, not put them off with advertising.
• Potentially be able to teach a bit about using WordPress through that content (e.g. instructions on editing/managing multi-part homepages).
• Provide translated/localized content in a sane way, and have a wide enough contributor base that the content is broadly understandable and not (too) culture-specific.

I think if we're smart about how we choose to implement this, the same content can be used to populate and do some amount of set up for .org previews even in their current state.

[karmatosed]

This may not be what works, but I was thinking for content we could either use or improve: ​https://github.com/WPTRT/theme-unit-test. That's sat for a while without iteration and perhaps this could be part of this and help both projects. Doesn't have to, but maybe an idea.

[westonruter]

Assuming that we have the data format in place to represent a set of dummy content (values for customizer settings, stored in a PHP array containing localized strings), is there a UI in mind for how the dummy/initial content would be selected? Would there be one set of dummy content setting that would be loaded with the theme, or would there be multiple sets of values to choose from (e.g. coffee shop, personal blog, school paper, etc)? If multiple, should there be a dropdown to choose from?

Also, should dummy content settings be able to override any existing settings that may already have values in their site? This is particularly a question for non-theme mods such as the static front page. If a user is showing latest posts on their homepage, should dummy/initial content be able to override this to supply a front page? I should think so.

[westonruter]

Also, in regards to:

This content should not be injected into the database, but rather appear during live previews (i.e. the customizer).

The way I envision this would work is that some of the content _would_ get injected into the database when needed, but it wouldn't be persistent. In other words, if posts/pages are included in the initial/dummy content then these would get created on the fly with the auto-draft status and only transitioned to publish if the changes are saved/published. If not, then these auto-draft posts would get garbage-collected after a week as normal.

[helen]

Replying to westonruter:

Assuming that we have the data format in place to represent a set of dummy content (values for customizer settings, stored in a PHP array containing localized strings), is there a UI in mind for how the dummy/initial content would be selected?

I'm imagining no UI (in core) - themes choose from a selection (which can be extended, but I would think that for .org themes they should be discouraged from doing so) that best showcases that theme. This perhaps disadvantages "do it all" themes, but I don't think that's a bad thing. :)

Also, should dummy content settings be able to override any existing settings that may already have values in their site? This is particularly a question for non-theme mods such as the static front page. If a user is showing latest posts on their homepage, should dummy/initial content be able to override this to supply a front page? I should think so.

So - possibly/probably, but later. Because I'm not thinking of much/any UI for this in core, I'm not sure it would be wise to allow that right away, as you'd likely want to prompt a user in a "this theme works best with a static front page, try it out?" sort of fashion. It is a huge hiccup in the theme set up process though, so if it seems like a reasonable thing to tackle once we have a basic swing in place, I'm up for it. See #19627.

The way I envision this would work is that some of the content _would_ get injected into the database when needed, but it wouldn't be persistent. In other words, if posts/pages are included in the initial/dummy content then these would get created on the fly with the auto-draft status and only transitioned to publish if the changes are saved/published. If not, then these auto-draft posts would get garbage-collected after a week as normal.

Sure, I was oversimplifying to make the point that it should not be something where activating a theme changes the content of your site without your explicit approval first :)

[westonruter]

Replying to helen:

I'm imagining no UI (in core) - themes choose from a selection (which can be extended, but I would think that for .org themes they should be discouraged from doing so) that best showcases that theme. This perhaps disadvantages "do it all" themes, but I don't think that's a bad thing. :)

So you're thinking that themes would fetch the dummy/initial content from WordPress.org rather than bundling the dummy/initial content inside the themes themselves? Or should both be possible?

So - possibly/probably, but later. Because I'm not thinking of much/any UI for this in core, I'm not sure it would be wise to allow that right away, as you'd likely want to prompt a user in a "this theme works best with a static front page, try it out?" sort of fashion. It is a huge hiccup in the theme set up process though, so if it seems like a reasonable thing to tackle once we have a basic swing in place, I'm up for it. See #19627.

I guess I'm having a hard time understanding the scope of what dummy/initial content is suppose to include. Is it just theme mods and any associated sideloaded images? Or is it also options, posts/pages, widgets, and nav menus? If only the former, then there's not the concern about overriding existing data: the injection of the dummy/initial content could be skipped if the theme mods not empty (meaning it was activated before). But to me it seems that limiting the initial/dummy content would be quite limiting in terms of providing users with a fully-configured initial site setup that they can then extend?

So if a theme does work best with a static front page and this static front page is also designed to have 3 widget areas, then I should think that when previewing this theme, these should be all configured and ready to go live if the user hits Save & Activate.

[helen]

Replying to westonruter:

So you're thinking that themes would fetch the dummy/initial content from WordPress.org rather than bundling the dummy/initial content inside the themes themselves?

I guess I'm having a hard time understanding the scope of what dummy/initial content is suppose to include. Is it just theme mods and any associated sideloaded images? Or is it also options, posts/pages, widgets, and nav menus? If only the former, then there's not the concern about overriding existing data: the injection of the dummy/initial content could be skipped if the theme mods not empty (meaning it was activated before). But to me it seems that limiting the initial/dummy content would be quite limiting in terms of providing users with a fully-configured initial site setup that they can then extend?

So if a theme does work best with a static front page and this static front page is also designed to have 3 widget areas, then I should think that when previewing this theme, these should be all configured and ready to go live if the user hits Save & Activate.

I'm thinking that core has a default set of content built right in to select from - therefore translatable, usable in other contexts if that proves to make sense, etc. I am not married to any technical implementation ideas around this, but let's say there's an array somewhere of various blobs of content - a widget with a type and various fields defined (e.g. a text widget with a title of "Find Us" and content containing address and email), common theme mods with certain values set, some images to choose from that can be sideloaded from somewhere (how sizing is handled, I don't know), some nav menu items (social ones, not sure if you'd actually provide page-based ones or if we could get smart with putting some in there), pages, and so on. As to whether this is limiting - I'd like to get an initial run of "how does this even work" with a couple of examples first and then go from there. I don't want to get stuck in a guessing game, and even if I have to drop this from 4.7, I want it sooner rather than later.

As far as existing data - if this is a fresh site, presumably there isn't much data there to scaffold with, so the local live preview should then reflect whatever ideal state (and if we do this right, the same state as the .org preview). I do agree that that something like a static page on front is a big part of that ideal state, I am just not sure we can tackle that in 4.7 when taking existing sites into account. Maybe we prioritize new sites and have the way existing sites do this work well enough for now (i.e. don't replace any content, show some starter content in areas that are new for a given theme), and keep working on that in the future.

[westonruter]

Feature plugin populates starter content in Twenty Seventeen including posts/pages, widgets, nav menus, theme mods (including panels), and options (static front page and page for posts): ​https://github.com/xwp/wp-trac-38114

[helen]

In discussing how we can dial this in for greatest chance of MVP success, it was decided to target "fresh sites". #38533 for how freshness is indicated.

[westonruter]

Please review and make additional revs via pushing to feature branch on GitHub. See PR: ​https://github.com/xwp/wordpress-develop/pull/188

[westonruter]

Apply patch via: git patch:https://github.com/xwp/wordpress-develop/pull/188

[westonruter]

In 38991:

Customize: Introduce starter content and site freshness state.

A theme can opt-in for tailored starter content to apply to the customizer when previewing the theme on a fresh install, when fresh_site is at its initial 1 value. Starter content is staged in the customizer and does not go live unless the changes are published. Initial starter content is added to Twenty Seventeen.

• The fresh_site flag is cleared when a published post or page is saved, when widgets are modified, or when the customizer state is saved.
• Starter content is registered via starter-content theme support, where the argument is an array containing widgets, posts, nav_menus, options, and theme_mods. Posts/pages in starter content are created with the auto-draft status, re-using the page/post stubs feature added to nav menus and the static front page controls.
• A get_theme_starter_content filter allows for plugins to extend a theme's starter content.
• Starter content in themes can/should re-use existing starter content items in core by using named placeholders.
• Import theme starter content into customized state when fresh site.
• Prevent original_title differences from causing refreshes if title is present.
• Ensure nav menu item url is set according to object when previewing.
• Make sure initial saved state is false if there are dirty settings without an existing changeset.
• Ensure dirty settings are cleaned upon changeset publishing.

Props helen, westonruter, ocean90.
Fixes #38114, #38533.

[westonruter]

In 38993:

Customize: Ensure that qunit test enters in expected state and tests wp.customize.dirtyValues in starter content context.

Fixes regression in [38991].
See #38114.

[westonruter]

In 38994:

Customize: Remove premature (and verbose) check of fresh_site option due to database not being ready on multisite.

Fixes regression in [38991].
See #38114.

[westonruter]

In 39038:

Customize: Prevent auto-draft post/page stubs from being saved with empty slugs or published with non-unique slugs.

• Allow WP_Customize_Nav_Menus::insert_auto_draft_post() to take full post array to pass to wp_insert_post(), except for post_status. Require post_title.
• Ensure empty post_name gets explicitly set to slugified post_title.
• Explicitly allow only post_type and post_title params in WP_Customize_Nav_Menus::ajax_insert_auto_draft_post().
• Use wp_update_post() instead of wp_publish_post() to ensure unique slugs are assigned to published auto-draft posts.
• Re-use WP_Customize_Nav_Menus::insert_auto_draft_post() when inserting stubs from starter content.

See #38114, #38013, #34923.
Fixes #38539.

[westonruter]

In 39100:

Customize: Prevent PHP warning in applying widget starter content on fresh installs.

Fixes PHP warning triggered by calling max() on $widget_numbers when there are no widget instances of the type yet. Also makes sure that widget instances start at 2 instead of 1.

See #38114.

[westonruter]

In 39241:

Customize: Allow starter content to apply in a new theme when switching from another theme containing changes.

• Ensure that starter content can apply from theme B after previewing starter content in theme A.
• Introduce new starter_content flag in changeset setting params which is used to capture whether a value is starter content and thus can be overridden.
• Create changeset up-front with starter_content flags instead of waiting for AUTOSAVE_INTERVAL.
• Eliminate instantiation of settings for widget instances in favor of directly calling sanitize_widget_js_instance. This eliminates issues with looking for widgets before they are registered.
• Ensure that non-placeholders (inline arrays instead of string references) can be supplied in starter content.
• Re-use auto-draft posts as starter content across theme switches.
• Introduce starter_content param for WP_Customize_Manager::save_changeset_post() which is false except when starter content is being loaded on a fresh_site.

See #38114.
Fixes #38541.

[westonruter]

In 39276:

Customize: Add unit tests for importing theme starter content.

Props welcher, westonruter.
See #38114, #38533, #38615.
Fixes #38540.

[westonruter]

In 39365:

Customize: Fix logic for previewing the URL for nav_menu_item settings for terms and post type archives.

Fixes typo in args passed to get_term_link() which caused a fatal error due to this call returning a WP_Error which was set to url. Also fixes never-satisfiable condition for obtaining post type archive URL. Also ensures that WP_Error never leaks through as url by setting it to an empty string. Adds missing unit tests.

Amends [38991].
See #38114.
Fixes #38945.

[westonruter]

In 39366:

Customize: Fix logic for previewing the URL for nav_menu_item settings for terms and post type archives.

Fixes typo in args passed to get_term_link() which caused a fatal error due to this call returning a WP_Error which was set to url. Also fixes never-satisfiable condition for obtaining post type archive URL. Also ensures that WP_Error never leaks through as url by setting it to an empty string. Adds missing unit tests.

Amends [38991].
See #38114.
Fixes #38945 for 4.7.

[westonruter]

In 39411:

Customize: Reuse existing non-auto-draft posts and existing auto-draft posts in the customized state with matching slugs when applying starter content.

• Updates wp_unique_post_slug() to ignore auto-draft posts. Prevents publishing multiple posts that have the same slugs from starter content.
• Fixes fatal error when attempting to save an header_image setting from a non-admin context.
• Fixes substituting attachment symbols in options and theme mods.
• Fixes applying starter content for header images and background images.

See #38114.
Fixes #38928.

[westonruter]

In 39412:

Customize: Reuse existing non-auto-draft posts and existing auto-draft posts in the customized state with matching slugs when applying starter content.

• Updates wp_unique_post_slug() to ignore auto-draft posts. Prevents publishing multiple posts that have the same slugs from starter content.
• Fixes fatal error when attempting to save an header_image setting from a non-admin context.
• Fixes substituting attachment symbols in options and theme mods.
• Fixes applying starter content for header images and background images.

Merges [39411] to 4.7 branch.
See #38114.
Fixes #38928 for 4.7.

[westonruter]

In 39502:

Customize: Prevent posts/pages imported via starter content from being dropped when adding post/page stubs via nav menus and the dropdown-pages control.

Props westonruter, dlh for testing.
See #38114, #34923.
Fixes #39071.

[westonruter]

In 39506:

Customize: Defer populating post_name for auto-draft posts in customized state until posts are published.

The ultimate post_name is stored in postmeta until the post is published. The get_page_by_path() function does not exclude auto-draft posts. Revert changes to wp_unique_post_slug() from [39411] which excluded auto-draft posts.

Props westonruter, dlh for testing, helen for testing.
See #38114, #38928.
Fixes #39078.

[westonruter]

In 39561:

Customize: Deprecate page_home nav menu item starter content in favor of home_link; replace usage in Twenty Seventeen.

Props celloexpressions, westonruter.
Amends [38991].
See #38615, #38114.
Fixes #39104.

[dd32]

In 39575:

Customize: Deprecate page_home nav menu item starter content in favor of home_link; replace usage in Twenty Seventeen.

Props celloexpressions, westonruter.
See #38615, #38114, [38991].
Merges [39561] to the 4.7 branch.
Fixes #39104.

[westonruter]

In 39924:

Customize: Allow custom post types to be used in starter content.

Changes WP_Customize_Nav_Menus::insert_auto_draft_post() so it can be invoked for a post_type that is not registered (yet).

See #38615, #38114.
Fixes #39610.

[dd32]

In 40098:

Customize: Allow custom post types to be used in starter content.

Changes WP_Customize_Nav_Menus::insert_auto_draft_post() so it can be invoked for a post_type that is not registered (yet).

Props westonruter.
Merges [39924] to the 4.7 branch.
See #38615, #38114.
Fixes #39610.

[westonruter]

In 40608:

Customize: Fix clearing of fresh_site option flag when editing sidebars on widgets admin screen.

Amends [38991].
See #38114, #38533.
Fixes #40722.

[westonruter]

In 41136:

Customize: Update Text widget starter content to utilize visual mode.

Amends [38991].
Props dlh, westonruter.
See #35243, #38114.
Fixes #41410.

[westonruter]

In 41137:

Customize: Update Text widget starter content to utilize visual mode.

Merges [41136] onto 4.8 branch.
Amends [38991].
Props dlh, westonruter.
See #35243, #38114.
Fixes #41410 for 4.8.1.

[desrosj]

Linking to the published dev note for reference: ​https://make.wordpress.org/core/2016/11/30/starter-content-for-themes-in-4-7/