I've been digging into this issue and there are a number of inconvenient truths that have led us here:
The core WP List Table implementation has barely any (possibly zero) actions available for us to modify the core features. In order to remove the core author feature from the Quick Edit box, we have to trick WP into skipping it by using remove_post_type_support() for the author feature.
The Co-Authors Plus post type support feature uses the same hard-coded value as the taxonomy name, which is also author. So, when we remove_post_type_support() for the core author feature, we're also removing post type support for CAP itself. (Aside: This whole setup kinda makes sense, because CAP will work, by default for new post types that support author, but also causes a number of chin-scratching scenarios.)
A recent change was made to add a supported_post_types() method to clean up some testing and best practices issues. Unfortunately, it relies on post_type_supports(), so any calls to it, after the workaround in Item 1, fail to return the post type for the current edit page.
This commit fixes that issue by changing the supported_post_types() method to get its value from the $supported_post_types property on the class. The post_type_supports() call and post types filter are moved to an init_supported_post_types() method that only runs when the $supported_post_types property is empty. This way, any call to $this->supported_post_types() will not be influenced by the post type support fudging happening behind the scenes.
Side note:
I think there should probably be a separate discussion about changing the CAP post type support feature name to co-authors. It would likely eliminate a number of unnecessary overlap issues. There would just need to be a function written to automatically add co-authors support to any post type supporting author. Then, we could possibly just remove author support at that stage, and be able to remove some of the overlap workarounds in the rest of the plugin.
Deploy Notes
I created this branch from the 3.6.0 tag, instead of the main develop branch, and that has made the Commits tab look a little weird. I'm not sure if this is the best way to handle it. Let me know if I should start over from develop and re-submit the PR.
No new dependencies or complex considerations here. Just possibly a discussion to be had about whether this approach is the best solution.
Description
This solves https://github.com/Automattic/Co-Authors-Plus/issues/1033
I've been digging into this issue and there are a number of inconvenient truths that have led us here:
authorfeature from the Quick Edit box, we have to trick WP into skipping it by usingremove_post_type_support()for theauthorfeature.author. So, when weremove_post_type_support()for the coreauthorfeature, we're also removing post type support for CAP itself. (Aside: This whole setup kinda makes sense, because CAP will work, by default for new post types that supportauthor, but also causes a number of chin-scratching scenarios.)supported_post_types()method to clean up some testing and best practices issues. Unfortunately, it relies onpost_type_supports(), so any calls to it, after the workaround in Item 1, fail to return the post type for the current edit page.This commit fixes that issue by changing the supported_post_types() method to get its value from the
$supported_post_typesproperty on the class. Thepost_type_supports()call and post types filter are moved to aninit_supported_post_types()method that only runs when the$supported_post_typesproperty is empty. This way, any call to$this->supported_post_types()will not be influenced by the post type support fudging happening behind the scenes.Side note: I think there should probably be a separate discussion about changing the CAP post type support feature name to
co-authors. It would likely eliminate a number of unnecessary overlap issues. There would just need to be a function written to automatically addco-authorssupport to any post type supportingauthor. Then, we could possibly just removeauthorsupport at that stage, and be able to remove some of the overlap workarounds in the rest of the plugin.Deploy Notes
I created this branch from the 3.6.0 tag, instead of the main
developbranch, and that has made the Commits tab look a little weird. I'm not sure if this is the best way to handle it. Let me know if I should start over fromdevelopand re-submit the PR.No new dependencies or complex considerations here. Just possibly a discussion to be had about whether this approach is the best solution.
Steps to Test