[wp-trac] [WordPress Trac] #65145: Plugins: Display plugin slug/identifier in Installed Plugins row meta

[WordPress Trac]

#65145: Plugins: Display plugin slug/identifier in Installed Plugins row meta
-------------------------+------------------------------
 Reporter:  crweiner     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Plugins      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  administration
-------------------------+------------------------------

Comment (by crweiner):

 Replying to [comment:6 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 [comment:7 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!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65145#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform