Starter content: Allow for setting a "parent" for pages (and other hierarchical CPTs)

[webmandesign]

From what I can see in ​get_theme_starter_content() function, it only allows for specific fields to be set for posts: post_type, post_title, post_excerpt, post_name, post_content, menu_order, comment_status, thumbnail and template.

I would like to propose adding a parent field in there too for hierarchical post types, such as Pages.

That way we can also create child pages (or sub-pages) in starter content, such as:

<?php
$starter_content = array(

  'posts' => array(

    'contact' => array(
      'template' => 'page-templates/list-of-child-pages.php',
    ),

    'contact-dublin' => array(
      'post_type'    => 'page',
      'post_title'   => 'Dublin Office Contact',
      'post_content' => 'Page content here...',
      'parent'       => '{{contact}}', // <-- Here's the magic:
                                       //     Making this a child page of our "Contact" page.
    ),

  ),

);

Thanks for consideration!

[westonruter]

Good call. Yes, this makes great sense.

[birgire]

Sounds like a good idea.

Here's a first attempt to support setting a parent post symbol.

In 40807.patch​

• Translate the parent post symbol to an ID and assign it to the post_parent field with wp_update_post()
• Uses the parent key for symbols, to not confuse it with post_parent that only supports an integer value.
• Includes a test, based on the existing one for starter-content

[birgire]

In 40807.2.patch​

• Added a deeper test config tree
• Added a failing (non-existing) parent post symbol
• Use get_post_field() to get the post_parent field.

To consider:

• Add a hierarchical post type restriction on posts using the parent
• Add a same parent/child post type restriction on posts using the parent

[westonruter]

Δ ​https://github.com/xwp/wordpress-develop/pull/276/commits/0bfc4dc

[westonruter]

@birgire patch is looking good! I don't think we need to worry about restricting which post types can have children. I think this hierarchical property is really more for the sake of the UI than a restriction on the data model. After all, an attachment post can have parent even though it isn't hierarchical.

See my ​changes for what needed to be done to apply ​WordPress-Coding-Standards. It was mostly whitespace changes; see ​diff without.

A build is running now: ​https://travis-ci.org/xwp/wordpress-develop/builds/284338738

While this was marked as an enhancement, I'm inclined to include it in 4.9 as it is closely related to #39254.

[birgire]

Thank you @westonruter for the whitespace cleanup and the other info.

I will consult the phpcs --standard=WordPress ... when writing patches from now on ;-)

I agree with your reasoning regarding the consideration of the two restrictions.

[birgire]

It looks like I forgot the {{...}} syntax, in the previous patch.

In 40807.4.diff​ we assume the parent reference to be like:

'animal' => array(
    'post_type'  => 'page',
    'post_title' => 'Animal',
),
'fish'   => array(
    'post_type'  => 'page',
    'post_title' => 'Fish',
    'parent'     => '{{animal}}',
),

[westonruter]

Punting this to the next minor release along with #39254, due to the number of outstanding tickets and lack of availability to focus on this.

[benoitchantre]

I haven't tested the patch, but I would like to mention that it would be great to support sub menu items.

[pento]

It'd be a good to show a practical use for this.

[webmandesign]

@pento Practical use example:
In my ​Reykjavik theme I provide a special page template that displays a list of child pages. There is no way I can build a starter content to show this feature now.

Here is an example of how a child pages list page template look like: ​https://themedemos.webmandesign.eu/reykjavik/services/ (scroll down to see the list of child pages for that particular parent page).

[westonruter]

New feature development is being directed toward the Site Editor, so I'm closing this.