WordPress.org

Make WordPress Plugins

Updates from Ipstenu (Mika Epstein) Toggle Comment Threads | Keyboard Shortcuts

  • Ipstenu (Mika Epstein) 9:30 am on February 3, 2016 Permalink |
    Tags:   

    Plugin Review “Inconsistencies” 

    A few people have complained that they feel the review process is inconsistent. I’d like to take a moment to explain exactly why that happens. The tl;dr is, of course, humans make mistakes. But if you really want to understand what’s going on, read on!

    There is no automated review process

    This is the big thing. Every single plugin is opened and read by a human being. We download the plugin, read it, and try to catch the myriad things that are wrong, insecure, not permitted, etc. And we’re humans. We do our best to scan/grep for things we know are easy to find (like I love checking for wp-(con|load|blog) to see if that’s being called). But a lot of times things are buried or hard to catch.

    This means mistakes are made. We don’t claim to be perfect. We claim to try our best to give you the best review we possibly can for your sake, as well as your users.

    Some replies are canned, the process is not

    I’m sure a lot of you have gotten an email starting with this:

    There are issues with your plugin code. Please read this ENTIRE email, address all listed issues, and reply to this email with your corrected code attached. It is required for you to read and reply to these emails, and failure to do so will result in your plugin being rejected.

    Yes, that’s a canned auto-reply. In order to get through reviews faster, we have replies for the common issues. Right now I have 60 in A-Text. That means there are at least 60 problems with plugins I see every single day.

    This makes us able to keep up with reviews. It’s impersonal, we know, but we try to cite examples from your plugin to help you understand what needs your attention.

    We don’t test your plugin on all environments

    Sometimes we do. But really that’s your job, not ours. We do if we notice things that are weird and we think may be problematic. Some days we test on VVV with PHP 5.6, sometimes it’s HHVM, and sometimes its PHP 5.2. Why? It depends on what we have available just then.

    This means sometimes we catch that you coded something for PHP 5.3 and up and sometimes we don’t.

    Every new version is checked top to bottom

    Think about that for a second, please. If you submit a plugin and we pend it for changes, and you send us the new version, we read the whole thing all over again. Every. Single. Time. We check to make sure you did your changes first, yes, but then we go back and re-read everything to make sure we didn’t miss anything, or you didn’t accidentally add in something new.

    This is why, sometimes, you get an email that starts with “We missed this before…” or “This is also not permitted because…” We’re giving you the best review we can.

    No, we don’t list everything wrong

    It’s not what you’re thinking. Every time we do a review, we list everything we see that’s wrong. We do not list out, for example, every instance of a non-sanitized/validated POST call. We do not list out every single usage of script tags instead of enqueues. We will give you an example, especially if you miss some on your first edit, but we expect you to know how to search your own code.

    This helps you learn how to better vet and review your own code. Also it saves us a little time.

    There are multiple people doing reviews

    Some of us are better at some thing than others. When we find a plugin we don’t feel confident in reviewing on our own, we raise a flag and ask our cohorts to spot-check our work.

    This also lets us hand off troublemakers. Let’s be honest here, folks, we don’t all get along with everyone. When it’s clear we’re at an impasse with someone, we ask each other for help.

    Our goal is protecting users first, then you

    The people we care about the most are the users who can’t code or who don’t understand the severity of things like offloading CSS. You may think it’s trivial and makes your plugin smaller. Someone in another country could find them sued for not disclosing it. Or your plugin may not work because Google is blocked where they are.

    We care about protecting the users from XSS and SQL injections. We care about protecting their information. We care about keeping them safe. But we care about you too! We’re so techy about you documenting ‘This plugin calls service XYZ’ because, yes, the users have a right to know where their data is going, but also because you deserve not to have a slew of angry 1-star reviews that you didn’t tell them.

    This is a tricky road to walk. Some people may get exceptions. Some people may teach us more about code! Some people may be told ‘no’ flat out.

    Guidelines evolve over time (so do security best practices)

    We’re constantly looking over the guidelines and evaluating them for clarity, consistency, supportability, and real-world applicability. Have you read our Detailed Plugin Guidelines lately? You should. Similarly, our security checks have gotten better over time. We used to allow you to call wp-config.php directly. We don’t anymore. The more a specific vulnerability is targeted, the harder we are on your code to ensure you are not the weakest link.

    This is for your protection! We’re doing our best to make sure you don’t get dog-shamed for being the reason sites go down.

    Remember: We are mortal

    I said this to start off this post and I’ll say it again. We, your review team, are human beings.

    We make mistakes. We miss things. We read code incorrectly. We don’t test everything as fully as we should. We screw up. We never miss things out of maliciousness or an intent to blacklist you from the repository. We believe you submit your plugins in good faith, and we respect you enough to treat you as adults and point out what you missed or explain how you can do things better.

    This means you should give us the same benefit of doubt we give you.

     
    • Wolly aka Paolo Valenti 9:37 am on February 3, 2016 Permalink | Log in to Reply

      1) Thanx a lot for your job. ( Now I can tell you since I cannot via email 🙂 )

      2) All my plugins have been reviewed and I received information of security problems, or code error.

      My 2 cents, and thanx again for your job.

    • Sami Keijonen 9:56 am on February 3, 2016 Permalink | Log in to Reply

      Are there any others than Pippin and you making great job at plugins review?

      I was also wondering if plugin review is as intense as theme review. I personally think that’s not possible because there are so many new plugins and updates coming in daily.

      • Pippin Williamson 2:47 pm on February 3, 2016 Permalink | Log in to Reply

        It is primarily Mika and I but there are several others who review a few plugins, primarily when we need an extra set of eyes.

        The plugin review process is much simpler and much less strict than themes. Themes have an inherent minimum that they must provide, but there’s no such thing with plugins. A plugin could be one line or 500,000.

    • IntellyWP 11:42 am on February 3, 2016 Permalink | Log in to Reply

      Hi only want to say… Thank you! 😀
      Your review process is amazing and also the information provided are each time very specific.
      Thank you again, Alex (IntellyWP team).

    • Mayeenul Islam 11:50 am on February 3, 2016 Permalink | Log in to Reply

      First of all, thanks a lot for the awesome job.

      I’ve a suggestion for you, as you mentioned:
      “If you submit a plugin and we pend it for changes, and you send us the new version, we read the whole thing all over again. Every. Single. Time.”

      If a version is managed, and all the diffs are visible it’s easy overseeing all the changes. If the changes are right, then you can check the overall thing.

      • Pippin Williamson 2:49 pm on February 3, 2016 Permalink | Log in to Reply

        Plugins do not existing in WordPress.org’s SVN repo until after they are approved, so we cannot automatically generate a diff of the new version.

        Tip: plugin authors can make the review process faster by including a link to a diff when sending a new version for review.

      • Ipstenu (Mika Epstein) 2:50 pm on February 3, 2016 Permalink | Log in to Reply

        Sure, but re-read why I said we do that.

        We know we miss things. That re-review has cought things multiple times. We’re doing this for your benefit. Make sure we get everything right.

        Plus we have to be sure you changed everything we asked and a diff will only show us what you did do, not if you did everything.

        It’s the same if your plugin is closed for security. You get a top-down review to make sure everything is good, even things we didn’t initially flag.

    • OllieJones 12:19 pm on February 3, 2016 Permalink | Log in to Reply

      “we, your review team, are human beings” — Yes, extraordinarily talented and dedicated human beings. Thanks. It’s your work that makes the plugin repo such a useful global asset.

      A suggestion: You said you have sixty or so “canned” reponses. How about posting them, in rough order of how frequently you send them out? That we we plugin noobz can see the kinds of things your code inspection looks for.

    • Chad Butler 1:14 pm on February 3, 2016 Permalink | Log in to Reply

      Thanks for the time and talent that the plugin review team puts into this.

    • Carolina Nymark 2:36 pm on February 3, 2016 Permalink | Log in to Reply

      <3 I just want to copy this over to theme reviews. I love the idea of (nearly) auto-replies.

    • Andy Fragen 3:00 pm on February 3, 2016 Permalink | Log in to Reply

      Thanks Mika, Pippin, and Otto. I appreciate all you time and expertise, and I know my users do. <3

    • Devio Digital 8:19 pm on February 3, 2016 Permalink | Log in to Reply

      I’ve had a few plugins reviewed now, and besides the two getting refused due to names in the slug which I wasn’t Legal owner of, I’ve had nothing but positive results 🙂

      Even with the rejections, I had kind, personal notes, so I don’t have a bad thing to say about the review process. You guys are doing an awesome job!

    • Mark O'Donnell 10:34 pm on February 3, 2016 Permalink | Log in to Reply

      Thanks Mika (Pippin, Otto, and whoever). You guys do an outstanding job. You are extremely knowledgeable, and very responsive. I say that as someone who has had plugin submissions “dinged” for various issues (generally my carelessness). Every time your review has made my plugins better.

    • jeffmcneill 4:24 am on February 4, 2016 Permalink | Log in to Reply

      Just another thank you for taking care of the important but definitely thankless task by whomever is doing all this great work. While still human, the challenge borders on the superhuman.

    • Guido 10:30 am on February 4, 2016 Permalink | Log in to Reply

      I’m just wondering, if a plugin in repository gets updated with for example a depricated function or other bad coding, is this somehow noticed by the review theme? If not, I suggest a report button.

      • Ipstenu (Mika Epstein) 4:14 pm on February 4, 2016 Permalink | Log in to Reply

        We don’t review every single commit to that granular of a level.

        And we’ve talked about a report button, but … well, report to whom? The review team? If it’s not security related, we’re not going to step in, so just leave a support-post for the author or contact them directly 🙂

    • Robin Cornett 5:07 pm on February 5, 2016 Permalink | Log in to Reply

      Just want to chime in and say that y’all are awesome. I’m thinking plugin reviewing is a monumental task. In my experience, y’all have been incredibly fast, courteous, professional, and helpful. Also, the docs for plugin guidelines, and navigating SVN, have been invaluable. Thank you!!!

    • A WP Life 6:03 pm on February 7, 2016 Permalink | Log in to Reply

      In my opinion @Mika you doing great job for all plugin developers.

    • victordemianenko 7:54 pm on February 9, 2016 Permalink | Log in to Reply

      Thanks for your time and talent, guys! It is thanks to your work, I can say this:
      Have you in frustration or may be in stress?
      Helpful for you will be only WordPress! :))

  • Ipstenu (Mika Epstein) 7:00 pm on January 26, 2016 Permalink |
    Tags: bad code, filters, scan   

    Catching Bad Code Before It Happens 

    It’s not that easy.

    We’ve got more spam/bad code in the plugin repository than anyone would like to see, and while we do manually curate plugin submissions, we don’t actively or even passively patrol all checkins for the bad stuff. We just can’t. We’re human, and with 600-1000 check ins a day, we can’t keep up unless it was a full time job and we were a Nacin-Bot.

    While we have been adding on filters to plugins, to try and curtail the outright bad stuff without needing human intervention, setting up filters and checks that work more than 10% of the time has been a monumental effort. And frankly, 10% just ain’t good enough. We still have to scan the whole repository for bad code on a semi-regular basis, and manually curate the naughty list. The pre-commit tool we have there now checks for base64 and eval and other obvious stuff. It also can check for non-obvious stuff, such as variable function calls (thanks to PHP’s tokenizer). Until we can get up to 80-90% reliability with those checks, there’s no point in them, since the manual work remains intact.

    And this is where you, the merry followers of this blog, come in. You’re smart people. You know what bad code is. You know what hacks look like. You love regex and filters. You scan plugins for the sheer fun of it (or because your work needs you to). We want your help. We want your code.

    How do you do it? What filters do you use, what strings do you look for, and what’s your best trick to catching the bad guys?

    I know you hate bad code as much as we do, and we won’t get to awesome without your help!

     
    • Marko Heijnen 7:12 pm on January 26, 2016 Permalink | Log in to Reply

      At the community summit some of the hosts did talked about checking the quality of a plugin. Mainly focussed if a plugin still works on a certain PHP version. It’s on my plate and I have played around a bit but nothing specific yet. http://php-grinder.com is still a great project to look at but I guess not really the solution for this problem.

      What I do wonder if the things what currently happens can be placed somewhere publicly.

    • J.D. Grimes 8:04 pm on January 26, 2016 Permalink | Log in to Reply

      Before I use a plugin I usually perform a manual review looking for security vulnerabilities. This is a manual review, but for my own code I automate this process during development using WPCS. The reason that I haven’t used WPCS when checking other code is that its security-related sniffs are very strict. The XSS sniff requires all output to be escaped right at the point of output for example—it can’t detect whether the variable was escaped at some previous time. Early sanitization and late escaping are really practices that all developers should follow, but I realize it might not be realistic to expect those to ever become requirements for all plugins in the repo. Short of that, I’ve considered creating more restrictive versions of these sniffs, that will have many false negatives, but very few false positives. So everything that they would flag would have a very high (99% maybe) chance of being a real security vulnerability (XSS, SQLi, etc.). I think I might even have started work on some of these restricted sniffs. If you’re interested I can find the code. I’d be willing to help work on them if you think that this is something worth pursuing.

      The other thing that I would suggest is that you might want to ban the use of the `move_uploaded_file()` function. Usually when that function is used to upload a file in a plugin, it means that the plugin isn’t properly protecting against arbitrary file uploads. You should require that WordPress core’s `wp_handle_upload()` and `wp_handle_sideload()` be used instead, since these will automatically restrict the types of files that can be uploaded to a safe list (though this can be disabled of `$overrides[‘test_type’]` is set to `false`).

    • Varun Sridharan 1:53 am on January 27, 2016 Permalink | Log in to Reply

      Hi, All
      I just created a small php class which creates a welcome page and also fetch the data about this plugin from wp.org. and this welcome page loads only at the plugin activation..

      https://github.com/technofreaky/WordPress_Plugin_Activation_Welcome_Page

      Do you think its a bad code ??
      Need to modify more ?

      Or is there any other code / class available for plugin welcome screen

    • SimonRWaters 9:28 am on January 27, 2016 Permalink | Log in to Reply

      “How do we do it?” – we put all code through sonarqube, insecure dependency checking, various Java specific tools for Java detecting common bugs and measuring coverage, manual code review, and test with BurpSuite Pro and other tools at the security manager’s discretion (that’ll be me). It doesn’t scale, it doesn’t catch everything (nothing will). We are also solving a different problem (except when using 3rd party plugins), we are looking for accidental mistakes, but you also have to look for deliberate spam, and that is a whole lot harder problem.

      Sonarqube is cool, but it isn’t terribly PHP focused, might be a tool to add to the mix if you aren’t already, although they’ve tended just to re-use or re-implement existing PHP scanners. At least contribution to such a tool might find life and utility elsewhere.

      I’ve also made feedback that you accept contributions to SVN without encrypting credentials, this seems a silly to me, just asking for credentials to be abused. My suggestions got the registration emails changed to suggest developers use TLS but I bet most just followed the emailed instructions and still use unencrypted submissions. Do wonder if there are wider security issues that need addressing when I see that sort of thing.

    • psiinon 10:47 am on January 27, 2016 Permalink | Log in to Reply

      You could always use ZAP: https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project for dynamic security testing.
      ZAP can be used both manually and completely automated, eg as part of a CI environment.
      Its also open source and completely free.
      Disclaimer – I’m the ZAP project lead 😉

    • A WP Life 3:31 pm on January 28, 2016 Permalink | Log in to Reply

      Hi Mika,

      600-1000 check ins a day it so big figure to handle.

      But, I am really appreciate your work.

      You doing great job for all plugin authors.

      Thanks
      aWPLife

    • snowboardmommy 9:14 pm on January 29, 2016 Permalink | Log in to Reply

      I wonder if WordFence and/or the other security plugins could be called upon to help?

      It’s in their best interest if spammy / infected stuff just doesn’t end up on anyone’s installation in the first place.

      I know that WordFence scans every plugin and theme on my wordpress installations, every day for me for hacks, infections … it also compares the files in the repository to make sure my local copy isn’t changed / infected. (For a while, it was driving me crazy with one of readme’s from Ban Hammer, actually!!)

      it seems like it should be possible to “reverse” the mirror and scan the repository itself for the same hacks, infections, etc. or, perhaps a “pre-repository” for not-yet-approved plugins.

      Anyway, if you don’t have their contact info, I can find it for you.

      HTH

      ~Bonnie

    • palmermarc 6:54 pm on February 2, 2016 Permalink | Log in to Reply

      In your post, you mentioned not using variable functions. I have some validation functions that work as follows.

      $meta_fields = array(
      ‘field_1’ => ‘sanitize_text_field’,
      ‘field_2’ => ‘sanitize_html’,
      ‘field_3’ => ‘custom_validation_sanitization_function’
      );

      foreach( $meta_fields as $meta_key => $validation_function ) :
      update_post_meta( $post_id, $meta_key, call_user_func( $validation_function, $_POST[$meta_field] );
      endforeach;

      Is this the type of variable functions you’re actively working against? Or would this be considered okay?

  • Ipstenu (Mika Epstein) 6:58 pm on January 20, 2016 Permalink |
    Tags: , tags   

    Reminder: Policy About Tags In Plugin Readmes 

    This is a reminder of current policy.

    We ask that users limit tags in their plugins to no more than 12 (twelve), with some exceptions. Any time your plugin has a high number of tags, you’re seen as trying to game the system.

    How do you fix this?

    1. Remove any ‘common misspellings’ from your tag list
    2. Remove duplicate tags
    3. Don’t use ‘wordpress’ or ‘wp’ in your tags
    4. Don’t use tags that don’t apply
    5. Don’t use your competitors in your tags (if you’re not a woocommerce plugin, don’t list it)
    6. Don’t list everything under the sun related to your plugin
    7. Do use tags that clearly identify what your plugin is

    As much as some people like to think, “tags” are not the same as “search terms” in our system, so including lots of them doesn’t really benefit you much. By adding multiple tags, you reduce the efficacy of searches and tags for everyone and make the experience of looking for a plugin suck. Yeah. You did that to yourself.

    If you’re looking to improve your search rankings, we suggest improving the parts of the readme intended for human beings to read. The short and long descriptions should be clear and useful. Addressing common problems in the “FAQ” section helps too. The entire contents of the readme file is considered for the search, and tags are really only a small part of that. Removing irrelevant pieces such as lists of languages (like links) or feature bullet points may help a lot as well, to reduce the overall length and to help eliminate irrelevant information about the plugin.

    Make the readme for people, not for machines, and it will help you rank higher in the search results. People actually search for solutions to their problems, not simply for keywords.

     
    • ArtissTheGeek 7:36 pm on January 20, 2016 Permalink | Log in to Reply

      Thanks for this Mika. Can you explain what purpose the tags have then, if the README in its entirety is used for search?

    • George Notaras 7:43 pm on January 20, 2016 Permalink | Log in to Reply

      Hi Mika,

      Thanks for this insight!

      Taking the whole readme into consideration is a good idea, but I think that there might be a little problem with plugins which list functionality of their pro versions inside the readme. This functionality is not part of the plugin that is provided through wordpress org, so this could lead into some search results being a little misleading.

      Also, although I don’t consider it a big problem, at some point it might be a good idea to add some guidelines about the plugin slugs and titles. Sometimes they are ridiculously long, other times the titles are totally different than the slug. Not a big deal, but these are points of possible abuse, so it might be a good idea to take these into consideration for future reevaluation of the guidelines.

      • Ipstenu (Mika Epstein) 5:53 am on January 22, 2016 Permalink | Log in to Reply

        Eh, that’s up selling which is difficult to do.

        Right now we let it go because we permit up sells. I would leave it out of the tags and put it in the content of the read me, though.

        • George Notaras 10:43 am on January 22, 2016 Permalink | Log in to Reply

          > Right now we let it go because we permit up sells. I would leave it out of the tags and put it in the content of the read me, though.

          Hmm, that’s fair enough, but still leaves room for some exploitation in the readme. Maybe there could be a special HTML comment (or a non standard HTML tag) in the future which should be used to enclose the part of the readme that is about the pro functionality and which would not be taken into account by the search algorithm. Just an idea.. I’m sure you’ll figure something out if you notice abuse. Keep up the good work!!

          • Ipstenu (Mika Epstein) 4:24 pm on January 22, 2016 Permalink | Log in to Reply

            Honestly the terrible 1-star reviews they get from doing that hurts them more than anything else. Here’s what happens.

            Developers put in all the features, pro and free, in the readme.

            User googles and finds plugin. Installs only to see the pro is missing. Leaves 1-star review about how the plugin is not as advertisted.

            Developer replies in a snit that it’s clearly stated this is in the pro version.

            User tells developer off.

            Moderators step in, close the post, and leave it for posterity.

            Plugin subsequently gets low marks across the board for how the developer handled an upset user.

            • George Notaras 12:30 am on January 23, 2016 Permalink

              Such things happen around here? Amazing! :p

              PS: Good point!

    • Reedyseth 7:51 pm on January 20, 2016 Permalink | Log in to Reply

      Thank you @Mika for the reminder. I will try to keep track of this and fix if need it.

    • JasWSInc 11:42 pm on January 20, 2016 Permalink | Log in to Reply

      Great suggestions Mika. Thank you for the reminder.

    • Rene Hermenau 9:46 am on January 21, 2016 Permalink | Log in to Reply

      A good step forward to make the plugin rep more structured.

      @ArtissTheGeek The tags are helpful for finding all plugins which are specialized and dedicated for a specific purpose. If everyone will stop ‘spamming’ the rep and will use only the plugin’s main capabilities as keywords we get a much better plugin search experience.

      • ArtissTheGeek 10:17 am on January 21, 2016 Permalink | Log in to Reply

        I don’t disagree Rene, just trying to understand exactly how the tags are used. Even Jetpack breaks some of Mike’s suggested rules, so there obviously isn’t the clarity around this subject that there should be.

        • George Stephanis 2:48 pm on January 21, 2016 Permalink | Log in to Reply

          We do?

          Jetpack’s current tags list looks like this:


          Tags: WordPress.com, jet pack, comments, contact, gallery, performance, sharing, security, shortcodes, stats, subscriptions, widgets

          https://github.com/Automattic/jetpack/blob/master/readme.txt#L3

          The only thing I can surmise you mean is that we list `jet pack` as a tag. But then, you said ‘some’ not ‘one of’ — so what exactly are you thinking we’re violating?

        • George Stephanis 2:54 pm on January 21, 2016 Permalink | Log in to Reply

          Besides, it actually looks like her “suggestions” are phrased as more “ways to pare down your list to about a dozen if you have way too many” — not strict rules. The main rule was not to have too many tags.

          • Ipstenu (Mika Epstein) 5:52 am on January 22, 2016 Permalink | Log in to Reply

            Common misspelling of ‘jet pack’ is understable here, and would be allowed anyway. Now if there was JetPack, jetpack, and Jerkpack, we’d have words, George 🙂

    • A WP Life 5:23 pm on January 21, 2016 Permalink | Log in to Reply

      We will do. Thanks @Mika.

  • Ipstenu (Mika Epstein) 8:57 am on January 12, 2016 Permalink |
    Tags: , ,   

    2015 Community Summit And How You Can Help the Plugin Team 

    Sadly, many of the same reasons we could not add new members to the Plugin Team last year are still an issue (see 2014 Community Summit Wrapup). The codebase has been improved, but the process is slow. Just to give you some hope, the work done on the Theme Repo is being used to help us. So. Soon. Soon. We’re restructuring the backend to make it more clear as to who can do what, but most things are waiting on the re-vamp.

    The only real ‘news’ is that we’ve been sneakily moving our documentation over to https://developer.wordpress.org/plugins/wordpress-org/ – Please check it out to keep up with all the information about what makes good plugins in the repo. Oh, and we’ve swapped reps. I’ll be taking over as the plugin team rep and that really changes… nothing at all. @boone did a great job and I thank him for it.

    You Can Help

    While we are still stuck on the old system, you can jump in and help us by emailing plugins@wordpress.org when you find people playing fast and loose with the rules.

    We encourage and welcome updates from everyone, but please don’t be snippy. Be serious. If someone has powered by links, or is phoning home, yes, please let us know. But don’t let your personal feelings get in the way. This is a big deal. A lot of people send us reports from a place of anger. Don’t be that person. That person makes it harder for us to figure out if someone has a personal vendetta against a plugin and/or developer, or a legit concern. We’re all passionate, but remember to channel that passion into something beneficial.

    How to Report Issues

    If you’ve found a plugin _doing_it_wrong(), email plugins@wordpress.org and remember:

    1. Make your subject clear. (“XSS Vulnerability in Hello Derpy” or “Derpack Developer swearing at users in forums” are good)
    2. Always provide an exact link to the plugin.
    3. Report plugins with guideline violations.
    4. Report developers who are behaving badly.
    5. Be detailed. If you know what file and line of code is the problem, tell us.
    6. Provide examples of vulnerabilities. If you already know what’s hackable, show us. It makes it faster for us to verify and reproduce. Link to forum threads etc etc.

    Remember: We don’t retroactively enforce guideline changes unless there is a legal, copyright, or security related reason. For example, we no longer allow new plugins to call wp-load.php directly, however we don’t hunt around for plugins that do so. If a plugin is closed for using a non-GPL library and, in the review, we note other best-practices violations, we will require them all to be fixed before reopening.

    Also, we won’t be following up with you as to what happened most of the time. We’d love to. We can’t and keep up with emails. Please don’t take it personally. As we add more people to the team we may be able to change that, but right now it takes us away from validating security issues.

     

    Tools

    Rami asked “What do you guys even use to check plugins and look for bad things?” and the real answer is “Our eyes.” We don’t have a theme-check type plugin because there are very few ‘standard’ things to look for (possibly it could check for license issues, including jquery files, and calling wp-load directly sort of things).

    Remember: Thou Art Mortal

    And so are we.

    We’re people too. We make mistakes. We miss things. We have bad days. We get sick. We have families. If we don’t reply to you super fast, please sit on your hands and give us five days. Five. You should get some sort of reply from us within five, even if it’s ‘we’re still talking about this, sorry but it’ll take a while.’ Sending us an enough every 12 hours (yes, someone did that) is annoying.

    Hunting us down on Twitter and Slack because we didn’t reply right away is similarly uncool and harassing. We use the email so that everyone on the team can read the conversations. Don’t take it off-line. Keep it in the email and that way, if you’re talking to Otto and he goes to a BBQ fest for two weeks days without access, Pippin can pick up the conversation and help you out.

    Just be patient and calm. Especially if we’ve just closed your plugin. We know that sucks, and we totally get you’re angry sometimes. Just try to remember we’re all humans and treat us with respect like fellow humans.

    Grumpy Otto (is there another kind?) looking at the camera.

    Take the plugin. Leave the cannoli.

     
  • Ipstenu (Mika Epstein) 4:31 pm on January 11, 2016 Permalink |  

    [RESOLVED] Jan 11 – Issues committing to SVN 

    0100 UTC

    This problem should be fixed now. Let us know if you have any continuing issues. -Otto

    2339 UTC

    We’ve ruled out a couple things. The access table seems okay. But right now we don’t have an ETA 🙁 I’m sorry.

    2141 UTC

    Just an update to let you know we’re still looking into it. You don’t need to tell us your plugin names. Pretty much everyone who was approved this weekend and on has this issue.

    1631 UTC

    We’re aware of this and looking into it. Please keep an eye on this post. We will update as soon as we have any information.

     
  • Ipstenu (Mika Epstein) 12:35 pm on January 4, 2016 Permalink |
    Tags: , , ,   

    Reminder: Your Email Account Must Be Valid 

    Since the only way we have to get in touch with plugin authors is their emails, we’re going to be enforcing that you have a valid email that goes to a human being for you plugins.

    This simple statement covers a multitude of situations but to clarify, we’re talking about the email associated with the user accounts that have commit access to your plugins.

    Go to https://wordpress.org/plugins/YOUR-PLUGIN/admin/ and look at the people listed under Committers. Those accounts are who we email when there’s an issue with a plugin, or when we’re alerting you to new WordPress updates. Those emails must go to real human beings. It can be a shared email box (goodness knows plugins is a shared email box) but real people have to read those emails because without that, we cannot communicate with you.

    We strongly suggest you whitelist plugins@wordpress.org

    The following email situations may result in your plugin being closed if we can’t find a way to communicate with you:

    Invalid Emails

    If your email bounces, your plugin gets closed. We can only assume that a dead email means you’re done with things, and since we have no way to contact you, your plugin can only be considered unsupportable. If you notice your plugin is closed and you didn’t get an email from us, check your account’s email. If that’s not right, that’s probably why.

    Auto-Replies

    If your email has an auto-reply, such as the sort that goes to a support ticket generator, stop it. This makes it nigh impossible for us to communicate with you, we can never tell if a human has read the email, and we get a mail box filled with auto-replies which means you’re the reason plugin reviews are backlogged. We will normally email you one sternly worded warning about this. If it keeps up, your plugin may be closed.

    2-Step Verification

    If your email auto-replies and asks people to click or reply in a special way to ensure our email gets to you, guess what? Half the time that doesn’t work. We often get expired tokens because it takes us more than 24 hours to get through all the emails in our queue, and once that happens we have no way to get our email to you.

    Deceased Authors

    This is a touchy subject so I apologize in advance. If a plugin author has died and we can verify this, we remove their account’s access to their plugins (and usually reset their passwords to something random). This is in the interest of security, as doing so will prevent any possible issues if their account is hacked. We do not close the plugins. If there are co-committers, they will be notified. Otherwise the plugin will simply remain in place. Taking over those plugins is a similarly touchy subject, and priority will be given to their coworkers or close friends/family who are also WordPress developers.

     
  • Ipstenu (Mika Epstein) 11:38 am on December 14, 2015 Permalink |
    Tags: ,   

    Sock Puppetry Is Not Welcome 

    When a single users makes multiple accounts with the sole intention of leaving reviews on their own plugins (or leaving poor reviews on their competitors), this is called being a “Sock Puppet” – https://en.wikipedia.org/wiki/Sockpuppet_(Internet)

    This behavior is expressly NOT welcome on the WordPress Forums as it is spamming, and it can result is us removing all your plugins from our repository for abuse.

    That’s from an email we send out when we catch you (or your plugin team) making multiple accounts.

    There’s a fine line between making multiple accounts for a team and making fake accounts that leave comments and reviews on your plugin, which you (or someone else on the team) then interacts with.

    It’s disreputable, it’s an abuse of our good faith in you, it’s spamming, and it’s wasting the time of forum volunteers.

    It’s also not permitted.

    We’ve shut down many plugins because the authors engage in unwelcome behavior. Please don’t make us shut down yours. Don’t leave reviews on your own plugins, don’t make fake support posts, don’t spam. It doesn’t make your plugin look good and it will result in your plugins being pulled.

     
    • David Anderson 11:47 am on December 14, 2015 Permalink | Log in to Reply

      It’s unfortunate that this even needs saying…. probably, a high proportion of sock-puppets already know it’s wrong, and it won’t deter them.

      I have a positive suggestion. How about some sort of badge or visual indication for verified identities, rather than aliases? That’d need a system for verifying identities, of course. Perhaps the review or search system could give bonus points to people who use them. That would allow people to still use anonymous identifies, but give an appropriate ‘reward’ to those who are willing to say exactly who they are.

      It’s amazing how many plugin authors want use to use their plugins, but hide behind meaningless invented-10-minutes-ago brand-names, hosted on domains with domain privacy, etc. Expert users can research that, but a lot of WP users would never get as far as a WHOIS lookup, or something like that. If we want people to use our plugins, we need a really good reason to not be willing to say exactly who we are. But currently, there’s little incentive for this – it’s left to users to work out for themselves.

    • Gustavo Bordoni 11:55 am on December 14, 2015 Permalink | Log in to Reply

      As a plugin contributor can I leave a review? On my main account? Just to avoid possible problems 😉

      • Ryan Hellyer 1:15 pm on December 14, 2015 Permalink | Log in to Reply

        Yes. Or at least it was for a long time. I haven’t seen any rule change regarding this. To make it clear, I always mention that I am the plugin developer when leaving a review. I think it’s a little dishonest to review your own plugin and not bother to tell people that you have a biased view point on it.

        Personally, I only use reviews on plugins of my own which I actually use (I make some plugins purely for others, and not myself).

      • Jon (Kenshino) 2:16 pm on December 14, 2015 Permalink | Log in to Reply

        Everyone is free to leave one review for each plugin as far as we’re concerned,

        Actual plugin authors can rate their own plugins 5 stars (once). Although we don’t understand why 🙂

        • Ryan Hellyer 2:50 pm on December 14, 2015 Permalink | Log in to Reply

          I’ve actually given bad ratings on my own plugins before, once they became out of date and not worth using any longer.

        • David Anderson 3:24 pm on December 14, 2015 Permalink | Log in to Reply

          The default for a new plugin in the wordpress.org repo is to be shown with zero stars. A lot of people browsing the repo will just assume this means that the plugin is rubbish. So, most plugin authors self-review (hopefully, clearly explaining why), so that that doesn’t happen.

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

        Sure but we think you’re weird.

        It’s YOUR plugin. We sort of hope you like it. And if most of your reviews are from your contributors, that’s just odd and will probably make us look at the other accounts.

        It’s all intent. If you’re trying to pad your reviews to make it look more popular, then that is a bad intent. Does that make sense?

        • David Anderson 3:25 pm on December 14, 2015 Permalink | Log in to Reply

          I always self-review (and clearly explain why I’m doing it), because the repo’s default is to show 0 stars next to the plugin, until someone reviews. Sure, lots of insiders know that “0 stars” means no review, but it’s not universal knowledge.

    • Jon (Kenshino) 2:15 pm on December 14, 2015 Permalink | Log in to Reply

      On behalf of the Support Team that manages the forums, we catch sock puppets usually almost as soon as they post something……….. it takes up a lot of time from the sock puppeteers and us and no one is gonna benefit since it’s gonna get caught.

      We have various tools that catch it…….. so you know, be honest, write good plugins and don’t game the system.

      Cheers!

    • Andrew 2:20 pm on December 14, 2015 Permalink | Log in to Reply

      > There’s a fine line between making multiple accounts for a team
      For this situation, please can those plugin authors make more effort to identify who is a contributor. If you don’t properly identify them then moderators may not be able to tell the difference from a sock puppet account.

    • Max Foundry 5:39 pm on December 15, 2015 Permalink | Log in to Reply

      Pretty sure that the 10 5 stars you sock puppet your way to isn’t going to really get you launched very far. It’s crappy behavior for sure.

  • Ipstenu (Mika Epstein) 8:20 am on November 23, 2015 Permalink |
    Tags: ,   

    Your Plugin Committers Should be Your Developers 

    After we started pushing back on the auto-reply stuff, a couple plugin devs said that they used their support accounts (like support@example.com) as their committer so that they could get email updates from the forums.

    This is a terrible idea. It’s insecure and rather dangerous.

    That means the support account is the one with write access to your plugin. And that means anyone with access to your group email (or your support tool) can click on reset password, get the password, change it, and blow up your plugin. Obviously that’s a major security issue. The only people who should have write access to your plugin should be people who know how to code and are responsible and reliable and trustworthy. And remember, people can go nutters in a company of any size and seek out revenge in weird ways. Limiting the damage they can do is your responsibility.

    This also means that when we send you an email about your plugin, you may be accidentally sharing privileged information with people who have no business knowing these things. With a support account for a company of four people, it may be okay for everyone to know your plugin was pulled from the repository for a security hole. When you have a company of 300 and you use a system like ZenDesk (not to pick on them, but they are popular), now everyone knows. This may not seem like a big deal, but if one person tweets “OMG! Plugin FOO has a security hole!” then there’s a major risk that you’ve opened up the floodgates of potential hacks. Limiting the risks you put on your users is important.

    Only allow your developer account(s) to have commit access to your plugin.

    If you want one joint email-alias (wp-plugin-dev@example.com) that forwards to everyone, that’s okay, but not great. Remember, if everyone has their OWN user account, then you can easily track who pushed what change to a system. If you’re only using SVN as your version control, it’s a good idea to make sure you know who did what. If you’re using Git or Mercurial or your own SVN to track the changes, then make sure that only responsible, reliable, people have access to that dev account. Again, remember that we’re talking about access to push code to (say) a million users.

    Remember: Anyone listed as a developer has the ability to remove anyone else as a committer. So you really want to limit those users.

    Make a separate account to handle support

    Make a separate account (wp-plugin-support@example.com) that does whatever it needs to do. Then you can sign up for email alerts. Go to https://wordpress.org/support/plugin/YOUR-PLUGIN and scroll to the bottom where it says “Subscribe to Emails for this Plugin”:

    Click "Subscribe to Emails for this Plugin" when logged in.

    Click “Subscribe to Emails for this Plugin” when logged in.

    Click the link and baboom, that account gets email alerts. You can do the same for reviews at https://wordpress.org/support/view/plugin-reviews/YOUR-PLUGIN if you want to catch the inevitable ‘this review should have been a support post’ threads.

    Remember: If you sign a support account up for getting those emails, you should still disable auto-replies. Otherwise you’ll be generating a lot of unnecessary email every time someone replies to your threads and you may get caught as a spammer.

    Add your support accounts as Contributors

    Contributors are the people you list under the ‘Authors’ field on your readme. They do not have any commit access to a plugin. They can’t edit the code.

    Example: “Automattic” has an account for Jetpack. That account can be a placeholder account. It can be a support account if you want to use it in the forums. It can be marked as a Contributor in the plugin’s readme.txt in order to get special markings in the forums for replies from that account for that plugin.

    The other accounts should be individual accounts, belonging to the devs, and preferably using their company email addresses. This way, if the organization changes, an individual leaves, etc, the email address still goes to the company and the plugin can be recovered, if necessary.

    Back on Jetpack, there are over 70 people listed as ‘authors.’ They all get that happy plugin author green lozenge in their forum replies and they can officially help people without you worrying they’ll miss a semi-colon and take down 20 thousand users with a bad push of code.

    Remember: Anyone listed as an author is going to get that green lozenge. If you don’t want people representing you, credit them in the readme but remove them as an author.

     
  • Ipstenu (Mika Epstein) 10:33 am on November 19, 2015 Permalink |
    Tags: , libraries, timthumb   

    TimThumb EOL 

    If you’re using (or thinking of using) TimThumb in the repository, please read.

    TimThumb has reached it’s end of life. As such, we strongly recommend you stop using it in your plugins as soon as possible. It’s not supported, it’s not maintained, and that means the 130ish of you who have it are going to have a bad day if another exploit is found because we will close your plugins.

    Please note, we’re not retroactively banning it from the repository at this time, though that may change. Right now, we’re asking everyone to take the first step and find an alternative. All new plugins are being required to use something else.

    In general, please keep an eye on your third party libraries. If they’re no longer supported, look for a replacement. If they’re out of date, update your plugins. This is the best way to keep your code secure and avoid those awful emails about how we closed your plugin.

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

    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.

    THIS IS A GLOBAL REMINDER

    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

      (y)

    • 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

      +1

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

      +1

    • 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

      +1

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar