Making WordPress.org

Opened 19 months ago

Last modified 3 months 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:
Cc:

Description

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 WordPress.org 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 WordPress.org display doesn't make sense.

Change History (7)

#1 @sebastienserre
6 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
4 months ago

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

#3 @dd32
3 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
100%
2. Readme Title IS Plugin Name 46,864
77.38%
🟢 These plugins are doing good.
3. Readme Title STARTS WITH Plugin Name
(but does not match)
3,532
5.83%
🟡 These plugins are appending extra data to the name displayed on WordPress.org, SEO purposes?
For example, Plugin Name - The widgets plugin for SEO
4. Readme Title CONTAINS Plugin Name
(but does not match)
833
1.38%
🟠 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
7,681
12.68%
🔴 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 3 months ago by dd32 (previous) (diff)

#4 @dd32
3 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
60,559
46,864
77.38%
3,532
5.83%
833
1.38%
7,681
12.68%
100k+
493 plugins
293
59.43%
102
20.69%
21
4.3%
74
15.01%
10k+
2,556 plugins
1,706
66.74%
378
14.79%
69
2.7%
354
13.85%
1k+
8,656 plugins
6,223
71.89%%
942
10.88%
161
1.86%
1137
13.14%

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 3 months ago by dd32 (previous) (diff)

#5 @bordoni
3 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
3 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 WordPress.org & within their users plugins panel differ.

#7 @dd32
3 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.

Note: See TracTickets for help on using tickets.