Title: tags – Make WordPress Plugins --- # Tag Archives: tags [ ](https://profiles.wordpress.org/ipstenu/) [Ipstenu (Mika Epstein)](https://profiles.wordpress.org/ipstenu/) 5:05 pm _on_ March 16, 2021 Tags: [release ( 2 )](https://make.wordpress.org/plugins/tag/release/), [svn ( 3 )](https://make.wordpress.org/plugins/tag/svn/), tags    # 󠀁[Trunk vs Tags? Which is Better? (Answer: Tags)](https://make.wordpress.org/plugins/2021/03/16/trunk-vs-tags-which-is-better-tags/)󠁿 tl;dr – We strongly recommend you use tagged folders for your releases of your plugins. Future you will thank you. While we have always advocated for people to use a tag folder with their plugins instead of trunk, it persists that a number of developers like using the “Stable TagTag Tag is one of the pre-defined taxonomies in WordPress. Users can add tags to their WordPress posts along with categories. However, while a category may cover a broad range of topics, tags are smaller in scope and focused to specific topics. Think of them as keywords used for topics discussed in a particular post.” of trunk. There are logical reasons for this. Having your stable tag be trunk feels like it’s one less thing to keep in mind when you update your pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory [https://wordpress.org/plugins/](https://wordpress.org/plugins/) or can be cost-based plugin from a third-party. for a new release. The problem with that setup is that you suddenly made it harder for everyone else to keep tabs on your plugin, to make sure they downloaded the correct version, and worst of all … you made it nearly impossible to roll back to a previous release. And with the advent of automated plugin updates, that last one is going to be damaging to you in the long run. In fact, here’s what you’re making worse: * No easy way to download older versions to debug compatibility issues * Translators cannot work in ‘advance’ of a release, meaning as soon as you push your code, the translations are out of date until volunteers can work on it * You increase your risk of an accidental release * No way to allow people to download the ‘pre-release’ version from official WordPress. orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. [https://wordpress.org/](https://wordpress.org/) sources * No ability to ‘roll back’ versions So what’s the _right_ way? 1. Make sure your readme.txt has the stable tag to your stable version in the main plugin file (those need to match) 2. Put everything into your trunk folder on your local checkout (use `svn add` and so on as needed) 3. Run `svn cp trunk tags/1.2.3` — this will copy from trunk to the tag folder 4. Run `svn ci -m "Releasing new version"` — this will push both trunk and tag That’s it. You’re done. Now you can upload and edit trunk all you want, for a dev version, and as long as the readme points to the proper stable tag, your users won’t get any updates. Okay, but what if you want to have a trunk version for testing? Do **not** edit the stable tag in the trunk readme! It’s that value that tells WordPress which version is ‘stable’ and if you’re working on 1.2.3, keep stable as 1.2.2 in trunk and no one will get the new code until you’re ready. [#release](https://make.wordpress.org/plugins/tag/release/), [#svn](https://make.wordpress.org/plugins/tag/svn/), [#tags](https://make.wordpress.org/plugins/tag/tags/) [ ](https://profiles.wordpress.org/samuelsidler/) [Samuel Sidler](https://profiles.wordpress.org/samuelsidler/) 9:57 pm _on_ May 20, 2016 Tags: tags, taxonomy    # 󠀁[More on Taxonomies in the New Plugin Directory](https://make.wordpress.org/plugins/2016/05/20/more-on-taxonomies-in-the-new-plugin-directory/)󠁿 Hello again everyone! I posted a proposal for taxonomies in the new pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory [https://wordpress.org/plugins/](https://wordpress.org/plugins/) or can be cost-based plugin from a third-party. directory on the make/metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. site. Please leave your questions and comments over there. > [Taxonomies in the Plugin Directory](https://make.wordpress.org/meta/2016/05/20/taxonomies-in-the-plugin-directory/) [#tags](https://make.wordpress.org/plugins/tag/tags/), [#taxonomy](https://make.wordpress.org/plugins/tag/taxonomy/) [ ](https://profiles.wordpress.org/samuelsidler/) [Samuel Sidler](https://profiles.wordpress.org/samuelsidler/) 8:33 pm _on_ February 25, 2016 Tags: tags    # 󠀁[Re-thinking “Tags” in the Plugin Directory](https://make.wordpress.org/plugins/2016/02/25/re-thinking-tags-in-the-plugin-directory/)󠁿 Howdy all you wonderful pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory [https://wordpress.org/plugins/](https://wordpress.org/plugins/) or can be cost-based plugin from a third-party. authors! [As you may have read](https://make.wordpress.org/plugins/2016/02/26/theres-a-revamp-coming/), the metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. team is kicking off a [rewrite and redesign of the plugin directory](https://make.wordpress.org/meta/2016/02/25/plugin-directory-v3/). As part of our work, we’re considering every aspect of the plugin directory, thinking through ways we can improve the experience for WordPress users everywhere. If you’re interested in following our work, [follow make/meta](https://make.wordpress.org/meta/). In considering tags, we looked at a few things that seem to make the experience less-than-ideal for users. 1. Tags are freeform with a recommended maximum of 12. This leads to plugins “duplicating” tags in the hopes of moving to the top of search results. For example, “anti-spam” and “antispam” exist for [Akismet](https://wordpress.org/plugins/akismet/). Freeform tags also mean that misspellings can occur. 2. Tags are not localizable. If you’ve used the plugin directory in another language, you’ll note that tags are translated into those language. For example, [the Japanese plugin directory](https://ja.wordpress.org/plugins/akismet/) has English tags. Users who attempt to find “スパム” instead of “spam” will have a hard time finding relevant plugins. 3. Tags are inconsistent. Finding the best anti-spam plugins using tags requires looking at the “anti-spam,” “anti spam,” “antispam,” “spam,” “comment spam,” etc tags. This makes it considerably harder for users to find what they’re looking for. These issues have built over time. They’re not new, but they weren’t inherent issues when the plugin directory was first developed. Looking at a new plugin directory, we’d like to change things up a bit and do the following: 1. Create a common set of tags. We’ll create this set by crawling all tags in the plugin directory and finding the most popular ones. From there, we’ll search for duplicates (e.g., spam vs anti-spam) and merge them together too. 2. Allow plugin authors to set a maximum of three (3) tags for their plugins. While this may seem limiting, because we’re working from a common set, there’s very little reason to have a large amount of tags and no need to worry about duplicating tags. 3. “Match” tags when importing into the new plugin directory. When we’re ready to launch the new plugin directory, we’ll do a final import from the current bbPressbbPress Free, open source software built on top of WordPress for easily creating forums on sites. [https://bbpress.org](https://bbpress.org) database into WordPress. During this import, we’ll do our best to match tags from one to the other. For example, if we have a “Spam Protection” tag, we’ll match “spam” and “anti-spam” and Akismet the “Spam Protection” tag. 4. Move tags from the readme into the plugin admin. As part of our work, we’re building an admin interface for plugin authors to manage certain aspects of their plugin. We’ll add tags to this interface so you no longer have to commit to SVNSVN Short for "SubVersioN", it's the code management system used to maintain the plugins hosted on WordPress.org. It's similar to git. to update your plugin’s tags. 5. Make these tags available for translation. Just as the rest of the plugin directory interface will be translatable, tags will be fully translatable too. If tags now sound a lot like categories, well, that’s intentional. 🙂 At the moment, we’re thinking it makes sense to keep calling them tags, keeping consistent with the previous and current iterations of the plugin directory. Requesting new tags would happen on meta tracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.[https://core.trac.wordpress.org/](https://core.trac.wordpress.org/)., working closely with the plugin review team. To be clear: **This is a proposal and we want your input!** So, what do you think? Leave your feedback here! [#tags](https://make.wordpress.org/plugins/tag/tags/) [ ](https://profiles.wordpress.org/ipstenu/) [Ipstenu (Mika Epstein)](https://profiles.wordpress.org/ipstenu/) 6:58 pm _on_ January 20, 2016 Tags: [reminder ( 30 )](https://make.wordpress.org/plugins/tag/reminder/), tags    # 󠀁[Reminder: Policy About Tags In Plugin Readmes](https://make.wordpress.org/plugins/2016/01/20/reminder-policy-about-tags-in-plugin-readmes/)󠁿 This is a reminder of current policy. We ask that users limit tags in their plugins to no more than 12 (**twelve**), with some exceptions. Any time your pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory [https://wordpress.org/plugins/](https://wordpress.org/plugins/) or can be cost-based plugin from a third-party. has a high number of tags, you’re seen as trying to game the system. How do you fix this? 1. Remove any ‘common misspellings’ from your tag list 2. Remove duplicate tags 3. Don’t use ‘wordpress’ or ‘wp’ in your tags 4. Don’t use tags that don’t apply 5. Don’t use your **competitors** in your tags (if you’re not a woocommerce plugin, don’t list it) 6. Don’t list everything under the sun related to your plugin 7. Do use tags that clearly identify what your plugin is As much as some people like to think, “tags” are not the same as “search terms” in our system, so including lots of them doesn’t really benefit you much. By adding multiple tags, you reduce the efficacy of searches and tags for everyone and make the experience of looking for a plugin suck. Yeah. You did that to yourself. If you’re looking to improve your search rankings, we suggest improving the parts of the readme intended for human beings to read. The short and long descriptions should be clear and useful. Addressing common problems in the “FAQ” section helps too. The entire contents of the readme file is considered for the search, and tags are really only a small part of that. Removing irrelevant pieces such as lists of languages (like links) or feature bullet points may help a lot as well, to reduce the overall length and to help eliminate irrelevant information about the plugin. Make the readme for people, not for machines, and it will help you rank higher in the search results. People actually search for solutions to their problems, not simply for keywords. [#reminder](https://make.wordpress.org/plugins/tag/reminder/), [#tags](https://make.wordpress.org/plugins/tag/tags/)