Make WordPress Core

Opened 4 years ago

Closed 4 years ago

#17285 closed defect (bug) (fixed)

Pagination of plugins search results does not work

Reported by: pavelevap Owned by: dd32
Milestone: 3.2 Priority: normal
Severity: normal Version: 3.1
Component: Administration Keywords: has-patch
Focuses: Cc:


I tested several plugins and noticed that pagination of plugins search results does not work. Simply, search string is not passed to pagination links.

  • Go to Plugins menu.
  • Set small (testing) number in Screen tab for plugin pagination.
  • Enter for example "Menu" into searchbox (or any other word to have chance to find some installed plugins).
  • There are 11 items found, 3 pages available for me, I can see first 5 related plugins, everything looks well.
  • But when you click on "Next page" icon to see other search results, you are redirected to second page, but of all plugins. Search string is not passed to pagination links...

Attachments (1)

17285.diff (622 bytes) - added by dd32 4 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 @scribu4 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 3.2
  • Version changed from 3.2 to 3.1


comment:2 @scribu4 years ago

  • Component changed from General to Administration

comment:3 @ocean904 years ago

Seems like the plugins page is the last screen which uses method="post" instead of method="get".

comment:4 @dbernar14 years ago

  • Cc dbernar1 added

I was just saying the same thing on the wordpress-dev channel. Switching the form to a get form fixes the issue.

The "problem" there is that the URL generated by the get form looks like this:


I don't know for sure that this is a problem, but it seems like it might have some URL params that it does not need.

comment:5 @ocean904 years ago

Also bulk stuff will not work any longer, because they rely on $_POST.

comment:6 @dd324 years ago

Also bulk stuff will not work any longer, because they rely on $_POST.

For posts/etc it's fine as the checkboxes are ID's, for Plugins the checkbox values are going to be Plugin names, so on average lets say 20char long.. That'll easily make a looong url when you perform bulk actions on many plugins..

comment:7 @scribu4 years ago

We can leave the action as POST, but make the search check $_REQUEST. Then, we could just pass 's' into the pagination URL.

comment:8 @dd324 years ago

  • Keywords has-patch added; needs-patch removed
  • Owner set to dd32
  • Status changed from new to accepted

Since the list tables have no filters of any kind on the pagination, it's a bit hard to do this any other way.

I seem to recall something bad about modifying $_SERVER['REQUEST_URI'] with add_query_arg(), but I can't remember what it was; So this is my patch: (Any comments?)

  • wp-admin/includes/class-wp-plugins-list-table.php

    2121                if ( $status != $default_status && 'search' != $status ) 
    2222                        update_user_meta( get_current_user_id(), 'plugins_last_view', $status ); 
     25                if ( isset($_REQUEST['s']) ) 
     26                        $_SERVER['REQUEST_URI'] = add_query_arg('s', stripslashes($_REQUEST['s']) ); 
    2428                $page = $this->get_pagenum(); 
    2630                parent::__construct( array( 
Last edited 4 years ago by dd32 (previous) (diff)

comment:9 @scribu4 years ago

It's cool that you can post diffs inline, but that makes it a chore to apply it to a local install.

comment:10 @dd324 years ago

I wasn't expecting you to attempt to apply it locally though :) I'll attach a diff

@dd324 years ago

comment:11 @scribu4 years ago

Thanks :)

comment:12 @johnjamesjacoby4 years ago

Tested 17285.diff.

Confirmed fixed.

comment:13 @ryan4 years ago

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

In [18093]:

Fix paging through plugin search results. Props dd32. fixes #17285

Note: See TracTickets for help on using tickets.