3.6.0 changed when the list of supported post types is calculated, causing potentially unpredictable behavior

[benlk]

Description of bug

I've run into a problem where, for one specific custom post type on my client's site, the Coauthors metabox goes missing between 3.5.15 and 3.6.1., but the Coauthors column re-added in #1038 does appear for all custom post types that have authors post type supports.

The weirdness gets deeper: a custom post type registered with 'author' in the 'supports' of register_post_type() returns false with post_type_supports() under both versions of the plugin in the add_coauthor_box() method — and only for this one CPT, not for other CPTs in the same site. The difference in behavior is that 3.5.15's property $this->supported_post_types array contains the problematic CPT at that time, whereas 3.6.1's method $this->supported_post_types() returns an array array that does not contain the post type.

The difference, as far as I can tell, is:

Under 3.5.15:

• CoAuthors_Plus->supported_post_types is populated once per request, within the action_init_late function, which is hooked on init with priority 100
• CoAuthors_Plus->add_coauthors_box() is hooked on add_meta_boxes at the default priority
• CoAuthors_Plus->add_coauthors_box() calls CoAuthors_Plus->is_post_type_enabled() at that time
• CoAuthors_Plus->is_post_type_enabled() compares the post type from the global get_post_type() to the predefined $this->supported_post_types

Under 3.6.1:

• CoAuthors_Plus->add_coauthors_box() calls CoAuthors_Plus->is_post_type_enabled() at that time
• CoAuthors_Plus->is_post_type_enabled() compares the post type from the global get_post_type() to $this->supported_post_types()
• CoAuthors_Plus->supported_post_types() dynamically recalculates which post types are supported every single time it is called.

The add_meta_boxes action is run within register_and_do_post_meta_boxes(), which in wp-admin/edit-form-blocks.php runs when that template is loaded. That template is loaded by wp-admin/post.php after wp-admin/admin.php is loaded, which means it runs after init.

The ultimate cause of the behavior change between 3.5.15 and 3.6.1 is a filter on the CPT. This filter removes the author support from that CPT on init with priority 999 — after 3.5.15 populates the $this->supported_post_types filter, but before 3.6.1 runs $this->supported_post_types() when rendering the metabox. The reason for this removal is that we wanted to have the support at one point, but not have the metabox appear. I'm not sure why that was ever needed, or why we didn't care that the metabox was actually appearing on the site under 3.5.15. It doesn't matter; I've fixed the problem on my site by adding this CPT in the coauthors_supported_post_types filter.

I want to flag that CoAuthors_Plus->supported_post_types() is being called hundreds of times per page load. On a sample Block Editor page load on my local, the function is called over 500 times in a single request, and the Block Editor has several other requests which get into the low dozens. I don't think this plugin needs to dynamically recompute the list of supported post types.

---

tl;dr: 3.6.0 changed when in the page load the question of whether a post type is supported occurs, from evaluated once upon init at priority 100, to being dynamically evaluated many times in different contexts.

Requested change

Following on discussion in #1033, I think that the one-time init from #1036 is a better solution than the one-off exception in #1038. The reasons are:

• Fix supported post types to solve missing Authors column #1036 calculates the list of supported post types once per page load, at the init action, in the new init_supported_post_types() method. This improves predictability of whether any given Co-Authors Plus function will be enabled in that request, because all Co-Authors Plus features will be operating off the same information.
• Fix supported post types to solve missing Authors column #1036 reduces the number of times that the supported post types list is calculated, reducing server load and maybe slightly improving page load times. The performance improvement may be slight; on a sample uncached page load for the main post.php?post=1234&action=edit request received a complete response from my local development server with a difference of +-1 second between the plugin versions, with total page load time in both cases of over 20 seconds in all runs. I haven't run formal profiling tools against this.

[douglas-johnson]

@GaryJones @alecgeatches What do you think about re-opening the pull request #1036 as a solution to this issue?

I still think #1038 was a good solution for hiding the WordPress core author selection in quick edit, but I think these two changes can co-exist.