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.