Make WordPress Plugins

Tagged: repository Toggle Comment Threads | Keyboard Shortcuts

  • Ipstenu (Mika Epstein) 12:00 am on November 19, 2015 Permalink |
    Tags: , repository   

    AutoReply Sucks 

    Did you know we have no auto-replies at all sent from WordPress plugins?

    Every single email, even the predefined ones, are written and picked and sent by hand. Even the one that goes out to all 22,573 user accounts with commit access to a plugin.

    But you know what happens when we send out that nice reminder to test on WordPress 4.4?

    We get a few hundred auto-replies from support systems.


    Please change the address on your WordPress.org forums account to one that does not go to an automated support system. We need to be able to communicate directly with plugin authors, and having automated responses don’t help us much.

    THIS IS A REQUIREMENT. If we continue to receive automated responses from your support system, we will have to shut down your plugin and remove it from the WordPress.org directory.

    We require that we have the ability to contact you about updates on a regular basis. If we also get automated responses, then this eats up our time, and is a problem for us.

    Please do whatever is necessary to STOP these automated responses. We would prefer that you use an email address on the forums that goes to actual people, not into a support system. Our forums send emails for all sorts of reasons, and automated responses eat up our bandwidth needlessly, since they don’t go anywhere.

    Basically it’s this: If we can’t get in touch with you, we can’t host your plugin.

    Please whitelist pluginsATwordpress.org and please exclude us from your auto-replies.

    (A quick note – A personal autoreply, like “I’m at a wedding and won’t be back until December 3rd” is not the same thing. Those are fine!)

    • Claudio Sanches 12:30 am on November 19, 2015 Permalink | Log in to Reply

      +1 for “THIS IS A REQUIREMENT. If we continue to receive automated responses from your support system, we will have to shut down your plugin and remove it from the WordPress.org directory.” :)

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


    • Zack Katz 12:54 am on November 19, 2015 Permalink | Log in to Reply

      Serious question: how can I change my profile email? I don’t see it in https://profiles.wordpress.org/%5Busername%5D/profile/edit/group/1/

    • Gustavo Bordoni 1:29 am on November 19, 2015 Permalink | Log in to Reply

      I love this +1 requirement!

    • Lester Chan 2:26 am on November 19, 2015 Permalink | Log in to Reply

      +1 to this! Just received the “WordPress 4.4 is imminent. Are your plugins ready?” Can;t wait!

    • Valerio Souza 2:42 am on November 19, 2015 Permalink | Log in to Reply


    • Matheus Martins 6:11 am on November 19, 2015 Permalink | Log in to Reply


    • Kaspars 10:33 am on November 19, 2015 Permalink | Log in to Reply

      What if a plugin author uses some kind of ticketing system to keep track of things that need to be done? How is that worse than an email being ignored?

      Secondly, are you actually supposed to read all the replies or act on them in any way? There must be equal amounts of “out of office” automated replies and standard rejects.

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

        No, we actually don’t get many out-of-office replies.

        And if you use a ticketing system, then that’s fine. But use it for your own support system, not for the email address we have on the forums.

        Our forums send emails for things like replies, and those are pretty useless to go into a ticketing system, and it is especially useless for you to auto-reply back to the automated email from the forums.

        We need an email that goes to *you*. Not to your support systems. We don’t need “support”, after all. :)

      • Ipstenu (Mika Epstein) 4:17 pm on November 19, 2015 Permalink | Log in to Reply

        We do check if it’s an out of office before sending the notice about no auto reply. Like I said, real humans check every email. We don’t even auto-spam filter.

        It only gets muddled if the email is support@company.com and has an out of office. That’s something where we can’t tell what it is.

    • Rene Hermenau 11:24 am on November 19, 2015 Permalink | Log in to Reply

      I am guily as well and had been on business trip for a few days when the wordpress mailing was send
      I was sending out an autoreply about my trip to tell people that i will answer their mail asap when i am back and they do not have to wonder when i do not answer as fast as usual.

      The predefined mail server i am using is not self hosted and i am not able to exclude pluginsATwordpress.org from autoreplies.

      What do you recommend for this?

      • Rene Hermenau 11:30 am on November 19, 2015 Permalink | Log in to Reply

        Forget the question. I will create a dedicated mail for wordpress.org so that you do not receive any autoreply from me ever-)

        > Every single email, even the predefined ones, are written and picked and sent by hand. Even the one that goes out to all 22,573 user accounts with commit access to a plugin.

        I appreciate all the good work

      • Ipstenu (Mika Epstein) 4:18 pm on November 19, 2015 Permalink | Log in to Reply

        We do check those actually. There were two emails this cycle that were out of office replies AND came from support or other no-reply formatted emails. Those get us a little confused… We can’t easily tell the difference between a support email address that doesn’t auto reply in that situation.

    • Ahmad Awais 2:44 pm on November 19, 2015 Permalink | Log in to Reply

      +1 for this!

    • rudwolf 6:38 pm on November 19, 2015 Permalink | Log in to Reply

      +1 Absolutely!

    • AnjitVishwakarma 12:41 pm on November 25, 2015 Permalink | Log in to Reply


  • Ipstenu (Mika Epstein) 1:14 am on November 11, 2015 Permalink |
    Tags: repository   

    Tis the Season for Snow 

    Edit: Please read this understanding we LITERALLY mean don’t submit a snow plugin that is 100% the same code as another one. If you have a new way to do it, or a functional change, that’s different. But if it’s a basic ‘this plugin makes snow show on your blog’ and it’s not different from the 21 I listed here, we’re probably going to reject it. We encourage innovation.

    Every year about this time, we get people submitting plugins to make it snow on a website.

    Besides the fact that making it snow can make your site inaccessible to people with visual issues, we actually have a lot of snow plugins.

    No, we have a blizzard of them.

    And unless your brand new ‘snow’ plugin does something in a magically new and different way, we’re not going to accept it.

    We’re all about innovation and creating new ways to solve problems. That’s why we allow so many similar plugins in the first place. There are a hundred ways around design decisions, and we love how people create their solutions. There just aren’t that many ways to make it snow, though, and in the last two years, I haven’t seen a single new ‘snow’ plugin that didn’t do things another one already did.

    If you’re going to submit a snow plugin, please make sure it’s significantly different from the ones we already have. Make sure it does something in a cool way.

    To help you with that, here’s a randomly ordered list of only some of the plugins that make it snow. I picked the top 21. There are more.

    If you want to code this just for your own coding exercise, awesome. But for now, if it’s not terribly different than what we already have, please put it on Github.

    • Archie22is 7:00 am on November 11, 2015 Permalink | Log in to Reply

      #word – I couldn’t have said it better myself

    • Rene Hermenau 10:56 am on November 11, 2015 Permalink | Log in to Reply

      I totally understand this decision from a plugin reviewer standpoint but it leaves a bad taste considering what could happen in future with other plugin requests. “Snow” only delivers 36 plugins which is much less than other plugin categories like “caching” or seo.

      I just hope that such general refusals will still be considered very well in future otherwise we only have jetpack, Yoast and wooCommerce all over;-) Think you get the point.

      • Ipstenu (Mika Epstein) 3:14 pm on November 11, 2015 Permalink | Log in to Reply

        Then make the plugin different. But I promise you that 100% of the submitted plugins for snowing are identical to one of those 21. Identical. The same JS and php.

        The point I’m trying to make is that IDENTICAL plugins aren’t helping the repository, or you. There are a lot of similar plugins, and that’s fine. But I am literally saying don’t be identical.

        Not kidding.

        If someone does it in a new and different way, I will gladly approve it. It’s just been two years since anyone has.

        • ArtissTheGeek 11:48 am on November 12, 2015 Permalink | Log in to Reply

          This is slightly at odds to discussions I’ve had in the past. I’m passionate not so much about this issue but the problem of abandoned plugins. I believe there should be an easy for people like me, who’d love to take over some abandoned plugins, to do so. But when I’ve brought this up with you guys I’ve been told I just need to copy the original and create my own branch. That doesn’t help – you end up with duplicates and I’m unable to easily transfer the user base over.

          So, can I ask again, any chance of putting some thought on how to deal better with abandoned plugins? I’m sure I can’t be the only developer who would love to assist with this.

          • Marcel Pol 4:06 pm on November 12, 2015 Permalink | Log in to Reply


            I am not on the plugin review team, but have some experience.
            There are different scenario’s possible:

            • There is a contact listed in that plugin. You can email the author, and request svn access. Only he can give that, through his admin interface on the plugin page.
            • If the author cannot be reached, you can talk with the plugin team, to see what they can do. They might have a different way to contact. They can (but not must) give you admin access. They might request certain things for that, like an already updated plugin in a zip, to show that you can and will make updates).
            • If the author doesn’t want to give you SVN access, and doesn’t want to give up that plugin. Then you can just fork it under a different name if you want to.
            • There might be more scenario’s, but these are ones I had experienced.
            • Ipstenu (Mika Epstein) 7:28 pm on November 13, 2015 Permalink

              99% accurate :)

              “They can (but not must) give you admin access.”

              That’s where things get messy :) And yes, we do require an updated zip first.

          • Ipstenu (Mika Epstein) 7:28 pm on November 13, 2015 Permalink | Log in to Reply

            It’s off topic and no it’s not at odds with discussions about adoption. You’re not reading this properly.

            If your code is 100% the same as another snow plugin out there, please don’t submit it.

            Seriously. I’m not making an exaggeration. THESE SUBMISSIONS ARE 100% COPIES. If your plugin is a fork that does something notably different (like say it snows based on the strength of the snow in your blog’s physical location), then I’d happily approve it. That’s different.

            Stop thinking this is us trying to stifle innovation or even about preventing similar plugins in the repository. In fact, it’s us attempting to FORCE people to make similar, but different, code. Different.

            I swear to you, the code is 100% the same. In two years I have not seen something new with basic snow plugins.

            Now to answer your question… To be perfectly honest, I’ve talked to hundreds of people about taking over plugins. I do not remember the conversations with you personally. I also don’t see a single email from you to the support email about asking to take over a plugin, so I can only address this anecdotally.

            We _do_ allow takeovers of plugins now. We didn’t because we hadn’t sorted out a proper way of handling it. We did. A couple years ago.

            Right now if there’s an abandoned plugin you want to take over, here’s how it works:

            1) Fork the plugin and update it. Modernize it for 2015 (or whatever). Make sure it’s using good code, is secure, and would otherwise pass a new-plugin-check today.

            2) Email us and say “Hi, I want to take over plugin X (link). Here’s my updated version.”

            3) We will review the new code and, if it would pass muster, contact the original dev.

            At this point it gets messy. If they say ‘no’ that’s the end. If they say ‘yes’ then we hand it over. If they don’t reply, we internally have a longer conversation about what to do. In some cases, we decide not to hand over the plugin based on who the new author is or who the old author is or myriad reasons. It’s a bit of a judgement call.

            Some plugins are too important to hand over to just anyone. Sorry. Other plugins are used by too many people and the upgrade would break. And sometimes the plugin belonged to a beloved member of our community who has passed away, and we’d rather give it to someone closer to them.

            If you have further questions about the details of taking over someone else’s plugin, please email plugins@wordpress.org

    • Lara Littlefield 6:07 pm on November 13, 2015 Permalink | Log in to Reply

      I can’t believe there are a complete top 21 to choose from! Thank you for sharing!!

    • WebberZone 3:43 pm on November 16, 2015 Permalink | Log in to Reply

      Just too much snow plugins in my opinion. Am curious as to other plugins that you’ve noticed that are highly similar!

  • Ipstenu (Mika Epstein) 6:00 am on May 4, 2015 Permalink |
    Tags: repository,   

    Reporting Plugin Issues 

    Note: I’ll be using Hello Dolly as my example ‘bad’ plugin for this post. It’s fine and not (to my knowledge) vulnerable.

    There are a few reasons people report plugins but the main two are as follows:

    • Guideline violations
    • Security vulnerabilities

    If you report a plugin, you can make everyone’s life easier if you do the following:

    Verify that it’s still applicable

    Before you do anything, check if the exploit is on the latest version of the code or not. If it’s not, we may not do anything about it, depending on how popular the plugin is.

    Use a good subject line

    “Plugin Vulnerability” is actually not good at all. “Plugin Vulnerability in Hello Dolly – 0 Day” is great.

    Send it in plain text

    SupportPress is a simple creature. It doesn’t like your fancy fonts and inline images. Attachments are fine, but we cannot read your ‘Replies in-line in red’ so just keep it simple.

    Link to the plugin


    Yes, it’s that easy. Put the URL on it’s own line, no punctuation around it, for maximum compatibility. With over 35k plugins, and a lot with similar names, don’t assume, link.

    If the plugin is not hosted on WordPress.org, I’m sorry, but there’s nothing we can do, so please don’t bother reporting it to us. We have no power there.

    Explain the problem succinctly

    Keep it simple.

    “Hello Dolly has an XSS vulnerability” or “The Author of Hello Dolly is calling people names in the forums” or “Hello Dolly puts a link back to casino sites in your footer.”

    Think of your intro like a tweet. Boil it down to the absolutely basic ‘this is what’s wrong.’

    Keep the details clear

    If someone’s acting up in the forums, link to the forum threads.

    If you know that on line 53, the plugin has a vulnerability (or a link back to that casino site), then you can actually link right to that line: https://plugins.trac.wordpress.org/browser/hello-dolly/tags/1.6/hello.php#L53

    We love that. If you don’t have that line, it’s okay. Tell us exactly what you see. “When I activate the plugin using theme X, I see a link to a casino site by my ‘powered by WordPress’ link.” Perfect. Now we know where to look when we test.

    Show us how to exploit it

    Don’t ask us ‘Can I send you an exploit?’ Just send us all the information. If the exploit’s already up online, like on Secunia, link us to it.

    If you know exactly how to exploit it, tell us with a walk through. If the walkthrough involves a lot of weird code, you may want to consider using a PDF.

    We’re going to take that information and, often, pass it on directly to the developers.

    Tell us if you want them to have your contact info

    We default to not passing it on, out of privacy, so “If the developer needs more help, I can be reached at…” is nice. Even “You can give the developer my information so they can credit me…”

    We’re probably not going to follow up with you

    We love the report, we review them, but we’re not going to loop you back in and tell you everything that’s going on for one very simple reason. We don’t have the time. If you told us to give the dev your contact info, then we did, but we don’t have any way to promise they will, and we don’t have the time to play middle management.

    Emailing us over and over asking for status gets your emails deleted. It’s not personal, it’s seriously a time issue. We’re nothing more than gatekeepers, we are not a security company and we’re not equipped for keeping everyone up to date. We don’t have an administrative assistant to handle that. We work with the developer to fix the issue and we work with the .org team to see if we need to force update the plugin, and that takes a lot of time.

    We don’t do bounties

    This is a little interesting but basically we’re not going to pay you. A lot of people ask for ‘credit’ so they can ‘earn’ a bounty, and that’s cool, but we’re not going to report that for you. Generally if you say you want a bounty, we give your info to the plugin dev, though, so they do know you’re interested.

    How do you report?

    You can report plugins by emailing plugins@wordpress.org

    That’s it :) Thanks!

    • J.D. Grimes 1:09 pm on May 4, 2015 Permalink | Log in to Reply

      Thank you for laying this out for everyone, it’s nice to have things clear. Now if we could just get this into the hands of people who are/should be reporting plugin issues… :-)

      • Chad Butler 3:55 pm on May 4, 2015 Permalink | Log in to Reply

        Awesomely descriptive! Thanks, Mika.

        I want to second J.D.’s comment – how to get this into the hands of the general public who report these things? I’m guessing they don’t follow Make threads.

        • Ipstenu (Mika Epstein) 4:01 pm on May 4, 2015 Permalink | Log in to Reply

          Man, if you guys have an idea I’d love to hear it.

          The idea of ‘Make a button!’ is not a great one since we’d just get a lot of bad reports and spam :/

          • J.D. Grimes 4:09 pm on May 4, 2015 Permalink | Log in to Reply

            What about just a link to this article or similar, “How to report vulnerabilities/violations”? Then people would have to read it to figure out how. But I guess some folks would still just scroll down to get the email address and you’d still get bad reports.

            I’ve been following https://wpvulndb.com/, and I’ve noticed that some of the researches don’t seem to know how to report the vulnerabilities to the plugins team. Maybe the folks at WPScan could help out with educating security researchers by including a note and a link to this article somewhere.

    • M Asif Rahman 4:23 pm on May 4, 2015 Permalink | Log in to Reply

      We already have button to report broken plugins. Maybe add another like “Report a plugin”. the button will lead to this post. And instead of emailing, maybe lets make a mail to form, with captcha.

    • Nile Flores 12:27 am on May 5, 2015 Permalink | Log in to Reply

      I’ll refer to this article, Mika. Thanks for putting this up. My co-mod shared it in All About WordPress on FB. :)

    • ethicalhack3r 9:05 pm on May 13, 2015 Permalink | Log in to Reply

      What incentive is there for any one who volunteers their time to email you about a plugin vulnerability to do so again if you’re not even going to acknowledge their email?

      You need to gamify this process, give them an incentive to do it again. After all, they are taking their own time to email you about the issue which helps protect *your* users.

      I’m sorry but ‘we do not have the time’ is not an excuse. If there is not enough time then not enough resources are being used for this.

      • J.D. Grimes 9:15 pm on May 13, 2015 Permalink | Log in to Reply

        Note that the email will be acknowledged in my experience. While the heading says “We’re probably not going to follow up with you”, it clarifies that to actually mean “we’re not going to loop you back in and tell you everything that’s going on.” However, the response is usually from a can (but not automated).

        • ethicalhack3r 9:22 pm on May 13, 2015 Permalink | Log in to Reply

          Maybe I miss interpreted it. I can confirm that, looking back through my emails, I have only ever not received a reply once.

          • Ipstenu (Mika Epstein) 3:07 pm on May 14, 2015 Permalink | Log in to Reply

            I can promise you we do reply. Always. Even if just to say “Thank you!”

            Normally people get a form email reply, but it’s something a human had to manually do.

          • J.D. Grimes 9:32 pm on May 13, 2015 Permalink | Log in to Reply

            But of course, it isn’t acknowledged in the sense of giving any kind of recognition to reporters, like rep points or a hall of fame mention. Maybe that was more the gist of what you were trying to get across?

            • ethicalhack3r 9:43 pm on May 13, 2015 Permalink

              Yea, that was part of what I was trying to get across. Even just building up a ‘relationship’ with the reporters by following up and saying ‘hey, thanks, we really appreciate the effort’.

              I think a another commenter touched on a submission form type idea. Most people who contact wordpress won’t have read this post. A submission form with all the necessary fields and explaining what wordpress want. I think this would increase the quality of submissions and thus waste less time.

              Full disclosure: I work on wpvulndb.com

              I think a wordpress supported version of what we are doing would improve plugin/theme security. Shine a light on vulnerabilities and credit researchers/reporters. I would be more than happy to work with WordPress in any way we can if they wanted.

      • Ipstenu (Mika Epstein) 3:09 pm on May 14, 2015 Permalink | Log in to Reply

        We ALWAYS reply to the email. Always. Even yours. I see it in our out boxes. Maybe you need to check you spam filter and make sure pluginsATwordpress.org is on the whitelist? Gmail has been particularly daft about it…

        Nope, not gamifying.

        Incentive? What’s my incentive for doing any of this? I’m not compensated by .org :) I do it because it’s the right thing to do for my community. Do it or don’t do it, we can’t make you, but we can suggest how it would best help US if you choose to. And we do greatly appreciate those who do.

    • Cx Rana 4:14 pm on August 13, 2015 Permalink | Log in to Reply

      currently i have 5/6 plugin hosted on wordpress.org
      but i didn’t got plugin developer badge in my profile…. why and how can i fixed it ?

  • Ipstenu (Mika Epstein) 5:04 am on April 21, 2015 Permalink |
    Tags: repository, testing   

    Reminder: Please Test Your Plugins With 4.2 

    WordPress 4.2 is being released this week. Are your plugins ready?

    After testing your plugins and ensuring compatibility, it only takes a few moments to change the readme “Tested up to:” value to 4.2. This information provides peace of mind to users and helps encourage them to update to the latest version.

    For each plugin that is compatible, you don’t need to release a new version — just change the stable version’s readme value.

    In the same vein, please take the time to make sure the people listed as committers on your plugin are only the people who are actively developing the plugin.

    Finally, if the email associated with your wordpress.org plugin author’s account has an auto-reply, please for the love of peanut butter change that or put plugins@wordpress.org on a magic whitelist that doesn’t get the auto-replies. We very rarely send you out important emails, but when we do, they’re related to security or upgrades. When you give us an auto-reply, it delays things and makes our in-box insanely large.

    • Varun Sridharan 5:07 am on April 21, 2015 Permalink | Log in to Reply

      :) Thanks For The Info

    • Pär Thernström 6:25 am on April 21, 2015 Permalink | Log in to Reply

      > In the same vein, please take the time to make sure the people listed as committers on your plugin are only the people who are actively developing the plugin.

      Is that the Contributors-field, or is there any other field that I have missed in my plugins? :)

    • rahul286 7:03 am on April 21, 2015 Permalink | Log in to Reply

      > When you give us an auto-reply, it delays things and makes our in-box insanely large.

      Just wondering if outgoing emails can have reply-to header set to no-reply@wordpress.org or some mail address which is not monitored. It might save plugins@wordpress.org inbox.

    • Rami Yushuvaev 3:38 pm on May 11, 2015 Permalink | Log in to Reply

      make sure the people listed as committers on your plugin are only the people who are actively developing the plugin.

      Actually, this is not correct. If I develop plugins for brands, and I’m the only committer, I can’t remove the brand username, it’s against your policy.

      • Ipstenu (Mika Epstein) 10:44 pm on May 11, 2015 Permalink | Log in to Reply

        Not our “policy,” but that’s a different thing and it’s actually exactly what I mean.

        What Rami’s talking about is that if you make a plugin for a company (say LiveJournal hires me to make a plugin to autopost), then I really should be using a LiveJournal company account to MAKE the plugin because the company owns the trademark, not you.

        So in that example, there might be two committers.

        1) LiveJournal – The plugin owner who is responsible for all things security, guideline, etc.
        2) My Account – The person who is in charge of writing the code.

        And there, Rami, you may be the only person actively developing the plugin, but the owner is someone else.

        What we meant by that statement is that if you quit development for a plugin, you should have your name removed. Otherwise you get all the emails about all the issues, and you may not want them.

  • Ipstenu (Mika Epstein) 7:25 pm on February 27, 2015 Permalink |
    Tags: , ratings, repository, 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?

  • Ipstenu (Mika Epstein) 4:47 pm on February 26, 2015 Permalink |
    Tags: repository,   

    Getting Support Notifications For Your Plugin 

    When you have a plugin, it’s important that you get notified when people have support questions. We have a way for you to keep up to date on these things and have since the Great Plugin Refresh of 2012. But for those of you who missed the news or need a refresher, here we go.

    All Plugins

    We’ve always had a couple convenience views of plugin-committers and plugin-contributors, and these are still there as well. Committers are managed in on the Admin tab (i.e. people who have access to commit code via SVN), while contributors are taken from readme.txt (which is why it’s important for you to use the proper WPORG forum ID, capitalization and all).

    Example URLS:

    Your username is case sensitive. Otto42 will work, otto42 will not. Not sure what yours is? Go to https://wordpress.org/support/profile/ (yes, that works for everyone) and look at the header:

    Example of Otto's profile, his name is capitalized

    The name in the grey header is capitalized, thus he must use a capital_O_dangit.

    Otto fixed this, lowercase works, still, check your login name because I know some of you have weird spaces and stuff

    Since anyone can add you as a plugin contributor, I recommend following plugin-committer.

    The RSS URLs for this look like https://wordpress.org/support/rss/view/plugin-committer/Otto42

    At this time, we don’t have email for this.

    Per Plugin

    Every single plugin allows you to follow it by email. Go to the Support Page for your plugin, scroll down to the bottom, and you’ll see this:

    Example of Email/RSS links

    RSS and email. Done. Even if there are no posts you can register for those emails, so make that a part of your workflow.

    • Lester Chan 4:59 pm on February 26, 2015 Permalink | Log in to Reply

      Thanks for this! It is a #TIL for me!

    • Chad Butler 5:16 pm on February 26, 2015 Permalink | Log in to Reply

      Great insight! Thanks for posting it. I was never aware of the “convenience” views before.

    • danieliser 5:36 pm on February 26, 2015 Permalink | Log in to Reply

      The one thing that is missing and I would desperately love to see is a new view for unresolved issues only. Would make sorting through hundreds of tickets much easier.

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

      You know, if you would email me before writing these things, then I could go in and fix the bugs in them before you finish writing them. 😉

      I’ve just made two important corrections to this code:

      1. It no longer uses your login name. It uses your URL slug (aka “nicename” for those who know what that means). This would be the same as in the URL of your profiles page.

      So, my profiles page is https://profiles.wordpress.org/otto42 . This means that my feed would be https://wordpress.org/support/view/plugin-committer/otto42 .

      2. Because of this, the case-sensitivity is now gone. Or rather, it will redirect you to the lowercase URL instead. No more case-sensitive BS for us, not when we can avoid it.

      The associated RSS feed should also no longer be case sensitive.

    • Paul de Wouters 8:20 am on February 27, 2015 Permalink | Log in to Reply

      We have the RSS feed trigger a Slack notification with Zapier or IFTTT, which is handy.

  • Ipstenu (Mika Epstein) 9:14 pm on January 23, 2015 Permalink |
    Tags: , repository   

    It's Not You – The repo cache is very sticky right now 

    FYI: This should be resolved now

    So you made an update recently and it’s stuck on the old version, but the downloads are right for your new release?

    We know.

    It will update, eventually. We’ve made some recent changes to everything and updates are running a little slower to sync and flush the cache. We’re aware of the delays and kicking the gerbils running the servers to make it faster.

    You should refrain from making multiple updates to ‘fix’ it right now, though. It won’t help.

  • Samuel Wood (Otto) 6:12 pm on June 9, 2012 Permalink |
    Tags: , plugin, readme, repository, 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.

        • 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.

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

          Perfecto, Otto, gracias!

    • 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: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.

          • 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.

    • 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… ?

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