Make WordPress Plugins

Tagged: directory Toggle Comment Threads | Keyboard Shortcuts

  • Samuel Wood (Otto) 9:53 pm on November 11, 2015 Permalink |
    Tags: banners, directory   

    Making Better Banners for your Plugins 

    With the plugin directory now being converted to use language packs, it’s more and more likely that your plugin will be translated by others and available in our various international plugin directories. But banners are kind of a problem for a few of those directories.

    Compare the Hebrew plugin directory to the English plugin directory. One thing you’ll probably notice right away is that the icons are on the other side. Hebrew is a Right to Left language, so the design for it is flipped. Click through to any of the plugin and you’ll notice something else: The banner image is the same, but the title is now on the opposite side of the page.

    For some plugins, especially those who designed banners thinking that the title was in a fixed place, this can present a problem.

    Probably the best solution is simply to make your banner work with either method. Compare Ninja Forms old banner vs. their new banner:





    For another example, take a look at Yoast’s SEO plugin.





    It’s an interesting stylistic difference, but the point is that they simply made the banner work for either case of title positioning. That’s honestly the best solution, IMO, because it also eliminates something from the banner that shouldn’t be there to begin with: Text.

    Text in images is bad. It’s non-accessible. Screen-readers can’t read it. It’s non-translatable to other languages. It’s a pain. Avoid it.

    However, sometimes people really like their designs. The design of a banner says a lot about the plugin, even though it’s just a big image. Some authors may want to be able to adjust their banner designs to adapt to the RTL language pages.

    For this reason, a couple of weeks ago, we added RTL support to the banners. I’ve been holding off on announcing this here to make sure it worked okay, and it appears to work fine, so, here’s the announcement. 🙂

    How to do it? There’s no magic to it. Just make your new banner, and name it with -rtl at the end of the name. Banner images live in the same directory as always, /assets. Nothing else changes.

    An example if you want to see how this looks in the SVN: https://plugins.svn.wordpress.org/pluginception/assets/

    And how it looks on the plugin page:





    Strictly speaking, the banner on Pluginception didn’t need to be reversed. I only did so as a demonstration, to show you how it’s done. Nothing tricky to it.

    In the future, adding support for specific locales may or may not happen. It is undecided if it is necessary, because, frankly, there’s a LOT of locales we have. Who wants to make individual banner images for 80+ languages? Best to just leave the text out of the banner instead.

    Note that while the RTL banners are now active for WordPress.org, they have not yet made their way into core, so the banners won’t yet show up properly in WordPress installations. Working on it. 🙂

    • Joost de Valk 10:08 pm on November 11, 2015 Permalink | Log in to Reply

      Honestly the solution we chose is…. Far from optimal. I’d prefer having the option to make RTL and LTR banners. We do similar things in CSS in WP core.

      • Samuel Wood (Otto) 10:08 pm on November 11, 2015 Permalink | Log in to Reply

        Joost: Keep reading. 🙂

      • Joost de Valk 10:08 pm on November 11, 2015 Permalink | Log in to Reply

        (Ugh, hit enter too early): so we’ll actually update ours.

        • Samuel Wood (Otto) 10:10 pm on November 11, 2015 Permalink | Log in to Reply

          If you’re interested, this is entirely implemented with CSS, and the data is available to the core installs via the API, so getting this in core should not be difficult. Might be a bit late for 4.4 though. Oh well, it can wait for 4.4.1 or what have you.

          • Ahmad Awais 6:59 pm on November 12, 2015 Permalink | Log in to Reply

            That’s true! Would be fun, though. I think this is a much better way to deal with this problem. Thanks for implementing it Samuel.

      • FolioVision 1:11 pm on December 3, 2015 Permalink | Log in to Reply

        Two banners is certainly aesthetically offers much more scope for creativity and design. Last time I checked WordPress was not by programmers for programmers product (functionalism only). Design questions matter.

    • Rami Yushuvaev 10:30 pm on November 11, 2015 Permalink | Log in to Reply

      In other words, plugin authors has two options:

      1. Create one bidirectional banner – https://GenerateWP.com/how-to-improve-your-plugin-header-image/

      2. Create two banners for LTR and RTL views.

    • jeffmcneill 2:12 am on November 12, 2015 Permalink | Log in to Reply

      > The design of a banner says a lot about the plugin

      No, it doesn’t. The design of a banner should convey something about the plugin, the author, or a brand, but it doesn’t “say a lot” about it. There are crap plugins with good banners, and good plugins with crap banners. there is no essential link between banner quality and plugin quality, banner functionality and plugin functionality, or any other aspect. The tail should not try and wag the dog.

      • Samuel Wood (Otto) 2:59 pm on November 12, 2015 Permalink | Log in to Reply

        > there is no essential link between banner quality and plugin quality

        Sure there is: The author. A spammy looking banner probably has a spammy plugin behind it. Not saying this is always true, but hey, take a closer look at some of the banners on what you might consider to be “bad” plugins.

    • Rene Hermenau 9:08 am on November 12, 2015 Permalink | Log in to Reply

      I love the new banner RTL feature. Thanks for this!

    • dartiss 9:55 am on November 12, 2015 Permalink | Log in to Reply

      Brilliant solution Otto, thanks. I hadn’t considered this when designing my banners. Making alternative RTL banners is going to work best for me, so I have some work to do!

    • Torsten Landsiedel 12:22 pm on November 12, 2015 Permalink | Log in to Reply

      Great work! Thanks Rami for bringing this up and Otto for this solution!

    • Alex Mills (Viper007Bond) 1:11 am on November 13, 2015 Permalink | Log in to Reply

      One problem I see with Yoast’s SEO plugin’s solution is that in some languages the title could be very long and go on top of the center logo. Just something to keep in mind.

  • Ipstenu (Mika Epstein) 7:25 pm on February 27, 2015 Permalink |
    Tags: directory, ratings, , reviews   

    Ratings Rebuilt 

    Did your ratings suddenly change dramatically? Hopefully not, but if they did, it’s because the ratings for all plugins were recently reset and rebuilt earlier this week. All ratings now correspond exactly with existing, non-deleted, reviews.

    As Otto put it:

    Back when we launched the review system 2.5 years ago, we tied ratings to reviews. However, up until that point, we had existing ratings in the system. At the time, some argued that the ratings should be wiped and everybody start fresh. I argued for the opposite, that we should leave the existing ratings in place until such time as we had enough reviews in the system to build up a good body of ratings.

    That time has finally come. What you see now is the ratings that correspond to your reviews. The data comes directly from the reviews themselves, and is accurate. Any ratings previously left over from the pre-review world are no longer available.

    Additionally, the ratings now will accurately reflect the actions of the moderation team. If a review is deleted for whatever reason, then the associated rating for it will not be reflected in the results.

    Please keep in mind, this means that all of the people who thought making sockpuppets to spam the reviews with 5-stars on their own plugins (or 1-stars on their competitors) have had the biggest swings. It should go without saying that you should never leave multiple reviews on your own product (we’re pretty sure you like it 😉 ) and you should never attempt to hide behind proxies and fake accounts to leave reviews. Be honest. It works out better.

    • Drew Jaynes 11:11 pm on February 27, 2015 Permalink | Log in to Reply

      Awesome! Thanks for the update @ipstenu 🙂

    • jeangalea 3:27 am on February 28, 2015 Permalink | Log in to Reply

      These changes are very welcome, thanks! I also notice that there is now an estimate of the number of installs on the main page of every plugin, rather than the amount of times it has been downloaded. How is that figure being calculated? I’d like to know how accurate it is.

    • Varun Sridharan 8:07 am on February 28, 2015 Permalink | Log in to Reply

      Awesome!.. thanks for good update .. @ipstenu

    • WPSecureOps 11:40 am on February 28, 2015 Permalink | Log in to Reply

      Oops, we’ve some weird error on our plugin’s stats page:
      “Cannot read property ‘title’ of undefined×”

      Any ideas what can be causing that?

      • WPSecureOps 11:41 am on February 28, 2015 Permalink | Log in to Reply

        In case that this is helpful: Chrome Version 40.0.2214.111 (64-bit) (OSX)

      • Samuel Wood (Otto) 5:31 pm on February 28, 2015 Permalink | Log in to Reply

        This has nothing to do with the ratings, as the stats are a separate change still being worked on. However, the people in the know about that have been notified of the issue and will look at it soon. 🙂

        • WPSecureOps 5:30 pm on March 1, 2015 Permalink | Log in to Reply

          At least, i’m happy that I was able to help to report another problem then 🙂

          Good luck with the new stats, they look awesome, especially this new version specific bar!

    • Varun Sridharan 1:58 am on March 1, 2015 Permalink | Log in to Reply

      Can i please know how do you calculate `Active Installs: Less than 10`. because
      https://wordpress.org/plugins/wpsecureops-easy-firewall/ = is used by more that 10 live sites. but in that status its only less than 10 ??

      • Ipstenu (Mika Epstein) 2:23 am on March 1, 2015 Permalink | Log in to Reply

        That code isn’t complete yet, which Otto said in the post above. Obviously there’s an issue, since the graph isn’t even showing. Don’t spend your time worrying about this yet, we’ll post and explain it when it’s done.

        Now if you have a question about the RATINGS, please let us know. That’s done and that’s why we posted here 🙂

      • WPSecureOps 5:33 pm on March 1, 2015 Permalink | Log in to Reply

        You are using our plugin on more than 10 live sites?!

        WOW! We are really happy to hear that !!!!

        If you have any feedback/suggestions/need of help or simply want to say “Hi!”, don’t hesitate to ping us at support@wpsecureops.com 🙂

        PS: Sorry for going a bit off topic, but …. 🙂

    • Joachim Jensen (Intox Studio) 5:09 pm on March 1, 2015 Permalink | Log in to Reply

      I wondered why the total number went down for Content Aware Sidebars, but the average rating didn’t change. This “cleanup” is appreciated very much!
      I’ve noticed a few plugins with very questionable reviews though, and those have not been removed? I won’t call out anyone, but I’ll be glad to give the info to @ipstenu so you can check it out?

    • Chad Butler 10:15 pm on March 2, 2015 Permalink | Log in to Reply

      Thanks for the update Mika. I am really glad to see this change implemented as it will improve the usefulness of the rating system.

    • Ajay 12:43 pm on March 6, 2015 Permalink | Log in to Reply

      Mika, this cleanup is definitely a good one. Helped improve ratings on most of my plugins. However, there remains one issue that might be worth considering. Some plugins have very few reviews. Shouldn’t there be a threshold post which you start displaying ratings? e.g. maybe 10 reviews/ratings?

  • Samuel Wood (Otto) 6:12 pm on June 9, 2012 Permalink |
    Tags: directory, plugin, readme, , svn   

    The Plugins directory and readme.txt files 

    Every once in a while, somebody pings me to say that their plugin isn’t showing up properly in the directory. Almost always it’s a problem with the plugin itself having incorrect information somehow. So I thought I’d do a quick post to explain some aspects of the plugin directory, and explain some of the more obvious stuff which a lot of people miss.


    First, let’s briefly go over the layout of your plugin in the SVN repository. There’s three directories created by default, and an optional fourth one that you can create yourself.

    Trunk: The /trunk directory is where your plugin code should live. The trunk can be considered to be the latest and greatest code. It’s the development version. Hopefully, the code in trunk should always be working code, but it may be buggy from time to time because it’s not necessarily the “stable” version. For simple plugins, the trunk may be the only version of the code that exists, and that’s fine as well.

    Tags: The /tags directory is where you can put versions of the plugin at some specific point in time. Usually, you’ll use version numbers for the subdirectories here. So version 1.0 of the plugin would be in /tags/1.0, version 1.1 would be in /tags/1.1, and so forth. Again, not every plugin uses tags for versioning.

    Branches: The /branches directory is a place that you can use to store branches of the plugin. Perhaps versions that are in development, or test code, etc. The WordPress.org system does not use the branches directory for anything at all, it’s considered to be strictly for developers to use as they need it.

    Assets: The last optional directory doesn’t exist by default (Edit: It does now, older plugins may be missing it, but all newly added plugins will get it by default.) You can create it yourself though. Just make a directory called “assets” next to those other three directories. Assets currently only has one use, which is to store the banner image to be displayed on your plugin page. We may use it for more things in the future. For now, you can just make an image, name it banner-772x250.png or banner-772x250.jpg, and put it in there. Easy.

    Additional Info: Since creating this post, some new files have been added to the assets folder. You can create a banner-1544x500.png or banner-1544x500.jpg now too. This high-resolution banner will be shown to users with high-resolution displays, such as phones or tablets or certain newer laptops. Additionally, screenshots which once lived in the plugin’s own directory can now be moved from there into the assets directory. This allows the screenshots to be shown on the plugin page, but not included in the download of the plugin, reducing file size. It’s recommended to put screenshot files in /assets.

    Parsing the plugin information

    All plugins contain a main PHP file, and almost all plugins have a readme.txt file as well. The readme.txt file is intended to be written using a subset of markdown.  The example readme.txt explains most everything pretty well, but there’s a few little tidbits that are worth pointing out.

    First is the concept of the “Stable Tag”. When WordPress.org parses the readme.txt, the very first thing it does is to look at the readme.txt in the /trunk directory, and then read that “Stable Tag” line. If the Stable Tag is missing, or is set to “trunk”, then the version of the plugin in /trunk is considered to be the stable version. If the Stable Tag is set to anything else, then it will go and look in /tags/ for the referenced version. So a Stable Tag of “1.2.3” will make it look for /tags/1.2.3/.

    Important bit: Everything else is read from this new location. If the Stable Tag is 1.2.3 and /tags/1.2.3/ exists, then nothing in trunk will be read any further for parsing by any part of the system. If you try to change the description of the plugin in /trunk/readme.txt, and Stable Tag isn’t trunk, then your changes won’t do anything on your plugin page. Everything comes from the readme.txt in the file being pointed to by the Stable Tag.

    Now let’s get to the plugin information itself. The WordPress.org directory reads the main plugin PHP file to get things like the Name of the plugin, the Plugin URI, and most importantly, the version number. On the plugin page, you’ll see the download button which reads “Download Version 1.2.3” or similar. That version number comes from the plugin’s main PHP file.

    Some people get this versoning confused due to the tags system. The Stable Tag points to a subdirectory in the /tags directory. But the version of the plugin is not actually that, it’s the version that is listed in the plugin’s PHP file itself. If you have changed Stable Tag to 1.4 and the plugin still says 1.3 in the PHP file, then the version listed will be 1.3.

    Readme.txt pieces that everybody gets wrong

    Back to the readme.txt. There’s a line called “Contributors”. This line has always been expected to be WordPress.org usernames only. WordPress reads those, gets information about that user, gets their gravatar, name, etc, and makes the authors listing. If you put anything here that’s not a WordPress.org username, then it doesn’t look nearly as good. No picture, no link, just text.

    Other information in the readme.txt is read and used at various points on the Plugin listing. The Donate link makes a “Donate to this plugin” link in the sidebar. The “Requires at least” and “Tested up to” fields are used for compatibility checking, even on the WordPress installation itself. Few people get these wrong.

    One thing a lot of people get wrong is this line:
    “Here is a short description of the plugin.  This should be no more than 150 characters.  No markup here.”

    That bit is serious, and you should read it again. That one line people get wrong more often than anything else. That line of text is the single line description of the plugin which shows up in big letters right under the plugin name, and if it’s longer than 150 characters, it gets cutoff and makes your plugin page look silly.

    Markdown allows for easy linking in your readme.txt as well. Just write like this to link a word to a URL:


    Videos can be put into your readme.txt too. A YouTube or Vimeo link on a line by itself will be auto-embedded. It’s also possible to embed videos hosted on VideoPress using the wpvideo shortcode. More on that topic here: http://wpdevel.wordpress.com/2010/02/20/plugins-can-now-include-videos-in-their-readme-txt-files/


    I don’t think I covered everything, but hopefully that will explain some of the more obscure features of the directory and how it works. If it reduces the number of times people send me the question “why didn’t my version change show up in the directory”, then I think this post was time well spent. 🙂

    • Marcus 7:32 am on June 10, 2012 Permalink | Log in to Reply

      I must admit, I’ve made one or two of these mistakes starting off 🙂

      Useful article, it would go great linked somewhere in the developer center, as I’m sure that’s where people starting would look first.

    • Lance Cleveland 2:37 pm on July 12, 2012 Permalink | Log in to Reply

      Don’t forget about the new “high definition” banners for the header image. If memory serves this is twice the resolution of the standard banner in the assets directory at 1444×500.

    • Mike Schinkel 7:16 pm on August 3, 2012 Permalink | Log in to Reply

      Just replying so I can get subscribed to this blog (might be another way, but can’t figure out how.)

    • Brad Touesnard 3:53 pm on August 17, 2012 Permalink | Log in to Reply

      @Otto Would it be possible to start supporting the filename README.md in addition to readme.txt? A lot of developers host their plugins on GitHub as well but the filename readme.txt isn’t run through the markdown parser at GitHub. It would be nice if .org supported the README.md filename as well.

    • Gwyneth Llewelyn 10:12 pm on November 18, 2012 Permalink | Log in to Reply

      Ok, I’m a bit confused now.

      “If the Stable Tag is 1.2.3 and /tags/1.2.3/ exists, then nothing in trunk will be read any further for parsing by any part of the system. If you try to change the description of the plugin in /trunk/readme.txt, and Stable Tag isn’t trunk, then your changes won’t do anything on your plugin page. Everything comes from the readme.txt in the file being pointed to by the Stable Tag.”

      So if I understand this correctly, the best way to deal with this scheme is simply to have a single file under /trunk/, which is readme.txt, and that needs only to hold 9-10 lines or so with the headers — and just point to the “Stable Tag”? Then the *rest* of the readme.txt *which is under the tag, not trunk* will be read & parsed instead? I don’t need to have a full copy of readme.txt both under /trunk/ *and* /tags/X.Y.Z/ ?

      You see, I hate unnecessary file duplication 🙂 I love the idea of having a super-small, 9-line only, readme.txt file under /trunk/ which just points to the correct place. Also, it makes this far easier to revert to earlier versions in case something goes seriously wrong!

      Sorry if all of this sounds incredible obvious to you seasoned plugin developers 🙂

      • Gwyneth Llewelyn 10:44 pm on November 18, 2012 Permalink | Log in to Reply

        Maybe all that’s needed on trunk/readme.txt is 2 lines after all:

        === Plugin Name ===
        Stable tag: X.Y.Z

        Is that right? The remaining readme.txt will come from tags/X.Y.Z instead? If so, this is just awesome!

      • Samuel Wood (Otto) 4:38 am on November 19, 2012 Permalink | Log in to Reply

        Yes, that works.

        No, you absolutely should not do it that way.

        There is a *convention* in place here. People expect trunk to contain the latest development code of your plugin. In other words, the latest and greatest code, unstable changes and all, belongs in trunk. The latest stable, versioned, tagged code, will be in a tags directory.

        The directory is based around this concept. There are beta-tester plugins which assume this to be true. Forget about “duplicated files”, do it the way everybody else does it so that you don’t mess up the friggin’ system. 🙂

        Put your development code in trunk. Tag the ready-for-release versions of the code in the tags directory. This is the best way to manage things. Even repository systems such as git and github have the concept of a main trunk for development and tags for versioning. The goal isn’t to make things easier for you to manage, the goal is to make the code accessible to everybody else in a sane way.

        • Gwyneth Llewelyn 4:42 pm on November 19, 2012 Permalink | Log in to Reply

          Thanks for the clarification and I do apologise if I have understood you wrongly. Maybe you should clarify that duplication of everything continues to be mandatory, and not optional, to stick to conventions. Your article, read in a certain light, seemed to convey the idea that the convention was changed exactly for the benefit of keeping things simple.

          I’m not here to discuss what is better and what is not — I’ve just asked the question on how to do things from now on because the article lead to believe me that the convention had changed, or, if it hadn’t, that “beginners were always making mistakes and can do things in much simpler ways if they understand the directory structure better”. And I appreciate your answer: no, nothing has changed.

          “The goal isn’t to make things easier for you to manage”. Why not? KISS is always a good philosophy, IMHO.

          • Samuel Wood (Otto) 4:59 pm on November 19, 2012 Permalink | Log in to Reply

            It’s not really duplication though. SVN doesn’t store files that way, it really just stores changesets. The trunk/tags/branches convention is SVN’s, not ours. You can tag things using an svn copy operation, and that’s not making new files in svn, just marking copies of the files at a specific point in time.

            The Stable Tag and readme.txt stuff is indeed ours, simply for the purpose of keeping things in the directory sane.

    • brasofilo 2:08 pm on December 18, 2012 Permalink | Log in to Reply

      Finally I got the /tags/ concept and am correcting a wrongful use of the “Stable Tag” (I had it declared, but the version was not present in the tags folder), although the system was kind enough to make it work.

      Now, I’m looking for articles on how to use the /trunk/ when developing a new version of the plugin.
      I mean, is it possible to install and update from there?

      • Samuel Wood (Otto) 5:56 pm on December 18, 2012 Permalink | Log in to Reply

        Trunk should be the “beta” version, and have its version numbers indicating such. So if my Stable Tag was like 1.0, and I had a /tags/1.0 directory, then I could make trunk’s version into 1.1-beta or something like that, and make all the changes I liked, then when it was ready for release, change it to 1.1 and tag it and update the Stable Tag field in the readme.txt to point to the new one.

        If you use this sort of structure, with trunk containing the latest beta code, then you can easily use a plugin like https://wordpress.org/extend/plugins/plugin-beta-tester/ to update to that beta version on a site.

        • brasofilo 7:29 pm on December 18, 2012 Permalink | Log in to Reply

          Perfecto, Otto, gracias!

        • Hinjiriyo 1:56 pm on January 31, 2014 Permalink | Log in to Reply

          Now I got the concept of the trunk dir! Thank you very much for your explanation.

          There are other informations about the way the readme file and tag files are processed by the WP plugin repo. I wish someone would extend the Plugin Developer FAQ with that article and the role of the trunk.

    • amineoujda 10:09 am on July 16, 2013 Permalink | Log in to Reply

      I want to change the line description that appears below the plugin name

    • bendoh 4:44 pm on January 22, 2014 Permalink | Log in to Reply


      Is there any sort of documentation as to the exact subset of Markdown that’s being used on these readme.txt files, or could you perhaps point me to the code that’s actually producing the rendered markup?

      I just submitted a plugin with standard Markdown list formatting, (e.g., * Item 1\n*Item 1) in the readme.txt, and it was not rendered correctly on the plugin page: it just appeared all together in one paragraph without any markup.

    • duck__boy 9:32 am on April 14, 2014 Permalink | Log in to Reply

      A very will written post, but I must admit, I’m still struggling with the `readme.txt` file. I suspect I’m just missing something, but I’m hoping you are able to help.

      I have both a version of my plugin with the `readme.txt` file, in the `/trunk` and `/tag/1.2.4` folders, but none of the details from `readme.txt` seem to be read, including the Stable Tag. This also means that the `Installation`, `FAQ` and `Changelog` sections are not available on the plugins `Details` page).

      So taking the above in to account, if I change the version number of the main PHP file in `/trunk` to say `1.3-beta`, that version number is shown when you search for my plugin, and my `/tag/1.2.4` file is ignored.

      The plugin in question is https://wordpress.org/plugins/admin-bar-button/

      • duck__boy 3:31 pm on April 22, 2014 Permalink | Log in to Reply

        Just in case anyone ever runs in to this, my issue was that my `readme.txt` file was not encoded as ANSI for some reason. I simply recreated the file using the correct encoding and all is now good with the world (well, my plugin anyway…).

    • Chip Bennett 5:02 pm on April 22, 2014 Permalink | Log in to Reply

      @Otto42 is there any chance that the readme parser could be changed so that it reads “Tested up to” and “Requires” from the trunk copy of readme.txt? It would sure make it a lot easier for Plugin developers to update this information in the Plugin directory. As it is right now, we either have to update the readme.txt in the stable tag readme.txt, or else bump the version number just to indicate that the Plugin has been tested and works with the latest WordPress version.

      • Samuel Wood (Otto) 5:03 pm on April 22, 2014 Permalink | Log in to Reply

        You can edit the readme.txt file in a tagged version. SVN isn’t like Git, it doesn’t have a restriction preventing you from editing tagged versions.

        I’ll think about using the trunk readme for other things though, some of this seems like it might be a candidate for a refactoring.

    • Raghunath Gurjar 1:37 pm on June 17, 2014 Permalink | Log in to Reply

      I have released my plugin two version but still on plugin download page its show first release version 1.0 while when you will download my plugin , you will get all latest code.

      You can also find developer log from here https://wordpress.org/plugins/simple-testimonial-rutator/developers/

      Can you someone help me please?
      I don’t know why this happening , i have updated the Stable tag in readme.txt file to 1.2

      • Samuel Wood (Otto) 5:25 pm on June 17, 2014 Permalink | Log in to Reply

        All information in the system is gathered directly from your plugin. If the displayed information is wrong, then your plugin is wrong.

        In this case, notice that the version number in the plugin itself is 1.0:

        Fix the plugin to have the correct information.

        • Natallya 7:21 pm on August 22, 2014 Permalink | Log in to Reply

          Hi, does anyone know how to get feedback for a plugin published?
          It’s more then month we sent it for review but no information at all. How can I know if it was declined ?

          Thank you!

          • Samuel Wood (Otto) 7:24 pm on August 22, 2014 Permalink | Log in to Reply

            We don’t have any plugins in the queue that have been there for more than a month. You would have received an email about it, and if we got no answer for 7 days, then it would be automatically rejected and you would receive an email about that too.

            Make sure that your email system is set up to never spam any emails coming from WordPress.org. We send emails for lots of things, but we cannot control what your end does with them.

          • Samuel Wood (Otto) 7:26 pm on August 22, 2014 Permalink | Log in to Reply

            Looking closer, it appears that your plugin was approved and you never continued on and did anything with it. Again, check your emails, your plugin was approved on the 11th of last month.

    • Natallya 5:46 pm on September 4, 2014 Permalink | Log in to Reply

      Thanks a lot, email had gone to junk… Setting up all further things. Thank you again for a good news! 🙂

    • JayDeep Nimavat 12:34 pm on October 4, 2014 Permalink | Log in to Reply

      Hello wordpress friend,

      I have created new version of “JDs Portfolio” plugin,

      I have done change,

      • deleted all folder and files from Repository trunk directory and uploaded new files and folder of new plugin version.
      • Created new directory 1.1 in Tags directory where 1.0 is already available and I uploaded all new files and folder of new plugin version in 1.1.

      The duration of uploaded new version plugin is more than one day.

      The problem is that it still give old version of plugin when anyone download it, and shows in Developer option as other version, as current version it display me old version 1.0.1 of JDs Portfolio plugin.

      Please help me to solve :
      How can I apply new version of plugin as current version?

      your good suggestion most appreciate,
      Thanks a Lot’s,

    • salescart 4:45 pm on October 8, 2015 Permalink | Log in to Reply

      Ok, I’m sorry but I’ve read this and I’m still confused. We tried to make our first revision at https://plugins.svn.wordpress.org/e-commerce-by-salescart/tags/1.1.0/

      1.) So are you saying it still looks at the readme.txt file in the /trunk folder to find the stable tag, and based on that that, it then goes to that /tags folder for the plugin content and will ignore the rest of the content in the /trunk folder?

      2.) Or, are you saying the only released version is ALWAYS the version at the trunk? (This would be despite the readme.txt file’s stable tag saying 1.1.0 instead of trunk and that the tags folders is just for historical reference). Therefore, the /trunk version must be the most up-to-date version… ?

    • webbistro 9:29 am on January 10, 2016 Permalink | Log in to Reply


      I’ve read this carefully, and I uploaded new versions many times, but I am afraid I need help now. I am sure that all data is correct in my tag and trunk readme-s and in the main php, but I still see the old description, changelog, everything below readme’s header. The significant differences from the previous updates is that I am not receiving email notifications any more.
      Please help https://wordpress.org/plugins/enhanced-media-library/ (I know, too many actions… but I hoped I just did something wrong).


  • Andrew Nacin 8:51 pm on May 19, 2012 Permalink |
    Tags: directory, favorites,   

    Plugin Directory Refreshed — What It Means for Developers 

    Matt just announced on the WordPress Blog — and many of you have already noticed — a number of recent changes to the plugin directory, profiles, and the support forums. Now let’s go into detail all of the individual changes, and what it means for plugin developers.

    Design refresh for plugin pages.

    We’re glad to see so many of you use the plugin headers we launched in December. Now, we’ve provided a further refresh. We’ve made authors much more prominent and with bigger Gravatars and better placement, and cleaned up the styles for the ratings, support, and compatibility sections. There’s a great before-after shot in the announcement post.

    Support is now integrated into your plugin page.

    In the past, creating new support topics for plugins has been special, and not in a particularly good way. It had this specialness by overloading the tags in the support forums to indicate that a thread was about a particular plugin. No longer. We’ve promoted plugins up a notch and given them their own area.

    So now, on your plugin pages, you’ll see a “Support” menu in the header, and you’ll see the topics for that plugin in that tab. You’ll also find a submission form at the bottom of that tab, to add new support topics specifically for your plugin. Topics about plugins made from here get a special sidebar with links to the plugin, to the plugin’s FAQ page, and to the list of Support Threads for that plugin.

    While this section looks like it’s on the Plugin’s page, it’s not really. These support threads are actually in the same place they’ve always been, in the Support forums. What you’re seeing as far as the look and feel of that view of the support forums is just some clever trickery on our part. 🙂

    Akismet, for example, will have it’s “support forums” at this URL: https://wordpress.org/support/plugin/akismet.

    How to follow support threads for your plugins.

    You may want to take advantage of this by subscribing to the RSS feed for your plugin: https://wordpress.org/support/rss/plugin/akismet. Email subscriptions are not available for these yet, but we will be adding them this week.

    For plugin authors who have been using them, the old convenience views of plugin-committers and plugin-contributors are still there as well. (Committers are managed in on the Admin tab, while contributors are taken from readme.txt.) We’ll be exposing these links in more places, but you can use them with URLs similar to the following: https://wordpress.org/support/view/plugin-committer/Otto42 https://wordpress.org/support/view/plugin-contributor/Otto42. (RSS feeds exist for these as well.)

    Support statistics are now shown to users.

    You’ll notice a new area on the plugin page sidebar showing information about how many topics there are for your plugin, and how many of them have been marked as resolved. These are handy for users to see if questions are likely to get a response.

    You have had the ability to mark plugin support threads as resolved for some time now. It’s now really easy — you can mark a thread as resolved while making a post with a simple checkbox. Note that the user who opened the thread can also mark threads as resolved and unresolved. Threads that are marked “Not a support question,” such as suggestions or feedback, are not counted toward these stats and do not need to be marked resolved.

    Statistics will be based on a rolling two-month period, based on when the thread was opened. Currently, the statistics cover threads opened in the last two weeks, and will continue to increase until it reaches two months, to allow you some time to resolve existing threads.

    Managing your forum with sticky topics.

    You can now make threads “sticky”  threads to the top of your plugin’s support forum, just like the other forums on WordPress.org. (You’ll find a link “Stick topic to this plugin’s support forum” in the sidebar.) Threads marked as sticky will show at the top of your plugin’s Support tab. (They won’t be sticky on the regular forums.) We hope you find this handy for posting FAQs or other important information about your plugin.

    A new section for developers.

    Every plugin now has a Developers tab where you can find links for browsing the code in Subversion, the development log, and development versions. Here, you can now subscribe to get an email whenever a commit is made to a plugin repository, even if it isn’t yours. (You will of course continue to receive commits for your own plugins.)

    Favoriting plugins.

    As I’m sure you’ve now seen, plugins can now be favorited by logged-in users — and have been more than 2,000 times since we soft-launched this feature earlier in the week! When you favorite a plugin, it gets added to your profile. And if you’ve also rated that plugin, your rating gets shown.

    We expect to do a lot more with all of this in the future — favorites, plugins, support, and profiles. Until next time, we hope you enjoy these changes as much as we do!

    — written by Nacin, Otto, and Scott

    • Arnan de Gans 5:15 pm on May 21, 2012 Permalink | Log in to Reply

      So i guess you’ve just rendered my own forum useless? Because i don’t want to give my users the impression i ignore support. Which your support stats will suggest if i keep ignoring the WP forums and use my own setup…
      And what’s up with this whole overhaul anyway, pulling visitors away from my plugin page by adding all these features. 🙁

      • Andrew Nacin 10:02 pm on May 21, 2012 Permalink | Log in to Reply

        The plugins directory is a hosting site, not a listing site. Your “plugin page” is https://wordpress.org/extend/plugins/your-plugin/ — while it may provide you traffic to your own site, it’s designed to be a dedicated and trusted area for users. If plugin authors don’t keep up with support topics on WordPress.org, we can no longer glean any statistics, and it is more difficult for users to identify which plugins are supported. I have been really happy to see so many users already benefit from the new tools we are giving developers. That’s a win-win to me.

        We think — and I think you probably agree — that these changes provide a far better experience for individuals looking for help. By choosing to have two support forums, you’ve already fragmented the experience for your users. (I imagine they even need to create a second account to simply provide feedback or ask a question.) Now you are experiencing this same thing for yourself.

        We may consider the ability to specify a location for support in the future, but we’d like to try this out for a while. And at least on WordPress.org, we can also guarantee your users will be greeted with the proper spelling of WordPress. 😉

        • Jon Brown 4:20 am on May 22, 2012 Permalink | Log in to Reply

          Nacin – While that seems sensible on the surface, many plugins don’t lend themselves to a single forum for support and plugin author’s who’ve built forums with multiple topics…

          For example I note that both BuddyPress and bbPress link out to their own forums…. as they should since trying to answer the myriad of support requests under a single tag would be a nightmare. I am not a plugin author (yet), but I feel all plugin authors ought to have this same option available to them to link to their own support location.

          Further there is still no good easy way (that I know of) to search a single plugin’s forum to see if a topic has been mentioned and resolved previously which is what has always rendered the forums on WordPress.org minimally useful to me.

      • Marcus 12:24 pm on May 22, 2012 Permalink | Log in to Reply

        would definitely like this. tried resolving topics myself yesterday, not really up for it 🙂

        Touching on Arnan’s comment above, I must admit I do feel the same way somewhat. Whilst I do value being able to support on WP and agree that ideally (but may not be realistic) support should be on wp.org, I don’t think statistics is a productive feature, at least as it stands right now.

        Constructive criticism below:

        Take my (the author’s) point of view and my plugin – https://wordpress.org/extend/plugins/events-manager/

        The wp support forum is usually visited at least once a day during the week. I myself go through this plugin support forum every weekday when possible, yet as it stands right now the stats are:

        15 of 84 support threads in the last three weeks have been resolved.

        However, look at the forum, and you’ll see they’ve pretty much all been answered by me or angelonwl.

        There’s a few issues here right off the bat:

        • Various questions get resolved by the opener somehow, but the topic never gets updated.
        • Some things are just unreasonable to ask from the author (i.e. how do I completely change this plugin to do what I want?), yet they count as an unresolved question.
        • Various questions aren’t support questions.

        I’m sure there’s more, but the above is already enough to, in my opinion, make this a misleading bit of information.

        As an author, I’m now expected to keep track of 3 weeks of questions, and resolve them proactively, since <50% (way less) of users will update tickets when they resolve things themselves. What's worse, contributors can't help out. I think this is unreasonable, and whilst I don't mind making do, I think this will decrease the overall experience in WP, with some immediate downfalls:

        • Good plugins will likely get misleading support stats.
        • This will likely dishearten many authors, meaning less quality plugins being made for WP.
        • I’m sure you’ll see on the forum a “hey my issue isnt’ resolved!” because it’ll become tempted to resolve every topic one answers.

        I think the most important thing for you to implement to make this work would be some sort of auto-approve or nullify tickets that the creator doesn’t keep on top of (e.g. it becomes not a support question if the author doesn’t reply to our reply in say a week). Or maybe a response rate?

        Don’t even get me started on the works/doesn’t work stats too! 😉

        • Marcus 12:30 pm on May 22, 2012 Permalink | Log in to Reply

          by “would definitely like THIS”, i meant letting contributors be able to resolve tickets

        • Marcel 9:00 am on January 12, 2013 Permalink | Log in to Reply

          +1 for including response rate statistic. Many support requests cannot be resolved because users ask for functionality that the plugin does not, or never will, offer. A state like ’10 of 12 support threads answered by plugin contributor’ would give users a better insight in plugin contributors involvement.

    • Marcus 5:30 pm on May 21, 2012 Permalink | Log in to Reply

      Great work guys! The plugin page keeps looking better and better.

      Who can ‘resolve’ topics, by that I mean committers, contributors etc. of a plugin?

      Is there a way to add users that aren’t committers/contributors so topics can be resolved?

      • Andrew Nacin 6:41 pm on May 21, 2012 Permalink | Log in to Reply

        Committers can resolve topics. At the moment, there isn’t a way to grant someone permission to resolve topics without making them a committer. It might be something we add in the future.

    • Joost de Valk 6:37 pm on May 21, 2012 Permalink | Log in to Reply

      Awesome guys, thanks for all the hard work!

    • ray 8:57 pm on May 21, 2012 Permalink | Log in to Reply

      I’m looking for a like button on this page… thanks

    • Jason Caldwell 12:51 am on May 22, 2012 Permalink | Log in to Reply

      Just wanted to say thanks for the recent changes to the plugin directory, profiles, and the support forums. Great work over there!

      I do want to make a request though. PLEASE give plugin developers the ability to use their own external support forums. That is, please make it possible (perhaps through a readme.txt file), for developers to use an external support forum system of their own.

      Many of the best plugins thrive on support, and you can’t expect us to operate our support departments within an outline set forth by WordPress.org. That is, we can’t be expected to use the support system that WordPress.org uses (we need to use what works for us).

      I, like many other plugin developers, have my own administrative system, support forum system, along with employees to assist me. As the plugin directory exists now, all support is expected to take place at WordPress.org, which is just not realistic. This is only going to result in people getting the wrong impression about plugins in your directory, because they’re looking for (and expecting) support from the forums at WordPress.org. When, in reality, the support for many plugins occurs offsite. Let’s give plugin developers the ability to direct WordPress site owners to the proper location.

    • Myatu 6:40 am on May 22, 2012 Permalink | Log in to Reply

      Couple things…

      Is there a way to see how many people have actually marked a plugin as their favorite, and optionally, who?

      Also, I’d really like to see the email subscriptions for support threads back again, the sooner the better.

      As for support itself goes, that needs some work with respect to what the plugin developer wants (better said, can do). I can understand your point about the consistency in user experience across WordPress plugins and an ability to measure plugin quality, but at the same time, what if a plugin developer would like – or already uses – a ticket system, provides phone support, use their own forum or simply use good ‘ol email, then what? There’s currently no method to integrate that with WordPress.org’s plugin listings, nor do they count toward the quality measurements.

      Something to consider perhaps, is improve the way users can vote on a plugin. More often than not, people do not vote. They install, and use it. Don’t like it, uninstall. That’s it. So, if a user uninstalls, why not ask them “Why are you uninstalling this plugin?” – plugin developers and the community could do with that sort of feedback. And voting from within the WordPress plugins page would be another option, though some care has to be taken to avoid someone using a “bot” on that (which is detectable, and could perhaps be reason for removal).

    • Mike Challis 6:14 pm on May 25, 2012 Permalink | Log in to Reply

      As a plugin author, I now have the ability to make a sticky post. Thanks.
      But after 10 minutes(or 20 or whatever) I have no ability to edit any of my posts. A sticky post is not very useful if I will not be able to edit it later if needed. Please give plugin authors the ability to edit their own posts.

    • Ipstenu 8:16 pm on May 25, 2012 Permalink | Log in to Reply

      Forum mod hat 😉

      The support forums have always been there for plugins, whether or not you used them. So this does make them more prominent, but for now if you don’t want to use them (and you certainly dont have to) I would do this:

      1) Put a link to your support location in your readme. No support at all? Just say that too 🙂
      2) Make a sticky ‘This plugin not supported on these forums.’ And inside, a link to where it is.

      No, it’s not perfect, but when the mods come through and clean up snark like ‘Bob’s a bad dev! He doesn’t help me!’ we can say ‘Well, actually, RTFM. Bob said to go to bobplugins.com instead.’

    • zorro1965 4:32 am on December 14, 2012 Permalink | Log in to Reply

      I have been so waiting for this to become a feature. So much easier then trying to keep a place where you have all these plugin details archived.

      Being able to access these in the backend after you have them marked is HUGE…!

      Now I only have a few suggestions for future.

      1. Allow the member to have ability to create their own categories for favorites to help quickly sort through what you need for a kind of site you are working on or group them for other reasons.

      2. Have a different view choices to see excerpt of description, last updated, ratings, # downloads

      Thanks very much,


compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar