Automattic / wp-calypso

The JavaScript and API powered WordPress.com
https://developer.wordpress.com
GNU General Public License v2.0
12.4k stars 1.98k forks source link

Posts: enable the Me/Everyone filter for Jetpack sites #2132

Open designsimply opened 8 years ago

designsimply commented 8 years ago

Raised by @rralian

Steps to reproduce:

  1. Log in to https://wordpress.com/ to an account that has both a Jetpack and WordPress.com blog, each with multiple authors
  2. Click "Blog Posts" in the left menu on the Jetpack blog
  3. Click "Blog Posts" in the left menu on the Jetpack blog
  4. Compare the header on each of those pages

Result: a WordPress.com multi-author blog has segmented control for viewing posts by "Only Me" or by "Everyone" while the Jetpack multi-author blog does not have the same segmented control.

WordPress.com multi-author blog:

screen shot 2016-01-05 at 16 27 14

Jetpack multi-author blog:

screen shot 2016-01-05 at 16 26 21

Also see 2897-gh-calypso-pre-oss and 547-gh-io

lancewillett commented 6 years ago

A team on Delta is going to take this on in Q1 2018.

dllh commented 6 years ago

This came up in #1101973-z. It's a pretty bad experience on a site with many authors and posts. In this case, the site has 10k posts and dozens of authors. An author can go to /posts/my to see their own posts, but this isn't ideal if they have multiple sites. When I go to /posts/my/domain.com for the site in question, it also just redirects to /posts/domain.com, so that's not a valid way of hacking to get around the missing UI. So a user in this case can basically search for posts (not a good option if, say, their name is a common name appearing in post content) or they can go into wp-admin to see a filtered list. Impact on the experience in other words is very high for users in this scenario, though the number of such scenarios is probably not super high.

dllh commented 6 years ago

I've tested this a bit more with both an Atomic site and a non-atomic Jetpack site, and in both cases, it's not only the case that the UI is missing, but if I navigate to /posts/my/domain.com, I'm redirected to /posts/domain.com, which doesn't filter by me. So it seems to be a plumbing issue and not just a missing UI issue.

Again, this is a pretty bad experience on a site with multiple active authors and many posts. If we need a separate issue for the redirect/plumbing issue than for the missing UI issue, please let me know and I'm happy to oblige. Here's a screen cap of the unfiltered view. To get this, I tried to visit /posts/my/domain.com, and it forwarded me to /posts/domain.com:

screen shot 2018-05-01 at 11 40 24 am

The UI is missing, and you can see that the posts are unfiltered (there are three posts by three authors). When I use the same link for a non-Atomic WP.com site, it filters and shows the filter UI as expected.

mattsherman commented 6 years ago

Thanks @dllh for the additional details! @Automattic/tanooki will be looking further into this issue in the coming weeks.

dllh commented 6 years ago

The user is back in touch on this issue. Filtering posts is still a pretty big pain point for them. Any word on whether/when this might be prioritized? Thanks!

mattsherman commented 6 years ago

@dllh @Automattic/tanooki has had reduced capacity for a while, but I will look into this early next week and see if there is a way we can get to this soon. Or, it not, I will see if there is capacity on another team to take care of this.

mattsherman commented 6 years ago

Putting this in Tanooki's backlog -- I will dig into what would be required to address this issue so that we can then make a determination as to whether we have the capacity to take this on at this point.

The main thing I need to better understand is what is missing on the backend to support this and what the effort will be to implement that.

michaeldcain commented 6 years ago

I was intrigued, so I spent a few minutes looking at this.

but if I navigate to /posts/my/domain.com, I'm redirected to /posts/domain.com, which doesn't filter by me.

This is also controlled in Calypso for all Jetpack sites (including Atomic).

However, as laid out in 547-gh-io, the real issue is that querying a Jetpack site's posts using the user's WPcom user id, returns no posts, since the author ID used in the endpoint is relative to the Jetpack site.

There are two possible solutions to this:

  1. The helper method/REST API patch from 547-gh-io (requires the changes to be synced to to Jetpack).
  2. Use the already-returned linked_user_ID and ID attributes of the site/%s/users endpoint to properly query the posts for Jetpack sites.
mattsherman commented 6 years ago

@michaeldcain Thanks for looking into this! Do you have a feel for which solution would be better from a maintenance and performance standpoint?

mattsherman commented 5 years ago

This is currently in Delta's backlog but will likely wait until the next HACK Week at the earliest.

joweber123 commented 5 years ago

Same issue came up again with a user. 2165206-zen

github-actions[bot] commented 3 years ago

This issue is stale because it has been 180 days with no activity. You can keep the issue open by adding a comment. If you do, please provide additional context and explain why you’d like it to remain open. You can also close the issue yourself — if you do, please add a brief explanation and apply one of relevant issue close labels.

github-actions[bot] commented 2 years ago

This issue is stale because it has been 180 days with no activity. You can keep the issue open by adding a comment. If you do, please provide additional context and explain why you’d like it to remain open. You can also close the issue yourself — if you do, please add a brief explanation and apply one of relevant issue close labels.

aisajib commented 2 years ago

I just had a user reach out to us at 4937158-zd-woothemes notifying us that they don't see the "Me | Everyone" filter after upgrading to Pro (basically, after going atomic).

github-actions[bot] commented 1 year ago

This issue is stale because it has been 180 days with no activity. You can keep the issue open by adding a comment. If you do, please provide additional context and explain why you’d like it to remain open. You can also close the issue yourself — if you do, please add a brief explanation and apply one of relevant issue close labels.