Following "plugins_list": Add a filter in get_views() in class-wp-plugins-list-table

[juliobox]

Since WP 6.3 there is a new filter named "plugins_list" added in #57278

Using this filter, we can now add a new array key like "my_plugins" and set some plugins in here.
"my_plugins" is now considered as a "status" by the WP behavior, like "all", "recently_activated", etc, the whole list is here : ​https://github.com/WordPress/WordPress/blob/master/wp-admin/includes/class-wp-plugins-list-table.php#L49

We can also delete (unset()) one of them if we want too, (like hide the must-use plugins or the "upgraded" tab)

So now WordPress will go through each iteration of the array keys (aka statuses) and create a tab link to get a new view, here : ​https://github.com/WordPress/WordPress/blob/master/wp-admin/includes/class-wp-plugins-list-table.php#L495

What's the issue here.
WP will try to display a "text" for each iteration, if there is no case in the switch, it will still display the $text var, and indeed the last used value, aka incorrect value.

But remember line 49, WP sets a list of allowed statuses, this shouldn't be there anymore since the new filter plugins_list allow us to add ANY status using an array key. We have to remove line 49 and modify line 52 to remove the in_array() stuff.

Still need a check to keep the same behavior when a wrong status is loaded? it's already done line 315: ​https://github.com/WordPress/WordPress/blob/master/wp-admin/includes/class-wp-plugins-list-table.php#L315

Now to get the correct translated label in get_views() we need a hook line 586 like:

<?php
// ...
default:
    $text = apply_filters( 'plugins_list_status_text', '', $count, $status );
    if ( empty( $text ) ) {
        $text = $status;
    }
    $text .= ' <span class="count">(%s)</span>';
    break;
}

Now please test in WP 6.3.x, using this:

<?php
add_filter( 'plugins_list', 'my_plugins_tab' );
function my_plugins_tab( $plugins ) {
        $plugins['my_plugins'] = $plugins['all']['hello-dolly/hello.php']
        return $plugins;
}

And go to the /plugins.php page. You'll see the last tab with "(1)" and its label is a duplicated one, the same as the last one.
Then click on it: your view is the 'All' one, not the desired one.

Now apply my modifications/patch using this:

<?php
add_filter( 'plugins_list', 'my_plugins_tab' );
function my_plugins_tab( $plugins ) {
        $plugins['my_plugins'] = $plugins['all']['hello-dolly/hello.php']
        return $plugins;
}

add_filter( 'plugins_list_status_text', 'my_plugins_tab_label', 10, 3 );
function my_plugins_tab_label( $text, $count, $type ) {
    if ( 'my_plugins' === $type ) {
        $text = _nx( 'My Plugin', 'My Plugins', $count, 'domain' );
    }
    return $text;
}

Tadaaa, the label is fine and since we remove the allowed status line code, the view is correct.

This ticket now fully finish the job started in #57278!
Thanks for your time and tests and opinions.

[audrasjb]

Indeed, this would be a good follow-up to [56068]. Moving for 6.6 consideration.
Would you like to suggest a patch for this?

[oglekler]

This ticket was discussed during a bus scrub, @sajjad67 volunteered to work on the patch.

Add props to @audrasjb and @hellofromTonya

Trac ticket: #60495

[sajjad67]

Removed plugin_status in_array() checking and added a default switch case for the plugin tab label and also introduces a new filter.

[sajjad67]

@audrasjb and @hellofromTonya Hi, Please look into the patch submitted and testers are very much welcome to test it and provide feedback. I think it might need to work on the filter commenting.

[oglekler]

@khokansardar and @sajjad67, thank you for the patches! We have 2 days before Beta 1 and no time for testing, so, I have to move this ticket to the next milestone. Let's try to finish the work there.

[davidbaumwald]

Looking at the latest patch, I think if the $allowed_statuses whitelist check goes away, we'll need to sanitize $_REQUEST['plugin_status'] before using it. Same would need to be done in the new default case before passing to WP_List_Table->get_views_links.

[sajjad67]

Sanitizing the user input for plugin status filter

[sajjad67]

@davidbaumwald I believe the only place we are assigning value from user input is in line #50, so adding sanitization to that, other place you mentioned in default case would get the sanitized $status, please correct me if I am wrong.

[davidbaumwald]

With 6.7 Beta 1 releasing in a few hours, this is being moved to 6.8 given its recent momentum towards a resolution.

If any committer feels the remaining work can be resolved in time for Beta 1 wishes to assume ownership, feel free to update the milestone accordingly.

[audrasjb]

As per today's 6.8 bug scrub:

This one needs a small patch refresh to:

• fix some WPCS issues
• update the @since tag

And of course some user testing would be more than welcome.

Trac ticket: https://core.trac.wordpress.org/ticket/60495
Patch refresh for: ​https://github.com/WordPress/wordpress-develop/pull/6637

[audrasjb]

As per today's bug scrub: It appears this ticket still needs user testing. As 6.8 beta 1 is very close, I'm moving it to 6.9. Feel free to move it back to 6.8 if it can be committed by Monday.

[soyebsalar01]

@soyebsalar01 I removed your comment as AI generated comments that only rephrases the issue doesn't help a bit and are not welcome here since they only add noise.

[SirLouen]

Test Report

Description

❌ This report can't validate that the indicated patch works as expected.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/8294.diff

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.2.28
• Server: nginx/1.27.5
• Database: mysqli (Server: 8.4.5 / Client: mysqlnd 8.2.28)
• Browser: Chrome 137.0.0.0
• OS: Windows 10/11
• Theme: Twenty Twenty 2.9
• MU Plugins: None activated
• Plugins:
  • Plugins Filter List 1.0
  • Test Reports 1.2.0

Testing Instructions

1. First add the code provided in OP, I added as a new plugin
2. Add hello dolly to hello-dolly/hello.php
3. Go to Plugins
4. 🐞 Problem happens as described in OP

Actual Results with the test

1. ❌ Issue is not resolved with patch.

Additional Notes

• Tests seem to be covering a use cases of the new filter (adding a new custom status), but not covering the problem with the repeated statuses that seem to conflict with existing statuses and generate a wrong new status with count 1.

cc @sukhendu2002

[mindctrl]

Current patches are passing $status as the third parameter to the filter, but I think the intent was for it to be $type, otherwise you can't act on my_plugin as the example shows.

Also the example for filtering plugins_list is incorrect, as it lacks the folder/file slug key when adding to $plugins['my_plugins']. This causes count errors.

Example filter code should look something like this:

<?php
add_filter( 'plugins_list', 'my_plugins_tab' );
function my_plugins_tab( $plugins ) {
        $plugins['my_plugins']['test-reports/test-reports.php'] = $plugins['all']['test-reports/test-reports.php'];
        return $plugins;
}

add_filter( 'plugins_list_status_text', 'my_plugins_tab_label', 10, 3 );
function my_plugins_tab_label( $text, $count, $type ) {
    if ( 'my_plugins' === $type ) {
        $text = _nx( 'My Plugin', 'My Plugins', $count, 'domain' );
    }
    return $text;
}

Even with the above fixes, the query doesn't work properly when navigating to the My Plugins view. All plugins are shown instead of a filtered view.

[mindctrl]

Noting the GitHub PRs lack the removal of the $allowed_statuses check that is present in the Trac patches here, which is why the query doesn't work.

[sukhendu2002]

I have updated the PR
cc: @SirLouen

[SirLouen]

I've hunted down the "Allowed Statuses" intent to [11029]

From what I can read in the whole history of commits down to that changeset, this started to track where the user left in the last visit. At some point with the introduction of the menu "Installed Plugins", someone decided that "All" should be defaulted, but left the list of "Allowed Statuses" without any particular additional purpose.

Also, we must address what david commented back in the day

Now, those allowed statuses only serve as a hindrance to avoid an extension like this, to add new Statuses as @mindctrl has pointed out.

About the Unit Tests, @sukhendu2002 first, please read this. For a hook filter, they are not really needed, or they need a major revamp to address more precisely the intent of this filter. As I commented on the other ticket, you can take an initial template as an inspiration, but or they are manually curated to death or better leave them undone.

@Sukhendu2002 could you merge the latest trunk changes into this to see if that fixes the test issues?

This PR is incomplete and doesn't work. Should be superseded by ​https://github.com/WordPress/wordpress-develop/pull/8294.

[mindctrl]

Test Report

Description

✅ This report validates that PR 9284 works as expected.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/8294

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.2.29
• Server: nginx/1.29.1
• Database: mysqli (Server: 8.4.6 / Client: mysqlnd 8.2.29)
• Browser: Chrome 140.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.2
• MU Plugins:
  • phpmailer.php
  • z.php
• Plugins:
  • Test Reports 1.2.0

Actual Results

1. ✅ Issue resolved with patch.

Additional Notes

I tested the included PR with the following custom code, which adds a new status view called "My Plugins", adds the Test Reports and Hello Dolly plugins to that view, and unsets those same plugins from the All view.

add_filter( 'plugins_list', 'my_plugins_tab' );
function my_plugins_tab( $plugins ) {
	$plugins['my_plugins']['test-reports/test-reports.php'] = $plugins['all']['test-reports/test-reports.php'];
	$plugins['my_plugins']['hello.php'] = $plugins['all']['hello.php'];
	unset( $plugins['all']['test-reports/test-reports.php'] );
	unset( $plugins['all']['hello.php'] );
	return $plugins;
}

add_filter( 'plugins_list_status_text', 'my_plugins_tab_label', 10, 3 );
function my_plugins_tab_label( $text, $count, $type ) {
	if ( 'my_plugins' === $type ) {
		$text = _nx( 'My Plugin', 'My Plugins', $count, 'my-custom-text-domain' );
	}
	return $text;
}

[mindctrl]

Screenshot of All Plugins view for Trac 60495

[mindctrl]

Screenshot of My Plugins view for Trac 60495

Test Report added to the Trac ticket: https://core.trac.wordpress.org/ticket/60495#comment:26

[wildworks]

This ticket was featured on today's 6.9 Bug Scrub.

A PR has been submitted and reviewed, but it appears the PR has not been updated.

@sukhendu2002 Do you have the bandwidth to update the PR?

@Sukhendu2002 are you available to update your PR to address the review from Weston?

Trac ticket: https://core.trac.wordpress.org/ticket/60495
Patch refresh for: ​https://github.com/WordPress/wordpress-develop/pull/8294

Patch Refreshed in this PR ​#10133

[wildworks]

The patch has been updated, so I think it needs to be tested again. Also, since the 6.9 Beta1 release will be starting soon, I would like to punt this ticket to 7.0.

[audrasjb]

As per today's 7.0 bug scrub: let's add `needs-testing workflow keyword again, as this ticket only needs testing on the current version of the PR.

[huzaifaalmesbah]

Patch Testing Report

Patch Tested: ​https://github.com/WordPress/wordpress-develop/pull/10333

Environment

• WordPress: 7.0-alpha-61215-src
• PHP: 8.2.30
• Server: nginx/1.29.4
• Database: mysqli (Server: 9.5.0 / Client: mysqlnd 8.2.30)
• Browser: Chrome 144.0.0.0
• OS: macOS
• Theme: Twenty Ten 4.5
• MU Plugins:
  • test-plugins-tab.php
• Plugins:
  • Classic Editor 1.6.7
  • Hello Dolly 1.7.2
  • Test Reports 1.2.1

Steps taken

1. Created a clean WordPress trunk install.
2. Activated several plugins such as Classic Editor, Hello Dolly, and Test Reports.
3. Added an MU plugin with:

      add_filter( 'plugins_list', function( $plugins ) {
          $first = array_key_first( $plugins['all'] );
          if ( $first ) {
              $plugins['my_plugins'][ $first ] = $plugins['all'][ $first ];
          }
          return $plugins;
      });
   

4. Visited /wp-admin/plugins.php.
   • Before patch: No new tab is created for my_plugins
5. Applied PR.
6. Reloaded the Plugins screen.
   • After patch:
     • A new tab is created for my_plugins
     • Count is correct
     • Clicking the tab properly filters the plugin list

7. Added label filter:

   add_filter( 'plugins_list_status_text', 'my_plugins_tab_label', 10, 3 );
   function my_plugins_tab_label( $text, $count, $type ) {
       if ( 'my_plugins' === $type ) {
           $text = _nx( 'My Plugin', 'My Plugins', $count, 'my-custom-text-domain' );
       }
       return $text;
   }

8. Reloaded page again.

9. ✅ Create a Tab and working properly.

Expected result

• Custom statuses added via plugins_list should appear as tabs
• Tabs should correctly filter plugins
• Tab label should be customizable via plugins_list_status_text

Screenshots/Screencast with results

Before and after behavior video: ​https://files.catbox.moe/ws4bjo.mp4

Support Content

MU plugin used:

<?php
add_filter( 'plugins_list', function( $plugins ) {
    $first = array_key_first( $plugins['all'] );
    if ( $first ) {
        $plugins['my_plugins'][ $first ] = $plugins['all'][ $first ];
    }
    return $plugins;
});

add_filter( 'plugins_list_status_text', 'my_plugins_tab_label', 10, 3 );
function my_plugins_tab_label( $text, $count, $type ) {
    if ( 'my_plugins' === $type ) {
        $text = _nx( 'My Plugin', 'My Plugins', $count, 'my-custom-text-domain' );
    }
    return $text;
}

[audrasjb]

In 61695:

Plugins: Add a new plugins_list_status_text filter in get_views() to allow custom filtering.

This changeset does the following:

• Custom statuses added via plugins_list now appear as tabs, to filter the related plugins
• The tab label is customizable via the new plugins_list_status_text hook

Follow-up to [56068].

Props juliobox, audrasjb, hellofromTonya, khokansardar, sajjad67, davidbaumwald, sukhendu2002, SirLouen, mindctrl, shailu25, huzaifaalmesbah, westonruter.
See #60495.

[audrasjb]

Committed in [61695].

[webdados]

Yes, if I'm concerned with this, I should have known about this ticket and spoken before this "fix" was released.

Now that we allow "custom statuses", this is already being abused (in my point of view) by plugin authors (See ​https://wordpress.org/support/topic/remove-your-filter-on-the-plugins-list-in-wp-admin/).
very

What are we going to do when all plugin authors follow by example and clutter the important status filter bar?

[mymothersdaughter]

I've just had to research why this happened on a plugin that's installed on 10+ million sites. Two customers so far after they updated to 7.0. So now, we'll start to see more of this on the plugin page. This will be a real mess for users.

[webdados]

I strongly suggest that this be reverted to avoid abuse from "all" the plugin authors. The filters list will become unmanageable very soon.

After that:

• Think of an alternative to this problem that does not allow abuse

• Implement a select field filter, listing all the plugin authors present on the website - this is a matter for another trac ticket, of course, but a way to allow plugins to be filtered by author without abuse

Adds a native "Filter by author" control to the Plugins screen: a single <select> plus a Filter button in the table navigation, backed by a new plugin_author query variable and populated from installed plugins' Author headers.

This gives "find all plugins by X" a dedicated, scalable home — one control regardless of how many authors are installed — instead of each vendor adding a per-author tab to the subsubsub bar via the custom-view hooks added in #60495. The status bar (get_views()) and those hooks are left untouched; this is purely additive.

### Highlights

• No JavaScript — submits a plain GET request via a small form printed outside the bulk-actions POST form (the controls associate with it through the HTML5 form attribute).
• CSP-safe — nothing is inlined.
• Accessible — a real labelled <select> with an explicit Filter button; nothing navigates on change (no *3.2.2 On Input* surprise), with native keyboard / assistive-technology semantics.
• Shown only when two or more distinct authors are installed.
• Filterable via plugins_list_authors and plugins_list_plugin_author (e.g. to merge Author header variants under one entry).

### Changed

• wp-admin/includes/class-wp-plugins-list-table.php — author map in prepare_items(), plugin_author narrowing, get_plugin_author_key(), author_filter(), author_filter_form().
• wp-admin/plugins.php — prints the GET form outside the bulk-actions form.
• wp-admin/css/list-tables.css — one rule so the select grows to fit its widest option.
• tests/phpunit/tests/admin/wpPluginsListTable.php — 21 tests / 40 assertions.

@since tags are placeholders (7.1.0) pending the milestone. Follow-up to [56068] / [61695] / #60495.

Trac ticket: _to be attached_

## Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code (Anthropic)
Model(s): Claude Opus 4.7
Used for: The implementation, unit tests, and CSS were drafted by the AI across several iterations under my direction — I chose the approach (a native <select> + GET form for full accessibility and no-JS / CSP safety), reviewed and edited the output, and ran the test suite. I take responsibility for the contribution.

[lopo]

Here is my proposal addressing @webdados's concerns.

I second adding this.

[sumitsingh]

I am agree with @webdados through 😀 and great proposal by @lopo 🙌🙌