[wp-trac] [WordPress Trac] #35083: Unusual plugin names can cause CSS to be unintentionally applied -- also duplicate element ID's are forbidden in HTMl

[WordPress Trac]

#35083: Unusual plugin names can cause CSS to be unintentionally applied -- also
duplicate element ID's are forbidden in HTMl
----------------------------+-----------------------------
 Reporter:  khag7           |      Owner:
     Type:  defect (bug)    |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Administration  |    Version:
 Severity:  normal          |   Keywords:
  Focuses:                  |
----------------------------+-----------------------------
 The list of installed plugins, `/wp-admin/plugins.php` is set up such that
 each `<tr>` in the table represents a single plugin. The value of the `id`
 attribute is simply the sanitized version of the plugin title. That means
 that a plugin with a specific name can cause some visual damage to the
 interface if the sanitized name of the plugin matches an id in the
 stylesheet.

 Here's a fun example -- Create a plugin named "Plugin Information" (or
 just rename an existing plugin for the purposes of this example) and drop
 it in your plugins dir. Don't even need to activate it. Then go to the
 plugins list page and be amazed! Here's a php to help you out:
 {{{#!php
 <?php
 /* Plugin Name: Plugin Information */
 ?>
 }}}

 Some other fun plugin names to try: `Contextual Help Back`, `WPAdminBar`,
 `Screen Meta`, `WPFooter`,  `WPBody Content`, `Post Body Content`, the
 list goes on.

 Now, its unlikely that someone creates a plugin named that, but there's
 also no reason our admin interface should be coded in such a way that the
 name of a plugin is enough to cause this kind of ugliness. The point is,
 we should come up with a better way of giving those `<tr>` elements a
 value for their `id` attribute.

 My first thought of a solution: we could change the value of `id` to be
 something like `#plugin-akismet` instead of just `#akismet`. That solves
 the problem, but since we're here lets talk about another issue...

 What happens if a user has two plugins with the same title? We end up with
 more than one HTML element with the same exact id. That's a HTML no-no!

 Before you say "Two plugins with the same name? That never happens!": I
 can think of a few clients of mine who have multiple old versions of the
 same plugin for backup reasons. Each of those `<tr>` elements have the
 same ID. Not the end of the world, but its not right. Our interface should
 be generating HTML with unique id's for elements, or no id at all.

 So, long story short, using the plugin title to make the id (as we've been
 doing for probably very long) is not working. Slugs won't work either:
 slugs can be the same for multiple plugins, and non wp-repo plugins have
 no slug at all in cases where the 3rd party plugin developer doesn't
 specifically provide one.

 One thing that is always unique is the plugin's file path, usually in the
 pattern of `the-plugin/the-plugin.php`. Unfortunately, the `id` attribute
 can't have `/` or `.` in it so we'd have to sanitize that string in a
 standard way.

 Alternatively, we could ditch the `id` attribute entirely and use a data
 element, since they can have special characters. `<tr data-plugin="some-
 plugin/the-plugin.php">` looks pretty nice. Is there any downside to
 losing the `id` attribute from all `<tr>`'s in the plugin list?

--
Ticket URL: <https://core.trac.wordpress.org/ticket/35083>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform