Make WordPress Plugins

Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

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

    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! :))

    • pressbro 8:47 pm on February 11, 2016 Permalink | Log in to Reply

      I just today got my first plugin accepted and the help from @ipstenu was more than I expected. Friendly, to the point and helpful. I honestly didn’t expect anything for a week, but everything happened in a mere day and a half or so, and was mostly behind me fixing the issues in my plugin.

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


      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.


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



    • 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] );

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

  • Samuel Wood (Otto) 8:20 pm on January 23, 2016 Permalink |  


    Same issues that were happening two weeks ago are happening again right now. I have alerted relevant parties to the problem.

    For now, new plugin authors won’t be able to commit, and some plugin readme.txt files won’t get processed correctly until this is corrected.

    Sorry for the inconvenience.

    Edit: This seems to be fixed for the moment, we’re working on preventing future recurrences.

    ETA2: If your plugin is still missing, we know and we’re working on it.

    • Ipstenu (Mika Epstein) 3:40 am on January 24, 2016 Permalink | Log in to Reply

      Please note this means we will not be approving new plugins until it’s fixed. There’s no point if I have to loop back with you all to explain why you can’t access things.

  • 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


          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.

    • FolioVision 12:51 am on February 13, 2016 Permalink | Log in to Reply

      Not sure that a blanket rule on banning tags with competitor plugin names is a good thing, Mika. Especially if the competitor has (had in this case) a near monopoly on a space (thinking of Yoast for example). Or for example Sucuri for instance (we don’t have a horse in that race).

      Could you explain the reasoning, Mika? I’m asking you here so others can see your thoughts on the issue as well.


      PS. There’s a way you could easily fix the twelve tag rule without deleting or delisting plugins: just go and delete any tags after twelve automatically from the database. In this case, abusers will only have their first twelve tags.

      • Ipstenu (Mika Epstein) 1:04 am on February 13, 2016 Permalink | Log in to Reply

        Because a tag should describe what your plugin does, not what someone else’s is named.

        Folgers coffee wouldn’t use the tag ‘sanka’ or ‘nestle’ because those aren’t them. They might use shared terms but they don’t use someone else’s brand because it hurts theirs and they know it. It’s like a smear campaign, it’s bad for everyone, mostly you.

        PS. There’s a way you could easily fix the twelve tag rule without deleting or delisting plugins: just go and delete any tags after twelve automatically from the database. In this case, abusers will only have their first twelve tags.

        Easily no. But we will probably have to switch to how Themes do it and stop letting y’all have a free-for-all with tags.

        • FolioVision 2:30 am on February 13, 2016 Permalink | Log in to Reply

          I’m not sure Mika. I can see your point when a plugin author has 59 tags and they cover every tag possible in an area (including software which shares very little functionality with their own plugin). But if an author stays within her/his 12 tags and considers it important to list a competitor as a tag, that seems to me fair game.

          All those guys like Piet Bos for example working hard on Yoast alternatives should be allowed to use Yoast as a tag and certainly within their descriptions. Otherwise it seems to be you would be giving too big an advantage to the established players and dooming new plugins in a popular sector to just suffocate.

          Have a good weekend.


          PS. Just deleting tags over 12 is about as easy a command as it gets. A couple of lines in MySQL and tag spammers will be sitting at 12 tags just like those of us playing it legal. If you were feeling mischievous you could knock plugins with more than 12 tags down to 5 or even zero tags as a reward for breaking your rules. Heck, send all plugin authors this warning (please not once per plugin but just once per author: authors don’t like email promiscuity any more than you do).

          I know you face an issue with bounces but you could send the warning on a special no-reply address (normally I hate those no-reply addresses but in this case it would serve a purpose).

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



    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.

  • Jen 5:52 pm on January 4, 2016 Permalink |
    Tags: annual survey, contributors   

    2015 Contributor Survey 

    Hi plugin review folks! Thanks for all your hard work and contributions in 2015. Could you contribute few more minutes to fill in the 2015 contributor survey? It will help us establish some baselines around the contributor experience so that we can see how things change over time.

    **This is being posted to all the Make teams, so if you subscribe to a bunch of p2s and keep seeing this post, know that you only need to fill the survey in once, not once per team.**

    The survey is anonymous (so you can be extra honest), all questions are optional (so you can skip any that you don’t want to answer), and we’ll post some aggregate results by the end of January. It took testers 5-10 minutes to complete on average (depends how much you have to say), so I bet you could knock it out right after you read this post! 🙂

    There are two sections of the survey. The first has questions about team involvement, recognition, and event involvement, and is pretty much what you’d expect from an annual survey (which teams did you contribute to, how happy are you as a contributor, etc).

    The second section is about demographics so we can take a stab at assessing how diverse our contributor base is. All questions are optional, but the more information we have the better we can figure out what we need to improve. If there’s some information you’d rather not identify, that’s okay, but please do not provide false information or use the form to make jokes — just skip those questions.

    The survey will be open until January 15, 2016. Whether you have 5 minutes now, or 10 over lunch (or whenever), please take the 2015 contributor survey. Thanks!

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


    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.


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

  • Samuel Wood (Otto) 3:53 pm on December 6, 2015 Permalink |
    Tags: , i18n, language packs, slack, translate.wordpress.org,   

    Plugin Translations for All Plugins 

    We have not mentioned this here yet, but since Matt mentioned it in his State of the Word talk yesterday…

    The WordPress.org plugins directory has the translations import mechanism currently enabled for all plugins. The update will happen for the plugin at the time of the next commit.

    To break down what this means into details:

    • When you commit the plugin, it will get read by the translations system.
    • All the strings for the plugin will be imported into the GlotPress install at https://translate.wordpress.org.
    • The plugin will become available for translators and language packs.
    • A message detailing the import will be posted into the #meta-language-packs channel on Slack.

    That last part has not been widely mentioned, but that is there for debugging and so you can find out what has happened or gone wrong.

    Here is an example of a problem: (I picked this at random, I’m not judging anybody here 🙂 )

    Import of ewz-rating
    ​_Time: Sun, 06 Dec 2015 15:23:20 +0000, Development Log_​
    Code for stable (ewz-rating/tags/1.0.0/) in process...
    This plugin has no text domain declaration in the file header.
    This plugin doesn't use `load_plugin_textdomain()`.
    Code for stable was processed.
    Readme for stable (ewz-rating/tags/1.0.0/) in process...
    The GlotPress projects were created.
    Result of the POT import: 57 new strings added, 0 updated, 0 fuzzied, and 0 obsoleted.
    Readme for stable was processed.

    The problem for this one is simply that the plugin is missing the proper Text Domain header, as well as not having any calls to load the plugin text domain. So, obviously, for this plugin, language packs will not work.

    Here’s one that worked fine:

    Import of docu
    ​_Time: Sun, 06 Dec 2015 13:45:53 +0000, Development Log_​
    Code for stable (docu/tags/1.5/) in process...
    The GlotPress projects were created.
    Result of the POT import: 37 new strings added, 0 updated, 0 fuzzied, and 0 obsoleted.
    Results of the inital translations import:
    Code for stable was processed.
    Readme for stable (docu/tags/1.5/) in process...
    The GlotPress projects were updated.
    Result of the POT import: 26 new strings added, 0 updated, 0 fuzzied, and 0 obsoleted.
    Readme for stable was processed.
    Import of docu
    ​_Time: Sun, 06 Dec 2015 13:46:38 +0000, Development Log_​
    Readme for dev (docu/trunk/) in process...
    The GlotPress projects were updated.
    Result of the POT import: 21 new strings added, 0 updated, 0 fuzzied, and 0 obsoleted.
    Readme for dev was processed.

    This one updated both the trunk and tagged version of the code, so it processed everything successfully. There’s a color coding indicator in the Slack channel as well. Red for a big error of some kind, orange for issues with missing headers or function calls, and green for good-to-go. 🙂

    So, if you’re having trouble with the translations for your plugin, check there for your plugin’s slug. If you have updated recently, then you probably have translation access already and might just be missing a header or something.

    Now, if you don’t want to get everything sent to you about all the plugins on the Slack, then you don’t actually need to join the #meta-language-packs channel. Instead, just add your plugin’s slug to your highlight keywords, and Slack will ping you when your plugin gets mentioned. This will let you see just the info about your plugin and can be a bit easier to manage.

    And again, if you already have translators for your plugin, but they don’t know how to contribute, point them to the Polyglots handbook, and consider asking the polyglots team to make them Translation Editors for your plugin. This will give them access to translate the plugin easily and to approve translations to get out the language packs to your users quickly.

    • Emil Uzelac 5:47 pm on December 6, 2015 Permalink | Log in to Reply


    • Jon (Kenshino) 7:42 pm on December 6, 2015 Permalink | Log in to Reply


    • Rami Yushuvaev 10:02 pm on December 6, 2015 Permalink | Log in to Reply

      We need to create a tutorial for plugin developers with all the common errors and how to avoid them.

    • webaware 10:32 pm on December 6, 2015 Permalink | Log in to Reply

      OK, so what happened to the bit about emailing the plugin author before that happens? I have my own installation of GlotPress through which translators submit their translations, and I received a set just this morning for a plugin… and I see that the plugin has already been imported into the wordpress.org GlotPress.

      If I’d known that the svn commit had already become the trigger for importing into the new world, I’d have also updated all my links for translators and changed my GlotPress installation to reflect that also. Now I have to rush that through for all my plugins somehow while also juggling my real job.

      Uh, thanks for the heads up… 🙁

      • Samuel Wood (Otto) 11:41 am on December 7, 2015 Permalink | Log in to Reply

        If you want to continue to use your own methods, you can do so. If you want to use the language packs, then your existing translations can be imported as well. Just mention something about it in the #meta-i18n channel on slack and we can look into it for you.

        • webaware 2:54 am on December 8, 2015 Permalink | Log in to Reply

          Thanks Otto. I’m happy to move translations across, but was expecting a heads-up as happened with two of my plugins already. I mean, it’s not like I can flag a plugin to *not* get imported into translate.wordpress.org, so really I don’t have a choice anyway (people will submit translations there whether I want them to or not!)

          I’ve hit #meta-i18n, hope to get caught up soon.

    • Brian Hogg 10:42 pm on December 6, 2015 Permalink | Log in to Reply

      How do we actually switch plugins to using the hosted translations vs the local ones? I tried removing the languages/ folder in the latest version as alluded to in the “Plugin Translations on WordPress.org” post in September, but the German translation doesn’t appear to pull through when the plugin is installed or come through in the downloaded zip.

      • Samuel Wood (Otto) 11:42 am on December 7, 2015 Permalink | Log in to Reply

        Once the translations on translate.w.org are at 100%, then you can remove the existing .mo files from your plugin and the language packs will be used instead.

        • pepe 12:08 pm on December 8, 2015 Permalink | Log in to Reply

          Is there a time delay? I got a “language pack ready” message via #meta-language-packs yesterday, so tried deleting the translations locally for the previous release (3.0.2) of wp-Typography (https://wordpress.org/plugins/wp-typography/), but then the German translation would not load. I assumed that maybe the language packs were only shipped with new installs, so I made a new release. However, the translations still do not load and I don’t remember getting a “Translations updated. Click to download.” notice in the backend of my site, either.

    • pepe 10:47 am on December 7, 2015 Permalink | Log in to Reply

      Unfortunately, existing translations don’t seem to have been imported for either of my plugins (https://wordpress.org/plugins/media-credit/ and https://wordpress.org/plugins/wp-typography/). For wp-Typography I assume because the original import happened while the plugin didn’t have translations yet (before I took over), butt for Media Credit it’s a bit strange, because I added translations according to the specs months ago, long before it was imported into GlotPress.

    • sLa NGjI's 12:18 pm on January 1, 2016 Permalink | Log in to Reply


      GlotPress or Translation inclusion, on code of plugins or themes, is contition necessary for approve it (for new plugins or themes) or is not necessary?

      On detail:

      1 – My new plugin or theme – not include translation or GlotPress – rejected from repository
      2 – My previous approved plugin or theme – not include translation or GlotPress – deleted from repository

      Thanks! !!

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