New conditional tags for child/parent pages

[ramiy]

New enhancements for theme developers with new conditional tags:

• has_parent() - return boolean result using $post->post_parent.
• parent_page() - return the parent page id using $post->post_parent.
• is_child_of( $id ) - return boolean result using $post->post_parent.

We can change the names, but we need the functionality.

[ramiy]

See the patch.

[ramiy]

For consistency, the patch is based on the code of has_excerpt() and get_the_excerpt() functions.

[johnbillion]

@ramiy What's the use case for filtering the return value of get_parent()?

Also these functions need post in their name to avoid ambiguity. eg. wp_get_post_parent().

[sebastian.pisula]

I added my version of patch

[ramiy]

Replying to johnbillion:

@ramiy What's the use case for filtering the return value of get_parent()?

Also these functions need post in their name to avoid ambiguity. eg. wp_get_post_parent().

You are right, there is no reason to filter the returned value. @sebastian.pisula revised my patch, he removed the filter and added the required post to the function name.

[nir_r]

+1 for this feature

[ramiy]

Actually,

I don't agree with the new function name wp_get_post_parent(),
I prefer it would be get_post_parent(), without the wp_ prefix.

We should stick with the naming conventions in post-template.php, non of the get functions use the wp_ prefix:

• get_the_ID()
• get_the_title()
• get_the_guid()
• get_the_content()
• get_the_excerpt()
• get_post_class()
• get_body_class()

[maor]

Love these functions! Great idea.

I actually just wrapped up a project where these functions could have been super helpful if existed.

Also, I agree with @ramiy on the naming convention. IMHO, I think there shouldn't be a wp_ prefix for the proposed conditional tags.

[ramiy]

Same logic can be applied for the boolean function, rename back from has_post_parent() to has_parent().

The other has_() functions don't use the post in their name:

• has_excerpt()
• has_tag()
• has_term()
• has_nav_menu()

Only one function use post in the name:

• has_post_thumbnail()

[ramiy]

@SergeyBiryukov Let's add this enhancement to 4.9. The ticket has a patch, it was tested and got a very good feedback from @johnbillion and @sebastian.pisula.

The only issue here was the function names. In the last patch I applied the naming conventions set in post-template.php to match similar template functions.

[johnbillion]

I've decided these functions should be named get_parent_post() and has_parent_post(). The "parent post" is the object being gotten.

This also allows functions such as get_parent_term() to be introduced in the future in order to fetch a term's parent.

[johnbillion]

And just as I submitted that I questioned it. Maybe it needs to be get_parent_post_id(). Naming things is hard.

[SergeyBiryukov]

For reference, comment:28:ticket:24164 has a good overview of existing get_*() and the_*() template functions.

Until a new function is added, get_post_field( 'post_parent', $post ) could be used for the same purpose.

[ramiy]

The last patch uses "short if" to match the code to get_the_ID().

[birgire]

In 33045.6.patch​ for the has_post_parent() docs, there's currently:

* @return int

but it should be:

 * @return bool

Regarding the naming, I would assume beforehand that get_post_parent() would return a WP_Post object, just as get_post().

But beside from that, we already have this function in core:

/**
 * Returns the ID of the post's parent.
 *
 * @since 3.1.0
 *
 * @param int|WP_Post $post Post ID or post object. Defaults to global $post.
 * @return int|false Post parent ID (which can be 0 if there is no parent), or false if the post does not exist.
 */
function wp_get_post_parent_id( $post ) {
        $post = get_post( $post );
        if ( ! $post || is_wp_error( $post ) ) {
                return false;
        }
        return (int) $post->post_parent;
}

See ​https://developer.wordpress.org/reference/functions/wp_get_post_parent_id/

[audrasjb]

Moving for 5.7 consideration

[audrasjb]

New iteration

[audrasjb]

Hi there,

33045.7.diff is a new iteration for this ticket:

• @since docs update
• get_post_parent() now returns parent post object
• few DocBlock enhancements

[audrasjb]

As Core Tech Lead for 5.7, @SergeyBiryukov, what's your feeling about those changes? I think it's pretty neat but feel free to take ownership on the ticket for proper review before the end of the alpha cycle ;)

[johnbillion]

These need tests. The functions in the latest patch do not work as expected.

[joyously]

I don't think the function names should have 'post' in them, because the standard Post is not hierarchical.
These functions don't seem very useful either, as we've gone more than 15 years without them just fine.

[ramiy]

Thank you @xkon, love the new checks you added, looks much better.

[xkon]

Hey @ramiy, thanks but I've re-uploaded 33045.8.diff​. It seems that they where not really needed as get_post() takes care of it as it seems on it's own either way, so I reverted to the original :) with the minor fix mentioned below.

@audrasjb I took a look on 33045.7.diff​ and instead of returning $post->post_parent it was returning $post again in get_post_parent() so it wasn't working as expected.

I'll try to work on unit tests as well to get this ready :). It should be good now though.

[xkon]

33045.9.diff​ adds unit tests, also renames the functions into has_parent_post() & get_parent_post() as mentioned by @johnbillion in comment 18 as it makes more sense.

I believe this is ready for a review if I didn't miss anything extra from the previous comments.

[audrasjb]

Thanks for the new patch and for adding unit tests.
I think we're ready for 5.7 beta 1 👌

[johnbillion]

This looks good. 33045.diff​ just tweaks the docs and switches to using the post factory in the tests.

One remaining concern that I haven't seen mentioned yet is whether any existing plugins or themes already define either a get_parent_post() or has_parent_post() function. If they do, a fatal error will occur in 5.7.

I checked the plugin and theme directories and (amazingly?) only one plugin is affected,​Revisionize with 6,000 active installations, and it defines the get_parent_post() function. No themes are affected.

I think we can reach out to the plugin author and ask them to update the plugin with a function_exists() check. If it's absolutely necessary we can ask the plugin team to push out an update with that change before 5.7.

Unless anybody disagrees, I'll commit this this evening.

[audrasjb]

Good point @johnbillion. I just opened a pull request on their GitHub repository and a thread on their support forum :)

• ​https://github.com/jamiechong/revisionize/pull/48
• ​https://wordpress.org/support/topic/urgent-prevent-fatal-error-in-wordpress-5-7/

[johnbillion]

In 50127:

Posts, Post Types: Introduce new functions for determining if a post has a parent (has_post_parent()) and to fetch the post parent (get_post_parent()).

These functions are simple but reduce the logic needed in themes and plugins.

Props ramiy, sebastian.pisula, birgire, audrasjb, xkon

Fixes #33045

[johnjamesjacoby]

Hey @johnbillion!

These functions are named weird. 😕

Your commit message uses post_parent() but the functions that were committed use parent_post().

I’ve read all of the comments in this ticket, and see it’s gone back and forth until you put your foot down 3 years ago, but then your commit message hilariously inverted them, and my intuition tells me that post-parent is more natural than parent-post.

If left as-is, I think it is highly likely that everyone until the end of time is going to get these function names wrong in their code-editor auto-completes.

I.E. I would never think to type get_status_post and I’ll never remember to type get_parent_post.

Thoughts?

[johnbillion]

Naming things is hard.

[SergeyBiryukov]

Replying to johnjamesjacoby:

I’ve read all of the comments in this ticket, and see it’s gone back and forth until you put your foot down 3 years ago, but then your commit message hilariously inverted them, and my intuition tells me that post-parent is more natural than parent-post.

I also went back and forth on this when reviewing the commit :) I guess get_post_parent(), for consistency with the post_parent field, would indeed be preferable here.

[lukecarbis]

This is a really hard call, but I also like the consistency with the post_parent field. I'm on board with get_post_parent() and has_post_parent().

https://core.trac.wordpress.org/ticket/33045

[peterwilsoncc]

I've set up a pull request ​renaming these to *_post_parent(). I'm happy with those as names too, click approve/request changes on the PR to express an opinion either way.

[johnbillion]

Checking the plugin and theme directories:

• ✅ get_post_parent for plugins ​ref
  • Four matches, all four are class methods
• ✅ get_post_parent for themes ​ref
  • No matches
• ✅ has_post_parent for plugins ​ref
  • No matches
• ✅ has_post_parent for themes ​ref
  • No matches

[johnbillion]

In 50396:

Posts, Post Types: Rename the new post parent conditional tag functions for clarity.

• get_parent_post() becomes get_post_parent()
• has_parent_post() becomes has_post_parent()

Props johnjamesjacoby, SergeyBiryukov, lukecarbis, peterwilsoncc

Fixes #33045

[prbot]

​johnbillion commented on ​PR #1017:

https://core.trac.wordpress.org/changeset/50396

[johnbillion]

Dev note has been updated: ​https://make.wordpress.org/core/2021/02/10/introducing-new-post-parent-related-functions-in-wordpress-5-7/