Plugins: Display plugin slug/identifier in Installed Plugins row meta

[crweiner]

On the Installed Plugins screen (/wp-admin/plugins.php), the row meta currently shows the metadata, such as the plugin version, author, and either “View details” or “Visit plugin site”, as well as whatever else a plugin author manually defines.

It would be helpful to also display the plugin's slug / identifier as well.

This would make it easier to match plugins shown in WP Admin with WP-CLI output, where all of the wp plugin commands like wp plugin list identify plugins by slug/name rather than the human-readable plugin title.

Suggested behavior:

• If $plugin_data['slug'] is available, display that value.
• Otherwise, fall back to an identifier derived from $plugin_file:
  • directory-based plugins: directory name
  • single-file plugins: filename without .php

Example:

Current:
Version 2.11.2 | By Activity Log Team | View details

Proposed:
Version 2.11.2 | By Activity Log Team | Slug: activity-log | View details

I am not tied to having the slug be after the author name specifically, just an idea!

WP_Plugins_List_Table::single_row() already uses $plugin_data['slug'] for the “View details” link when available to pull up a WP.org card, so this appears to be available for many installed plugins already.

Trac ticket: https://core.trac.wordpress.org/ticket/65145

• Used $plugin_slug already available to display in plugin meta after the author as Slug: <plugin-slug>.

## Screenshots or screencast

Before	After

## Use of AI Tools

• None

[hbhalodia]

Hi @crweiner, I agree with the same. It would be beneficial when we compare the results with the CLI command which shows slug and with the plugin UI page.

Let's wait for a review from the Core Team to check the usecase more broadly and the placement of the slug. I have already raised the PR in case the issue is accepted to work on.

The enhancement is not such big, as you already pointed, $plugin_slug is being used in WP_Plugins_List_Table::single_row(), So my PR uses the same variable to add it after the author.

Thanks,

[wildworks]

Thanks for the suggestion.

It would be helpful to also display the plugin's slug / identifier as well.

This feature might be useful for developers, but it's meaningless for most users. Personally, I don't think this feature should be introduced into the core.

Instead, I recommend using the CLI to retrieve the title and identifier.

wp plugin list --fields=name,title

[westonruter]

I often look at the row action links to figure out what the slug is. Not ideal, but it works.

[hbhalodia]

+1 to @westonruter. I’ve also noticed that retrieving the slug from the plugin UI list page can be useful in many cases.

Adding this information to the UI is unlikely to impact regular users. While it may not be particularly meaningful to them, it wouldn’t clutter the plugin list page significantly and can be easily ignored.

For developers, however, it provides clear value by eliminating the need to run CLI commands. In many scenarios, accessing the server via SSH and executing commands involves multiple steps, so having this information readily available in the UI would be a more straightforward IMO.

[westonruter]

A possibility is to add a Slug column but which is hidden by default. A developer could then go up to Screen Options to enable showing the Slug column. Other users would not see it unless they opt in as well.

[westonruter]

Something else to note: "Slug" is not always sufficient to identify a plugin. To be entirely accurate, it should be "File" (e.g. directory/file.php). A plugin directory can actually contain multiple plugin files, although this is not common (and probably isn't allowed in the plugin directory).

[hbhalodia]

That approach makes sense. I support the idea of adding this option under Screen Options, allowing users to enable or disable it similar to how Description and Automatic Updates are handled.

Developers or advanced users could opt in to display it as a standalone column (positioned after the plugin name and before the description), while keeping it disabled by default.

This would be a more suitable solution, as it preserves the existing plugin metadata and layout, ensuring no disruption to the default experience for regular users while still providing additional functionality for those who need it.

Before proceeding and updating the PR, I would like more of the users to check the viable option and then we can decide to provide a support or not.

Thanks,

[wildworks]

A possibility is to add a Slug column but which is hidden by default.

Yes, this approach might be good.

[crweiner]

Replying to westonruter:

A possibility is to add a Slug column but which is hidden by default. A developer could then go up to Screen Options to enable showing the Slug column. Other users would not see it unless they opt in as well.

I think that's a great idea to make the slug selectable in Screen Options! It'll be out of the way, but still accessible for the devs who need it.

Replying to westonruter:

Something else to note: "Slug" is not always sufficient to identify a plugin. To be entirely accurate, it should be "File" (e.g. directory/file.php). A plugin directory can actually contain multiple plugin files, although this is not common (and probably isn't allowed in the plugin directory).

I took a look at how the WP-CLI works with slugs, as this was my whole inspiration for the enhancement ticket in the first place. It seems to use three different ways of processing a slug, depending on the command. Do note, I am not a PHP or WP-CLI expert and would highly, highly, suggest double checking my assumptions below.

• For wp plugin list, it uses php/utils-wp.php and get_plugin_name - ​https://github.com/wp-cli/wp-cli/blob/main/php/utils-wp.php . If I understand it correctly, I think it functions like this:
  • If the plugin basename has no slash, use the filename without .php
  • Otherwise, it uses the directory name

• Commands like wp plugin activate <slug>, wp plugin update <slug>, and similar commands use src/WP_CLI/Fetchers/Plugin.php and get_plugins - ​https://github.com/wp-cli/extension-command/blob/main/src/WP_CLI/Fetchers/Plugin.php . I think it tries to match the plugin slug you type via one of three ways:
  • Exact plugin file: directory/file.php
  • Bare file name: name matches name.php
  • Directory name: directory matches directory/file.php

• Installing via wp plugin install <slug> is different, as that uses src/WP_CLI/CommandWithUpgrade.php and install - ​https://github.com/wp-cli/extension-command/blob/main/src/WP_CLI/CommandWithUpgrade.php#L188
  • This first checks if it is a remote URL, local ZIP file, remote or local PHP file, a WP.org directory URL, then lastly a WP.org slug

So, all of that is to say, I agree with @westonruter and it looks like a directory or filename-based slug column is probably the best, as that will match with what wp plugin list does (if I am understanding the code correctly). To have pairity with the WP-CLI, I think the slug logic would look like this:

• Derive the slug from the installed plugin file:
  • dirname( $plugin_file ) for directory plugins
  • basename( $plugin_file, '.php' ) for single-file plugins
• If duplicates exist (because of two plugins in the same directory), fall back to the plugin file without .php
• We could also maybe use the exact plugin file location, like directory/file.php, if that's simpler? As long as the slug is findable on the page with CTRL (or CMD) + F, that would probably be good enough for most people.

Would love to know everyone's thoughts!

[crweiner]

Another thought that just came to mind: I am not sure if this will work well for multiste installs or for people who run a non-standard WP install with a different directory structure than the default, such as Bedrock - ​https://roots.io/bedrock/ , or use simlinked plugins, like on WP.com. I don't want to cause an issue (like PHP fatals) for these kinds of sites if a "Slug" column is enabled in Screen Options if the code is searching for plugins in a folder that doesn't exist.

We would need to not assume that plugins are always in wp-content/plugins and instead check where it is: ​https://developer.wordpress.org/apis/wp-config-php/#moving-plugin-folder . So, maybe showing the plugin_basename would be better (or at least a first option, before trying the directory or dropping .php for single-file plugins)? ​https://developer.wordpress.org/reference/functions/plugin_basename/

[westonruter]

The plugin identifiers can be whatever the array keys for what is returned by get_plugins().

The WP_Plugins_List_Table::single_row() function is already passed a tuple which of array( $plugin_file, $plugin_data ). The $plugin_file is how to uniquely identify a plugin.

[hbhalodia]

Hi Team, I have updated the PR to add the slug column after Name and before Description. Also added option to hide the slug by default for all users when the feature lands. User can enable/disable using screen options as shared.

Refer PR description for detailed screencast on the functionality - ​https://github.com/WordPress/wordpress-develop/pull/11674

As @westonruter mentioned, to uniquely identify the plugin, we need to use $plugin_file variable. So I have used that, so we have detailed plugin slug info.

Thanks,

Tested this in Playground, and the feature is working fine on my end.

See Trac ticket: https://core.trac.wordpress.org/ticket/65145

## Summary
Adds a hidden-by-default File column to the plugins list table so installed plugins can be identified by their plugin file/basename.

This is an alternative to #11674. That PR helped validate the Screen Options direction, but this patch takes a slightly different approach by exposing the installed plugin file ($plugin_file) in a File column rather than exposing a Slug column.

## Why this approach
Using File may be a better fit for the concerns raised in the ticket because it reflects the actual installed plugin identifier that core already has reliably for all plugins, including:

• WordPress.org plugins
• premium/custom plugins
• plugins with multiple entry files in one directory
• must-use plugins
• drop-ins
• multisite and custom plugin directory setups

This also avoids labeling directory/file.php as a “slug”, which is not always technically accurate.

## What changed

• Adds a hidden-by-default File column to WP_Plugins_List_Table
• Displays the value of $plugin_file
• Places the column at the end of the plugins columns / Screen Options list
• Adds a responsive fix so hidden plugin columns remain hidden on narrow/mobile views
• Adds PHPUnit coverage for the new column, default hidden state, and row output

## Testing

• Browser-tested on local single-site and multisite Studio sites
• Verified Installed, Must-Use, and Drop-ins views
• Verified network and subsite plugin screens on multisite
• Confirmed the File column is hidden by default, appears when enabled, and hides again when disabled
• Ran:
  • php -l src/wp-admin/includes/class-wp-plugins-list-table.php
  • php -l tests/phpunit/tests/admin/wpPluginsListTable.php
  • npm run test:php -- tests/phpunit/tests/admin/wpPluginsListTable.php

## AI assistance
AI assistance: Yes
Tool(s): OpenAI Codex
Model(s): GPT 5.4 High
Used for: implementation drafting, test drafting, and local QA assistance. Final code, testing, and validation were reviewed and completed by me.

[crweiner]

As above, I had a slightly different implementation, and opened this PR: ​https://github.com/WordPress/wordpress-develop/pull/11780

The main difference is that this patch adds a hidden-by-default File column using $plugin_file, instead of adding a Slug column. And it adds it at the end of the plugin table.

I also noticed a bug with the "Automatic Updates" Screen Option responsiveness on small/mobile devices, and patched that as a part of this PR as well. On small screens, the "Automatic Updates" section in the plugin table still appears, regardless of the Screen Options checkbox. Previously, no matter if "Automatic Updates" was checked in Screen Options or not, it still appeared on the page for mobile-sized screens.

This PR also adds PHPUnit coverage, per the Automated Testing handbook: ​https://make.wordpress.org/core/handbook/testing/automated-testing/

This is my first time attempting to contribute code to WP.org and did use AI for assistance, as disclosed in the PR.