When you submit a new plugin to the WordPress.org directory, one of the things that can easily trip you up is the name you’ve chosen for your plugin (and a quick way to get a rejection).
You can spend a long time crafting the perfect name to use but, when it includes a trademarked name, it gets tricky. Very quickly.
This year I submitted a plugin which embedded Threads into your post. I knew that trademarks couldn’t be used as the initial part (no more “YouTube Embed” – one of my much, much earlier plugins, before a lot of the current guidelines were put into place), so I named it “Embed Threads”. The idea is that nobody should believe this is official (which it feels more like if the trademarked name is at the beginning). Anyway, it was rejected. Let’s try and understand why it was and why, in this case, it actually benefited me.
When building a WordPress plugin, a good quality README is critical, particularly if you’re going to be hosting it in the official directory. However, I’ve recently come across some unusual behaviour with the tags option that I want to dive into further.
1 to 12 comma separated terms that describe the plugin. Only the first five will show on the generated page, and anything over 12 will be detrimental to SEO. Plugins must refrain from using competitors plugin names as tags.
There didn’t used to be a limit on the number of tags, but they introduced, a few years ago, a recommendation of up to 12.
So, according to this documentation, you can have up to 12 but only 5 will show on your plugin page. Got it. I regularly have around 6 to 7, so this is all good.
Over the last week I’ve decided to put 3 of my plugins up for adoption. There’s a little known tag, adopt-me that you can use to indicate this, so I added it on. When you do this your plugin should appear on a search for this tag, as well as a banner appearing on your plugin like this…
But, in my case, this only happened for one of my plugins.
When I studied all 3 what I noticed is that, for the one that worked, I’d added the flag at the 5th position. For the other 2 they were greater than this. Would moving them earlier in the list work? In fact, yes, it did. It appeared that this specific tag had to be used within the first 5 for it to work (I’ve since shifted this tag to the first position for all 3 of these plugins now, just to get me into the habit).
This isn’t documented anywhere so I spoke to the Meta team for clarity. Not only is this true (i.e. that it has to be one of the first 5) but the documentation is confusing in how the tags work more generally. So, let me clear this up…
Only the first 5 tags do ANYTHING on WordPress.org. That includes when you do a plugin search (and I’ve checked and can confirm this), search for a specific tag or even how your plugin is indexed. Tags 6 – 12 are only for any indexing that external services (such as search engines) do of your README file.
As Otto said to me…
We made the limit 12 originally so that people would stop filling it in with hundreds and hundreds of tags. They are used in the sense that the search engine sees them. But they are not used by the directory itself. Basically, the limit of 12 is not a technical limit. It is a rules based limitation.
Personally, I can’t therefore see any real advantage to having anything over the first 5 and, it seems to me, by doing so you’re only potentially going to forget some of the above rules and end up causing more issues than it’s worth. No, in future I’ll stick to just the 5 limit.
This is why the plugin review team should be full time, paid positions by the non-profit entity. This team is the most important in the entire #WordPress ecosystem (they essentially manage a billion dollar ecosystem we all benefit from) and deserves every ounce of support to make… https://t.co/Nkjv9IVwx1
And there are so many things the team could / should / must check for. Security, animated GIFs, images without sufficient contrast in different color schemes, … and much more: https://t.co/uj3TajvBRW (see talk from @DavidArtiss)
I’m just a few days away from deleting my Twitter account1 and don’t want to reply directly there (it will also railroad the original discussion, which I also don’t want), so will make use of a WordPress-powered blog to do so.
But, sorry, Torsten, you’ve missed the point of my talk.
It’s been around 3 years since I last submitted a plugin to the WordPress directory. A lot has changed since then and having just had a new one approved, I thought I’d compare the process.
First of all, let’s talk about that previous plugin, back in 2020. It wasn’t particularly complex, but then neither was my recent one.
I submitted the code on 9th November. On the 11th November they rejected it due to a failure to use unique prefixes on the function names. I corrected it, sent it back and, same day, it was approved.
10 years ago, I was part of a conversation in Trac about WordPress’ housekeeping of transients. It was closed off with a half-hearted attempt to resolve the issue with the reasoning of…
This leaves much to be desired, but we don’t want a core update to be blamed for breaking a site that incorrectly assumes transients aren’t transient.
Basically, because some plugins may store data as transients, when they shouldn’t be, they were afraid to housekeep it fully.
