Allow `wp_count_posts()` on multisite after switching sites

[flixos90]

When switching sites on a multisite, there can be problems when using wp_count_posts():

Let's say you are on site X and site Y has a post type 'event' registered while site X does not have it. When you switch from X to Y using switch_to_blog() and then call wp_count_posts( 'event' ), there won't be any results since this post type does not exist on site X and since it's not possible to register post types per sites when switching between sites.

I think we should only make the post_type_exists() control call when we can ensure that we've not switched sites. The function will still work properly without it. And since we can still correcly get_posts() of such a post type after switching sites, we should be able to also use wp_count_posts() correctly.

[flixos90]

patch to fix wp_count_posts() on multisite after switching

[flixos90]

The above patch fixes the problem. The one thing that is still not possible by using it is to also include private posts in the count. I'm not sure if this can be properly fixed at all using the current system though.

[ocean90]

Can you tell us your use case for this? Why are you trying to count posts of a post type which doesn't exist?

[flixos90]

Replying to ocean90:

Can you tell us your use case for this? Why are you trying to count posts of a post type which doesn't exist?

I'm running a script which indexes all content on a WordPress multisite into Elasticsearch, content of different post types and such. This script iterates through the entire network (makes indexing requests with AJAX) and therefore it needs to retrieve all posts of all the post types that I need to index.

However there are some post types that only exist on site A and others that only exist on site B. Thus, when I run the script from site A (and switch to B to index its content), it will get back a count of 0 for all post types from B that do not exist in A.

[dd32]

FWIW, I'm not sure we should support this (even if we technically can) as it introduced an inconsistency in the CPT API.
We end up with a situation where some functions work without the post type registered, whereas others don't.

Many other API's could also technically support querying without registration, including WP_Query, however when a CPT becomes more complex than a simple copy of the post format such as having plugin conditionals on queries, altering SQL, adding permission checks, etc we get to a position where we currently are - if the plugin which registers the CPT isn't active, we effectively can't be sure that the functions will handle the same.

[flixos90]

Replying to dd32:

FWIW, I'm not sure we should support this (even if we technically can) as it introduced an inconsistency in the CPT API.
We end up with a situation where some functions work without the post type registered, whereas others don't.

I see that it brings inconsistencies, but on the other hand it enhances functionality. Since many parts of WordPress were built before Multisite was a thing, it's almost impossible to make it fully compatible (without breaking backwards compatibility). I personally would however prefer inconsistent solutions over leaving those areas untouched. Furthermore, regarding compatibility in this specific case, I actually was able to query posts of a non-existent post type using get_posts(), but I was not able to get the post count using wp_count_posts(), so it seems there already is inconsistency there - not that this would justify my cause, but I wanted to mention it.

The alternative for me is to hack around that problem as long as this is not supported, but like I said, I would prefer it being solved in Core. It is probably an edge-case at the moment - yet I think it shouldn't be ignored.

[flixos90]

I think we can close this one for now. With the current implementation it doesn't make sense to hack around to fix this problem, and it's also edge-case. So maybe later. :)