Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Authors now missing from the Posts list table after 3.6.0 update #1033

Closed
justinmaurerdotdev opened this issue Apr 22, 2024 · 6 comments · Fixed by #1038
Closed

Authors now missing from the Posts list table after 3.6.0 update #1033

justinmaurerdotdev opened this issue Apr 22, 2024 · 6 comments · Fixed by #1038
Milestone

Comments

@justinmaurerdotdev
Copy link

justinmaurerdotdev commented Apr 22, 2024

I've been working on an issue related to Co-Authors Plus with the WP List Table at wp-admin/edit.php?post_status=publish&post_type=post and I just saw there was an update. I went ahead and updated my local environment and noticed that the Authors column is completely missing. Weirdly, the regular Author column is also missing. I seemingly don't have any way to see the author for a post before I click to edit.

I checked the code that I had previously been working with and noticed it's entirely missing from the updated plugin. Here's a link to the filters I was working with before, that appear to do at least part of the admin column handling: https://github.com/Automattic/Co-Authors-Plus/blob/33ae3b0c8adf54f0ad193caa5fa13f166fcc4ddc/co-authors-plus.php#L265C1-L268C100

It's not just the filters missing. The functions are also gone. Was this intentional? Am I missing something?

Edit: I figured out that PHPStorm's index had not fully updated so the search function hadn't found the new class yet. That said, I am still missing the Author/Authors column in the Posts table and not sure why.

@justinmaurerdotdev
Copy link
Author

justinmaurerdotdev commented Apr 22, 2024

I was able to determine that, on 3.6.0, all of my post types are failing the is_post_type_enabled() check here: https://github.com/Automattic/Co-Authors-Plus/blob/586e803589a5d3f86de6f04a8391385529b3fbbe/php/class-coauthors-plus.php#L508C1-L508C43.

After rolling back to 3.5.15, the authors column re-appears. My best guess is that there's some way that this remove_post_type_support() call is happening at the wrong time in the refactored plugin or something:

remove_post_type_support( get_post_type(), $this->coauthor_taxonomy );

@shelb-elliott
Copy link

Commenting to add that Newspack has received several reports of this from our publishers.

@douglas-johnson
Copy link
Contributor

Seems related to this #1006

and specifically ! post_type_supports( $name, 'author' ) on this line
https://github.com/Automattic/Co-Authors-Plus/blob/3.6.0/php/class-coauthors-plus.php#L269

Because remove_quick_edit_authors_box does remove_post_type_support( get_post_type(), $this->coauthor_taxonomy ); as an action on admin_head, subsequent calls to supported_post_types() won't include the current post type.

https://github.com/Automattic/Co-Authors-Plus/blob/3.6.0/php/class-coauthors-plus.php#L496C4-L496C74

@justinmaurerdotdev
Copy link
Author

My above PR fixes this. I'm not sure if it's the solution that everyone will want/agree on, but it does fix the issue.

@douglas-johnson
Copy link
Contributor

One idea for consideration:

  • The author dropdown isn't displayed if wp_dropdown_users( $args ) returns an empty string.
  • It will return an empty string if the user query returns an empty array.
  • We can force it return an empty array by changing $args to include only the user ID 0 which doesn't exist.
  • We can target the $args specific to Quick Edit using the filter quick_edit_dropdown_authors_args

So in remove_quick_edit_authors_box we could replace this

remove_post_type_support( get_post_type(), $this->coauthor_taxonomy );

with roughly this

add_filter(
  'quick_edit_dropdown_authors_args',
  fn() => [ 'include' => [0] ]
);
			

@GaryJones
Copy link
Contributor

@justinmaurerdotdev @douglas-johnson Thank you both for diving into this - so very helpful.

I reviewed the (nicely documented) PR from @justinmaurerdotdev, but to keep things simple, I've gone for the more targetted and simpler approach suggested by @douglas-johnson and created #1038. I'd love it if you could both give it a test and see if that seems to be working as intended please.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants