Skip to content

Fix/top posts widget#15109

Merged
kraftbj merged 6 commits intomasterfrom
fix/top-posts-widget
Mar 27, 2020
Merged

Fix/top posts widget#15109
kraftbj merged 6 commits intomasterfrom
fix/top-posts-widget

Conversation

@leogermani
Copy link
Copy Markdown
Contributor

@leogermani leogermani commented Mar 24, 2020

Fixes #15104,
See #2369
Addresses 4794-jpop-issues, 4988-jpop-issues

Changes proposed in this Pull Request:

This PR improves the way the Top Posts & Pages Widget fetches posts to be displayed.

How it worked before this PR:
  • Widget makes a request to the wp.com API to fetch the top posts (of all post types)
  • Since it makes a request with summarize=1, it receives up to 500 posts in the response
  • It filters out only the number of posts the widget is configured to be displayed
  • From this few posts, it filters out only posts of the post types configured to be displayed
  • If it results in zero posts, it falls back fetching only one post or page, no matter what the post types configured in the widget are

The problem here is that if there were 10 posts in the top 10 positions, and you queried for pages, you would get no results.

This PR proposes two changes:
  1. It filters out the posts by post type at the same time it's iterating over all the posts returned by the API, till it reaches the number of posts configured in the widget.
  2. If no posts are found, it respects the post type and number of posts configurations

Limitations: This PR does not completely solve the problem. There is no way to query the wp.com API for post types filtering for a specific post type. So the same problem still persists, the only difference is that it now looks in all 500 retrieved posts, and not only on the first 10.

Is this a new feature or does it add/remove features to an existing part of Jetpack?

  • It fixes an existing feature

Testing instructions:

It's very difficult to test the edge cases that this PR fixes, but I'll give some basic testing instructions and describe the edge case afterward.

Run these tests both on a wp.com site and on a JP site.

On an existing site with some stats.
2. in Jetpack settings, activate Make extra widgets available for use on your site including subscription forms and Twitter streams
3. Go to Appearance > Widgets and add two "Top Posts & Pages" Widget
4. Configure one of the widgets to display only posts, and the other one to display only pages
5. Visit the site both logged in and logged out and check if the widgets are working as expected

On a brand new site

  1. Follow the same instructions, 1 to 4
  2. Visit the site, logged in, and see the message "There are no posts to display"
  3. Visit the site, logged out, and see that the posts displayed in both widget respect the configured post type and count.

The Edge case

The Edge case is a site that has many posts of a certain post type and, when you add a widget to display posts of another post type, this widget would not find any post.

  • Considering a site that has many posts of the post type post as its top rankings posts, and few pages with few visits
  1. Follow the same instructions 1 to 4
  2. Check the site front end, bot logged in and logged out. Check that the widget that should display pages finds the most viewed pages.

Proposed changelog entry for your changes:

  • Fixes Top Posts & Pages Widget handling with different post types

Consider all the posts retrieved from the wp.com API when filtering
by post type
When no posts are found in wp.com API
Fallback to local posts but respecting post type and count
@matticbot
Copy link
Copy Markdown
Contributor

Caution: This PR has changes that must be merged to WordPress.com
Hello leogermani! These changes need to be synced to WordPress.com - If you 're an a11n, please commandeer, review, and approve D40778-code before merging this PR. Thank you!

@jetpackbot
Copy link
Copy Markdown
Collaborator

jetpackbot commented Mar 24, 2020

Thank you for the great PR description!

When this PR is ready for review, please apply the [Status] Needs Review label. If you are an a11n, please have someone from your team review the code if possible. The Jetpack team will also review this PR and merge it to be included in the next Jetpack release.

Scheduled Jetpack release: April 7, 2020.
Scheduled code freeze: March 31, 2020

Generated by 🚫 dangerJS against 97d3618

@jeherve jeherve added the Bug When a feature is broken and / or not performing as intended label Mar 25, 2020
@jeherve jeherve added this to the 8.4 milestone Mar 25, 2020
@sergeymitr
Copy link
Copy Markdown
Contributor

Hi @leogermani.
For some reason the "Top Posts & Pages" widget doesn't display any posts or pages when I'm logged in as an admin:
top-pages-posts

Everything works correctly when I'm viewing the website as a guest though.
Let me know if you need help debugging it.

Copy link
Copy Markdown
Contributor

@kraftbj kraftbj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very minor things. (and the updated commit may retrigger Travis)

* @param array $types The post types that should be returned.
* @return array
*/
public function get_posts( $post_ids, $count, $types ) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we set $types = array( 'post', 'page' ) to make it an optional parameter?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we could. I didn't because this variable is treated here:

$types = isset( $instance['types'] ) ? (array) $instance['types'] : array( 'post', 'page' );

But no harm doing that

Copy link
Copy Markdown
Contributor Author

@leogermani leogermani Mar 27, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm reconsidering this.

This method is not called directly by the main widget method, it is passed through get_by_likes, get_by_views and get_fallback_posts. So this would require a chain of optional and useless arguments...

Both $count and $types are present in the widgets $instance, so a nice refactor would be to use it instead. Not sure if we should do it now... Also, these methods could/should be private (or live somewhere else in jetpack codebase)

I'm always afraid with backward compatibility when I consider refactoring things, but this is a widget and the code, I beleive, is self contained and shouldn't be called from outside...

What do you think? quick refactor?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm okay covering that in a later PR. Could you either open an issue (if you don't have bandwidth) or open a new PR for it?

function get_posts( $post_ids, $count ) {
/**
* Get posts from an array of IDs
*
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we add a @since 8.4.0 Added $types?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 97d3618

@leogermani
Copy link
Copy Markdown
Contributor Author

Hi @leogermani.
For some reason the "Top Posts & Pages" widget doesn't display any posts or pages when I'm logged in as an admin:

That's expected with a brand new site.

When you have an anonymous visitor, it falls back and make a simple query for posts (the second fix on this PR). Before this PR. it would display only one post, no matter how many you configured to be displayed in the widget, and also ignore the post type.

@matticbot
Copy link
Copy Markdown
Contributor

leogermani, Your synced wpcom patch D40778-code has been updated.

kraftbj
kraftbj previously approved these changes Mar 27, 2020
@kraftbj kraftbj added [Status] Ready to Merge Go ahead, you can push that green button! and removed [Status] Needs Review This PR is ready for review. labels Mar 27, 2020
@kraftbj
Copy link
Copy Markdown
Contributor

kraftbj commented Mar 27, 2020

r204992-wpcom

@kraftbj
Copy link
Copy Markdown
Contributor

kraftbj commented Mar 27, 2020

D41022-code // r204996-wpcom for the clean-up of the defaults.

@kraftbj kraftbj merged commit 3eb619e into master Mar 27, 2020
@kraftbj kraftbj deleted the fix/top-posts-widget branch March 27, 2020 20:57
@matticbot matticbot added [Status] Needs Changelog and removed [Status] Ready to Merge Go ahead, you can push that green button! labels Mar 27, 2020
* Get posts from an array of IDs
*
* @since 8.4.0 Added $count and $types parameters
* @since 8.4.0 Added $types parameters
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah yes, the parameter existed, but it was ignored

jeherve added a commit that referenced this pull request Mar 31, 2020
jeherve added a commit that referenced this pull request Mar 31, 2020
* Initial changelog entry

* Changelog: add #14904

* Changelog: add #14910

* Changelog: add #14913

* Changelog: add #14916

* Changelog: add #14922

* Changelog: add #14924

* Changelog: add #14925

* Changelog: add #14928

* Changelog: add #14840

* Changelog: add #14841

* Changelog: add #14842

* Changelog: add #14826

* Changelog: add #14835

* Changelog: add #14859

* Changelog: add #14884

* Changelog: add #14888

* Changelog: add #14817

* Changelog: add #14814

* Changelog: add #14819

* Changelog;: add #14797

* Changelog: add #14798

* Changelog: add #14802

* Changelog: add #13676

* Changelog: add #13744

* Changelog: add #13777

* Changelog: add #14446

* Changelog: add #14739

* Changelog: add #14770

* Changelog: add #14784

* Changelog: add #14897

* Changelog: add #14898

* Changelog: add #14968

* Changelog: add #14985

* Changelog: add #15044

* Changelog: add #15052

* Update to remove Podcast since it remains in Beta

* Changelog: add #14803

* Changelog: add #15028

* Changelog: add #15065

* Changelog:add #14886

* Changelog: add #15118

* Changelog: add #14990

* Changelog: add #14528

* Changelog: add #15120

* Changelog: add #15126

* Changelog: add #15049

* Chanegelog: add #14852

* Changelog: add #15090

* Changelog: add #15138

* Changelog: add #15124

* Changelog:add #15055

* Changelog: add #15017

* Changelog: add #15109

* Changelog: add #15145

* Changelog:add #15096

* Changelog:add #15153

* Changelog: add #15133

* Changelog: add #14960

* Changelog: add #15127

* Changelog: add #15056

* Copy current changelog to changelog archive.

* Clarify changelog description
jeherve added a commit that referenced this pull request Apr 9, 2020
$types was added in 8.4, but we did not add a default value when it's not provided.

See #15109 for more details.
kraftbj pushed a commit that referenced this pull request Apr 9, 2020
$types was added in 8.4, but we did not add a default value when it's not provided.

See #15109 for more details.
kraftbj pushed a commit that referenced this pull request Apr 9, 2020
…am. (#15395)

$types was added in 8.4, but we did not add a default value when it's not provided.

See #15109 for more details.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Bug When a feature is broken and / or not performing as intended [Feature] Extra Sidebar Widgets Touches WP.com Files

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Top posts widget not handling post types well

6 participants