Unnecessary code in wp.getPage

[nprasath002]

Pages Does not have categories

[F J Kaiser]

But categories can be added to pages.

[DrewAPicture]

Replying to F J Kaiser:

But categories can be added to pages.

Agreed. On one of my sites, pages rely on categories to display specific posts from said categories. At the time it was in deference to creating a new custom post type.

[F J Kaiser]

I close it now as I think there are enough use cases for this left.

[nacin]

We could wrap this into a post_type_supports check and save the queries.

[F J Kaiser]

Replying to nacin:

We could wrap this into a post_type_supports check and save the queries.

Would this add any performance in- or decrease?

[markoheijnen]

Now there is wp_getPost. I recommend using that instead of wp_getPage. That said I'm not sure how to use post_type_supports. There isn't one for categories, right?

Weird thing is that we expect only categories and not tags or custom taxonomies. I think we should copy the stuff from _prepare_post to _prepare_page and that will solve the issue with a fallback for categories

[markoheijnen]

Wonder if we can inherit most of the getPost functionality in getPage.

[markoheijnen]

Created a new patch that adds a is_object_in_taxonomy() check. It will prevent one query like this one:

SELECT t.term_id FROM wp_terms AS t INNER JOIN wp_term_taxonomy AS tt ON tt.term_id = t.term_id INNER JOIN wp_term_relationships AS tr ON tr.term_taxonomy_id = tt.term_taxonomy_id WHERE tt.taxonomy IN ('category') AND tr.object_id IN (2) ORDER BY t.name ASC

Moving to 4.1 for consideration.

[SergeyBiryukov]

In 29731:

XML-RPC: Check if category support was added for pages before calling wp_get_post_categories() to avoid unnecessary query in wp.getPage.

props markoheijnen, nprasath002.
fixes #17920.