Taxonomies in the Plugin Directory

Since my last post, I’ve been doing some thinking and digging into taxonomies on the plugin directory. There were a few common complaints about rethinking “tags” in the plugin directory. They boiled down to a few specific points:

  • I need to mark my plugin as built for [plugin name].
  • I need to note which WordPress features my plugin supports.
  • Tag pages are currently well-placed in search engine results and changing or removing them could lower my ranking.
  • As a result of the above, among other things, three is not enough.

This post will walk through a bit more detail on our thinking and address those points.


The plugin directory was created to showcase free and open source plugins from all over, bringing them together to make it easier for WordPress users to customize their WordPress installations. As its grown to over 40,000 plugins, it’s gotten harder and harder for users to find the Right Plugin. While initially helpful, tags have become a free-for-all to indicate an assortment of things. Going forward, we’d like to re-focus our taxonomies to make it easier for users to find quality plugins.

In an ideal world, a plugin’s readme would detail all of its features and the plugin directory search would parse the readme well. We’re moving toward that ideal world. Our current search, powered by Sphinx, is being replaced by ElasticSearch, which will yield far better results.

However, parsing readme files is not the only method for classifying things. We have a wonderful feature in WordPress called “taxonomies” that can both assist search and make it easier for users to find specific plugins. So, let’s use them!

I’d like to propose three separate taxonomies (more on each below):

  1. Categories
  2. Built For
  3. Business model

Here’s a bit more detail on each taxonomy.

Categories

Categories are the new tags. In fact, we’ll automatically map most tags to categories so plugin authors don’t have to.

With great help, I went through the top 1000 terms currently in use in the plugin directory and attempted to categorize them. Many of them are not useful and should not be categorized (here’s looking at you “post” and “plugin“). But most of them categorize quite well into these 26 categories (an initial attempt):

  • Accessibility – Plugins that improve accessibility.
  • Advertising – Including affiliates.
  • Analytics – Including statistics, counters, and the like.
  • Arts & Entertainment – Sports, games, movies.
  • Authentication – Login, registration, OAuth, OpenID.
  • Business – Real estate, travel, restaurants.
  • Calendar & Events – Including scheduling, booking, clocks, and appointments.
  • Communication – Email, chat, newsletters, subscriptions.
  • Contact Forms – ‘Nuff said.
  • Customization – Templates, sidebars, Customizer, widgets.
  • Discussion & Community – Comments, forums, BuddyPress.
  • eCommerce – Shopping, payments, billing, invoicing.
  • Editor & Writing – Writing, editing, TinyMCE.
  • Education & Support – Including help desk, wiki, and dictionary.
  • Language Tools – Multilingual tools.
  • Maps & Location – Plugins that geolocate or map.
  • Media – Galleries, carousels, sliders, etc.
  • Multisite – Plugins which are built to improve and enhance networks.
  • Performance – Cache, monitoring, maintenance.
  • Ratings & Reviews – Including polls, testimonials, and recommendations.
  • Security & Spam Protection – SSL, HTTPS, firewalls.
  • SEO & Marketing – Including sitemaps and OpenGraph.
  • Social & Sharing – All the sharing plugins for all the social networks, including OEmbed.
  • Taxonomy – Custom taxonomies, tag clouds.
  • User Management – Membership, profiles, CRMs.
  • Utilities – Import, export, calculators, debugging, offline.

We can – and should – debate the specific naming of these categories. However, for this post, consider the general “buckets” created by each category. We have plenty of time to paint the bike shed. 😉

Why move from free-form tags to categories? Moving to categories allows us to feature specific categories on the plugin directory home page. For example, in the future, we’ll be able to update the homepage on a regular basis to show “Trending [Category] Plugins.”

Categories are also considerably more familiar to users today. This is well-evidenced by mobile app stores like Google Play and iTunes, where users find it easy to explore and find new apps for their devices.

What about tag pages? These will no longer exist, but they can be forwarded to the relevant searches.

Wait! Don’t comment yet. Keep reading. 🙂

Built For

Plugins often need a way to indicate they’re built for another plugin. WordPress does not have a dependency system and this blog post is not the right place to lobby for one. However, the plugin directory currently allows plugins, through the use of tags, to indicate that they are built for another plugin.

For example, all plugins that are built for Contact Form 7, currently indicate so with the contact-form-7 tag. This can get messy, as seen in the search results.

The new directory will, instead, introduce a new taxonomy that allows the plugin author to select a plugin they’re “built for” in the plugin admin. This will not be a free form area. Instead, it will allow you to choose a specific plugin that is already in the directory.

Business Model

Finally, Matt forwarded some user feedback and challenged the team to come up with a way for authors to indicate what business model their plugin operates under.

As you can see from the prototypes, we’ve been experimenting with how this will look like, with the likely addition of an explanatory tooltip and/or page. Terminology-wise, I propose we adopt the following terms:

  • Service – Utilizes external services to operate. Some functionality may be available without sign up.
  • Lite – A premium version (or add-on) is available for purchase from the developer.

Plugins with neither of these restrictions would not need to add either term. This new taxonomy would be opt-in and plugin authors will be responsible for adding the relevant term.

Adding these two terms will go a long to helping users understand a plugin’s requirements.


Your Input Matters

Please take a moment and consider everything in this post. If you’re a plugin author, consider how your plugin(s) fits into the above categories, as well as if and how it uses the other two taxonomies. Then… leave your comments and questions! Your feedback is what helps makes the plugin directory great. 🙂

A big, big thank you to both @ipstenu and @aaroncampbell for their input, help, and support on coming up with the proposals above.

#plugin-directory