Static Front Page section/controls should be contextual and allow assignment to page stubs

[westonruter]

With the introduction of the ability to add new page stubs via Nav Menu Items (#34923) this also brings focus to the Static Front Page. If there are no created published pages, the registration of this section and its controls is skipped entirely (checking get_pages()). However, since a page (stub) can actually be created inside the customizer, it would stand to reason that this newly created page should also be able to be assigned as the static front page or page for posts.

There are a few part to this:

1. Register static_front_page section and controls regardless if there are published pages, and add active_callbacks that return true if 0 !== count( get_pages( 'number' => 1 ) )
2. Sync the page stubs created via nav menus into the dropdown-pages controls for page_on_front and page_for_posts.
3. And then lastly there is providing a seamless way to actually edit the content of these pages that get assigned to the homepage or the page for posts. See #38002 (Customize: provide a path to editing posts created in nav menus)

Related: #16379 (Better UI for doing "Page on Front")

[westonruter]

38013.0.diff​ implements the contextual (active callback) part, mostly.

The second part (syncing the created pages to the page_for_posts and page_for_posts controls) is facilitated by the control in the ​Customize Object Selector feature plugin:

Note that the Object Selector Control also integrates with ​Customize Posts in that it will display a “Add New” button which will cause a new page to be created and allow you to edit its fields right in the customizer. Collapsing the section for the newly-created page brings you back then to the static front page control with the newly-created page then selected.

So too, the Customize Posts will provide a way to edit page stubs created in the customizer. (See ​wp-customize-posts#253).

[westonruter]

Polyfill added to the Customize Posts plugin in ​https://github.com/xwp/wp-customize-posts/pull/254/files

[celloexpressions]

We should tackle this in 4.7 to build on the ability to make page stubs with menus. Ideally, we'd be able to use the same functions and primarily focus work here on integrating it with this particular UI. This is also important for Twenty Seventeen.

It sounds like we can take 38013.0.diff​ and add an additional control to add a new page (perhaps matching the UI from menus with a visible input + button, with the button adding to the select element and hiding the input).

[westonruter]

In 38013.1.diff​:

• Activate Static Front Page controls when a new page stub is created.
• Ensure that dropdown-pages control gets a select even if there are no pages created.
• Add newly-created page stubs to dropdown-pages controls.
• Remove active_callback from section to inherit contextual active state from controls.

[westonruter]

In 38013.2.diff​, switch to letting static_front_page section be contextual rather than the controls. This makes sense because if there aren't any pages then the “Static Front Page” section shouldn't be there. It also improves compatibility with when the page_on_front and page_for_posts controls get proper active_callbacks themselves. See #29948.

[westonruter]

Harden selector for select element

[westonruter]

As also noted on #38002, here's a Customize Posts integration with the dropdown-pages control:

Notice the edit and create buttons.

Pull request that includes this code: ​https://github.com/xwp/wp-customize-posts/pull/272

[westonruter]

Fix has_published_pages to actually check post type being equal to page

[celloexpressions]

38013.4.diff​ looks ready to commit for adding page stubs to these selects and making them contextual to having pages.

I think we should also look at the ability to add new auto-draft pages here in this ticket, or a new one for 4.7. We should try to keep that separate from the Select2 work for now if possible. It sounds like #16379 is not a good place to pursue that work.

[westonruter]

In 38624:

Customize: Let static_front_page section be contextually active based on whether there are any published pages.

If there are no pages when the customizer is opened, the static_front_page section will be hidden. As soon as a page is created in the customizer session, the static_front_page section will be revealed. Previously the section would not be registered if there were no pages. Page stubs created via nav menus will appear in the dropdown-pages controls for page_for_posts and page_on_front, and such page stubs will thus cause the static_front_page section to appear. Plugins that facilitate page creation in the customizer by filtering get_pages will also cause the section to appear.

See #34923.
Fixes #38013.

[westonruter]

In 38906:

Customize: Allow page stubs to be created via dropdown-pages controls in the Static Front Page section.

This ability was previously added to nav menus via the available page items panel. The "Add New Page" button only appears when the allow_addition control param is supplied as true. Code is adapted from the Customize Posts feature plugin.

Props celloexpressions, westonruter.
See #38013, #34923.
Fixes #38164.

[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.