[wp-trac] [WordPress Trac] #62953: Add post_ancestor as query var to WP_Query class

[WordPress Trac]

#62953: Add post_ancestor as query var to WP_Query class
-------------------------+-----------------------------
 Reporter:  bbpaule      |      Owner:  bbpaule
     Type:  enhancement  |     Status:  assigned
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  Query        |    Version:  trunk
 Severity:  normal       |   Keywords:
  Focuses:  rest-api     |
-------------------------+-----------------------------
 Issue on Gutenberg:
 - https://github.com/WordPress/gutenberg/issues/54461

 More specifically, have a look at the last few paragraphs of this comment:
 -
 https://github.com/WordPress/gutenberg/issues/54461#issuecomment-2608989671



 == What
 Add `post_ancestor` as a query var to the WP_Query class.  This var should
 accept a page id and will fetch all descendants of that page from the
 database.


 == Why
 I'm working on adding a toggle to the Gutenberg editor that shows ''all''
 descendants (not just the direct children) of the current page (see link
 to GitHub comment above).  Currently the WP_Query class only allows you to
 fetch the direct children of a list of pages through the use of either
 `post_parent` or `post_parent__in`.


 == Recommend Approach

 - In the WP_Query class, add `post_ancestor` as one of the query props.
 - If `post_ancestor` is present then the `post_parent` and
 `post_parent_in` props should be ignored.
 - The query should get 'all' pages from the database.
 - Then filter out the descendant pages using `get_page_children` (docs:
 https://developer.wordpress.org/reference/functions/get_page_children/).

 == Other approaches
 Instead of `get_page_children`, we could loop over the page hierarchy and
 execute a different sql query for every depth we need to fetch children
 from. (So one sql query would fetch the direct children of the parent, a
 second sql query would fetch the children of those children, etc, etc).
 - Each post/page has a `post_parent` property in the db.  So it's very
 easy to get the direct children of  a page but getting the grandchildren
 is more difficult and requires something similar to the algorithm defined
 above.

 == Discussion
 Are people happy with my recommended approach?  I'm happy to do this
 ticket myself.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/62953>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform