Make WordPress Core

Opened 10 years ago

Closed 9 years ago

#29870 closed defect (bug) (fixed)

Pagination disappears after deleting the last page of post entries

Reported by: greg-raven's profile Greg Raven Owned by: wonderboymusic's profile wonderboymusic
Milestone: 4.4 Priority: normal
Severity: normal Version: 4.0
Component: Posts, Post Types Keywords: needs-patch
Focuses: Cc:

Description

If you have multiple pages of posts listed in the All Posts listing, go to the last page of the posts. Click the checkbox to select all of the posts on that page. Bulk delete your selection. After WP deletes those entries, the pagination disappears from the top of the listing pane.

If you delete all posts from other pages, when the window content refreshes the pagination will be there.

Attachments (3)

29870.diff (1.9 KB) - added by A5hleyRich 10 years ago.
29870.2.diff (1.9 KB) - added by wonderboymusic 9 years ago.
29870.3.diff (1.0 KB) - added by bradyvercher 9 years ago.

Download all attachments as: .zip

Change History (20)

#1 @helen
10 years ago

  • Keywords needs-patch needs-codex added
  • Milestone changed from Awaiting Review to Future Release

Thanks for the report, sorry we missed this. Seems like we should check to make sure we're within the bounds of pagination and, if not, go to the last page.

#2 @helen
10 years ago

  • Keywords good-first-bug added; needs-codex removed

@A5hleyRich
10 years ago

#3 @A5hleyRich
10 years ago

This can be replicated by just appending the paged parameter with a page number greater than the total pages on the all posts screen.

#4 @A5hleyRich
10 years ago

  • Keywords has-patch added; needs-patch removed

#6 @helen
10 years ago

  • Keywords needs-patch added; has-patch removed

Should look into why what's in WP_List_Table doesn't seem to work.

#7 @A5hleyRich
10 years ago

I'm not sure WP_List_Table is at fault here, the issue is that the prepare_items method in the WP_Posts_List_Table class is not passing the correct values.

The reason for querying for the post counts separately is for performance reasons. The initial query doesn't return results because the SQL offset exceeds the amount of posts, but removing the offset will query and return all posts on every paginated page, hence the additional lookup.

#8 @pirasath
10 years ago

Thanks for the patch i tried it work.

#9 @obenland
9 years ago

  • Owner set to A5hleyRich
  • Status changed from new to assigned

#10 @wonderboymusic
9 years ago

  • Keywords has-patch added; needs-patch removed
  • Milestone changed from Future Release to 4.4

#11 @wonderboymusic
9 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 34271:

Posts List Table: Use a more robust technique for calculating $total_items so that pagination still appears when items are removed on the last page of results and ->max_num_pages decreases.

Props A5hleyRich.
Fixes #29870.

#12 @ocean90
9 years ago

  • Keywords needs-patch added; good-first-bug has-patch removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

[34271] brokes the pagination for searches. It uses the total number of posts and not the number of search results.

#13 @DrewAPicture
9 years ago

  • Owner changed from A5hleyRich to wonderboymusic
  • Status changed from reopened to assigned

@wonderboymusic Sounds like we need a follow-up re: comment:12.

#14 @wonderboymusic
9 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 35622:

List Tables: after [34271], account for searches when calculating pagination.

Fixes #29870.

#15 @bradyvercher
9 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

I ran into issues with this earlier today where the pagination no longer works with custom views that modify the query. The total items count used to be calculated based on $wp_query->found_posts, so pagination correctly accounted for any changes to the query, but that's no longer the case.

I tried to find a way to fix the pagination args from outside the list table class, but it doesn't look like it's possible after [34271].

Last edited 9 years ago by bradyvercher (previous) (diff)

@bradyvercher
9 years ago

#16 @bradyvercher
9 years ago

I attached a new patch that continues using $wp_query->found_posts on the first page of results or when any posts are actually found, otherwise it'll use the post counts to determine if the request is out of bounds.

I also went ahead and removed the $total_pages calculation since that's done immediately in WP_List_Table::set_pagination_args().

#17 @wonderboymusic
9 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 35683:

List Tables: After [35622] and [34271], improve pagination logic when queries are altered.

Props bradyvercher.
Fixes #29870.

Note: See TracTickets for help on using tickets.