Opened 2 years ago

Last modified 3 days ago

#6106 new enhancement

Deprecate readme.txt plugin name header

Reported by: dd32's profile dd32 Owned by:
Milestone: Priority: normal
Component: Plugin Directory Keywords:


Currently there's two places where the plugin name is defined:

  1. readme.txt
  2. The Plugin file

for example, for Hello Dolly:

hello.php: Plugin Name: Hello Dolly
readme.txt: === Hello Dolly ===

This duplication leads to confusion with authors, only updating one of the fields and not the other.

It's also not uncommon for authors to leave the readme as === Plugin Name === not realising that they have to replace it in both locations.

Ideally should present plugins by names that they will see after the plugin is installed, and since WordPress sites themselves do not display readme titles anywhere, having an explicit field JUST for display doesn't make sense.

Change History (8)

#1 @sebastienserre
13 months ago

I agree with @dd32. We should have to change information in only 1 place.
It will be easier and avoid some mistakes.

#2 @afragen
11 months ago

I agree. Deprecate the title in readme.txt for the purposes of displaying the plugin name.

#3 @dd32
10 months ago

I've been thinking about this again after seeing some "mistakes" in plugin names that I'm not entirely sure were not intentional.

So I've run a query over all current published plugins as of a few minutes ago, and come up with this:

Case Plugin Count Note
1. All plugins searched 60,559
2. Readme Title IS Plugin Name 46,864
🟢 These plugins are doing good.
3. Readme Title STARTS WITH Plugin Name
(but does not match)
🟡 These plugins are appending extra data to the name displayed on, SEO purposes?
For example, Plugin Name - The widgets plugin for SEO
4. Readme Title CONTAINS Plugin Name
(but does not match)
🟠 These plugins are mostly prefixing extra keywords to their plugin name, such as ACME Plugin Name.
The worst offenders are things like OtherTrademarkedPluginName - MyPluginName
5. Readme Title DOES NOT CONTAIN Plugin Name,
and Plugin Name does NOT contain Readme Name
🔴 These plugins just have a completely different name in the fields. In the best case, it's plugin-name vs Plugin Name, in the worst cases it's WP Plugin Name vs WordPress Plugin Name

I think there's probably a few steps needed to make this happen:

  1. Announce/reenforce guidelines on make/plugins.
  2. Immediately cease using Readme title for plugins in cases #4 and #5 above, use the plugin title from the plugin itself. Benefit of the doubt, that they're not intentionally trying to mislead users, and that it's just that they've missed where to update things properly.
  3. After a grace period, 1 month(?), Cease to read the readme.txt header entirely.

Due to the number of plugins which are ignoring the trademark guidelines around the usage of trademarked terms, that we reject during plugin submission, I believe we'd be likely best to enforce those with code too..

I think most people would be on the same page, that My Plugin Name - Long description about the plugin and what it does is not an appropriate plugin name, but that we also understand why the majority of plugins do this. I think we have to possibly allow it though, as the alternative is that plugin authors will simply adjust their plugin name in their php files too, such that they can continue to do so in the plugin indexes.

Last edited 10 months ago by dd32 (previous) (diff)

#4 @dd32
10 months ago

I was asked via Slack on whether this data would affect popular plugins, or if "small" plugins were the main plugins not using reasonable names. So I've broken down the above data into active install groups.

Installs 2. 🟢 Exact Match 3. 🟡 Starts with plugin name 4. 🟠 Contains plugin name 5. 🔴 Completely different
All plugins
493 plugins
2,556 plugins
8,656 plugins

Note: The data in this table has been updated since posting. A data issue was discovered with some titles resulting in some plugin being incorrectly categorised. Added the All plugins row and altered other numbers, see comment diff for the minor changes. This resulted in some plugins moving from column 5 to columns 2&3.

Last edited 10 months ago by dd32 (previous) (diff)

#5 @bordoni
10 months ago

This is really good data, and I 100% agree that if the plugin name is not the name and some one or two words for clarification it's too much. For example, when you have separators on the plugin name it's clearly because the second part is more of a description or even just for SEO purposes.

I wonder how plugins that have renamed or even re-branded after the creation of the plugin, how should they handle that process?

#6 @dd32
10 months ago

I wonder how plugins that have renamed or even re-branded after the creation of the plugin, how should they handle that process?

The vast majority of plugins that rebrand simply rename the plugin, ACME Widgets => Dions Widgets, sometimes they do have a transitional period of Dions Widgets (formally ACME Widgets) from what I've seen.

At first I don't see that being an issue at all here, it's unlikely that a plugin should/would want to have the name of the plugin on & within their users plugins panel differ.

#7 @dd32
10 months ago

In 12715:

Plugin Directory: Import: When importing plugins from SVN, if the readme title is the plugin slug, ignore that and use the Plugin headers.

This affects a minority of plugins, but this improves a small set of plugins who have === plugin-slug-here === in their readme.txt.

See #6106.

#8 @dd32
3 days ago

As noted in

If we do it for the plugin name, I'd consider also doing it for the short description. Use the one from the plugin file.

I agree that it makes sense to also switch the description field too..

Note: See TracTickets for help on using tickets.