WordPress.org

Make WordPress Plugins

Welcome to the official blog for the WordPress Plugin Review team.

If you have a problem with your hosted plugin, or have found an issue with a plugin hosted here, please read our post on reporting plugin issues first.

We do not provide help with using, debugging, or developing plugins. We act as gate-keepers and fresh eyes on newly submitted plugins, as well as reviewing any reported security or guideline violations.

For documentation on creating a plugin, as well as all guidelines and support information, please visit developer.wordpress.org/plugins/

 

Currently we have neither meetings nor office hours.

We can be reached by email at plugins AT wordpress.org, or you can join us in the #pluginreview channel on Slack.

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Ipstenu (Mika Epstein) 5:52 am on July 29, 2016 Permalink |
    Tags: , ,   

    Status on the Plugin Repo Revamp, Guidelines, and Handbooks 

    First off, please read Obenland’s post on the repo:

    Plugin Directory v3: Next Steps

    Obviously we have a long way to go.

    As for the Guidelines, I wanted to be done and ready to release them to everyone before 4.6 dropped, but I’ve been using small focus groups at WordCamps first. This resulted in a lot of small changes that I want to take the time to go over with the Plugin Team before I unleash it to the world for nitpicking. A huge amount of thanks goes to @courtneydawn @logankipp and @lunacodes for being my first run of editors!

    As we clean up the aftermath of the 4.6 emails (you have no idea…), I’ll be pinging people whom I know to be good copyeditors and have mentioned wanting to help before. If you think that’s you, please leave a comment here. I won’t be asking everyone as I’ve found that to be overwhelming for me to be able to process, so please don’t take it personally. Once I have it mostly good, I’ll flip it from Google Docs to a Git Repo and people can pull request!

    Also a handbook! Oh me oh my I’ve been writing one! And I’m almost ready to ask Sam to flip the switch for it. It’s sparse and will need lots of attention too.

    Thank you everyone for understanding the crazy that goes on with all this, and for being patient. It’s been a long 7 months for me working on all this.

     
  • Ipstenu (Mika Epstein) 6:02 pm on July 28, 2016 Permalink |
    Tags: , , updates   

    Reminder: WordPress 4.6 is imminent. Are your plugins ready? (also make sure your email is valid) 

    The email went out last night to everyone with commit access to a plugin.

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

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

    Looking to get more familiar with 4.6? Read this roundup post on the core development blog to check out the changes made to register_meta(), native fonts, persistent comment cache, Customizer APIs, WP_HTTP API, and much, much more: https://make.wordpress.org/core/2016/07/26/wordpress-4-6-field-guide/

    Thank you for all you do for the WordPress community, and we hope you enjoy 4.6 as much as we do.

    Also, as we’ve been warning for the last two cycles, some plugins have been closed. It’s a requirement that we be able to contact you. We’ve also been pushing back on auto-replies, since they make it impossible for us to tell if there’s a human reading. Frankly, based on the content of the auto-replies, this is the cycle we see:

    We email you and receive an auto reply of “A support ticket has been created…” We email a warning “Hey, please remove us from this auto reply…” and we get another auto reply. We don’t reply to that one, but 3 months later when we send another email, the cycle starts anew. This tells us that you are not actually reading your support emails. Which means we have no way to contact you (and your users probably hate you, just FYI). So this time, plugins have been closed.

    Your plugin has been closed (or you were removed from a plugin) based on the following criteria:

    • If you have auto-replied to our ‘Are your plugin ready?’ email 4+ times, and your plugin has not been updated in 2+ years
    • If your email bounced
    • If your auto-reply says “I’m on vacation until…” and it’s a invalid future date (example: someone’s out of office said they’d be back August 2014…)
    • If your auto-reply said you no longer work at a company
    • If your auto-reply says the company no longer exists

    If the only valid emails for the plugin meet those criteria, the plugin was closed. If it was only one committer, they were removed and everyone else was emailed and notified.

    In all cases we absolutely emailed each and every one of you. I did it myself. I directly contacted over 80 plugins about this situation and expressly told them if their plugins were closed or if people were removed, and why.

    If you find your plugin was closed and you didn’t get an email, check spam, because they were all sent. Even to people who auto-replied. Which was really annoying.

     
    • Drew Jaynes 7:09 pm on July 28, 2016 Permalink | Log in to Reply

      Thanks Mika!

    • Gregory Karpinsky (@tivnet) 9:57 pm on July 28, 2016 Permalink | Log in to Reply

      @Ipstenu Mika,

      What exactly wrong with “A support ticket has been created…” ? If I am using a helpdesk for all my business correspondence, there will be an auto-reply.

      Should we have a separate email for WP-org profile?

      Thanks

      • Ipstenu (Mika Epstein) 10:15 pm on July 28, 2016 Permalink | Log in to Reply

        You don’t need a separate email. Most people are clever and just add in a filter “Don’t auto reply to this email address…”

        If you’re unable to whitelist our email, then yes, make a new account for your development. Have that go to a shared email for all we care, but we just don’t want to read your auto replies.

        We need to be able to communicate directly with plugin authors, and having automated responses don’t help us much. 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.

        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.

      • Samuel Wood (Otto) 1:04 am on July 29, 2016 Permalink | Log in to Reply

        I’m going to disagree with ipstenu on this one. Use a separate email. One that goes directly to you.

        If you want to get complicated about it and use the same email with rules and such, fine. But using your real email is so much simpler.

        The important thing is that when we email you about a problem with your plugin, it needs to go directly to your eyeballs, fast. However you do that is fine. But stop any and all auto replies to *@wordpress.org, plz… K thx. 🙂

  • Ipstenu (Mika Epstein) 11:12 pm on July 20, 2016 Permalink |
    Tags: alert,   

    Security Alert: Httpoxy 

    You may have heard about this already. Even so, please read this post. Normally we email all possibly impacted developers directly. In this case, trying to generate a list gave me over 6 gigs of results. I trimmed it down, but given the volume of people using Guzzle and possibly using suspect code, it was more straightforward to post an alert.

    httpoxy is a set of vulnerabilities that affect application code running in CGI, or CGI-like environments. It comes down to a simple namespace conflict:

    • RFC 3875 (CGI) puts the HTTP Proxy header from a request into the environment variables as HTTP_PROXY
    • HTTP_PROXY is a popular environment variable used to configure an outgoing proxy

    This leads to a remotely exploitable vulnerability.

    You can read about the entire situation on httpoxy.org. While the fix is, as most are, a server one, all developers should be aware of this.

    Don’t bother doing the following:

    • Using unset($_SERVER['HTTP_PROXY']) – it does not affect the value returned from getenv(), so is not an effective mitigation
    • Using putenv('HTTP_PROXY=') – it does not work either (to be precise: it only works if that value is coming from an actual environment variable rather than a header – so, it cannot be used for mitigation)

    You can prevent and mitigate some of this in your code. Read up on httpoxy Prevention.

     
    • Jeff Chandler 1:15 am on July 21, 2016 Permalink | Log in to Reply

      How big of a concern is this for the typical end user?

      • Ipstenu (Mika Epstein) 5:48 pm on July 22, 2016 Permalink | Log in to Reply

        In the vein of “I am not a lawyer” I preface this with “I am not a server side security expert.” Anywhere from not at all to huge, depending entirely on what you’re doing with your WordPress site. The TYPICAL end user? Pretty low I think. I’d still ping my host and ask if they’re aware and what measures are they taking to protect me 🙂 That’s what I did. Mine blocked PROXY via ModSec and apache.

        Of course if you’re on HTTPS for internal requests, no worries.

  • Samuel Wood (Otto) 9:36 pm on July 14, 2016 Permalink |  

    Known issues with pre-commit to the plugins SVN 

    Have you seen this recently?


    $ svn ci -m 'commit first version of plugin'
    Adding trunk/readme.txt
    Adding trunk/my-cool-plugin.php
    Transmitting file data .......svn: E165001: Commit failed (details follow):
    svn: E165001: Commit blocked by pre-commit hook (exit code 1) with output:

    ***********************************
    PHP error in: my-cool-plugin/my-cool-plugin.php:
    Errors parsing my-cool-plugin/my-cool-plugin.php
    ***********************************

    A couple weeks ago, the PHP “lint” part of the SVN pre-commit check was changed from using PHP 5.4 to using PHP 7.0. Somewhere in that process, something got broken with regards to the output of the error messages resulting from this check. So, none of the errors show up.

    This can be confusing, especially if you’re not running PHP 7.0 yet, because PHP 7 is actually a lot more strict about this sort of thing. You can run the PHP lint process yourself on your own files all day long and not see what the issue is, because it *only* comes up in PHP 7.

    My advice: Grab a copy of PHP 7 for your machine, and run “php -l” on the file you’re getting an error message about. There is a valid error, you’re just not seeing it on older PHP versions, which were not quite so picky.

    One known case that seems to be cropping up a lot:

    The “break” and “continue” keywords are only valid inside a for, foreach, while, do-while, or switch structure. You’ll get the error message of “Fatal error: ‘break’ not in the ‘loop’ or ‘switch’ context in my-cool-plugin.php on line 123”

    We’ve been seeing code that has something like this in it:

    if ( is_thing() ) {
      do_thing();
      break;
    }
    

    And that is invalid in PHP unless that if is inside a loop. But, previous versions of PHP didn’t show the problem in their lint processes. Not so with PHP 7.

    So, make sure to check your code with PHP 7. It’s no fun for people using the newest systems, like we always recommend, to be running into syntax errors. Note that these were actually syntax errors in previous versions of PHP as well (using break and continue makes no sense outside of a loop structure), but now you’re getting told about them by the lint process.

    We’re still working on finding the bug not showing you these errors in the pre-commit checks too. 🙂

    Edit: Any plugins uploaded to the directory should still be PHP 5.2 compatible. Just because we’re allowing PHP 7 code doesn’t mean this is a free-for-all.

    Look at https://wordpress.org/about/stats/ . This isn’t complicated. Your main plugin file can be installed and activated on any of those sites. If you have even 5.3-only code in that main file, then you are responsible for breaking that person’s website, and *you* will get the appropriate review from them for doing so. And we are not going to delete that review just because you ask nicely…

    Make your plugin handle failure cases properly. If you want to limit your userbase, then you’re welcome to do so. But do it right. Add code to the plugin to fail gracefully on older systems.

     
  • Ipstenu (Mika Epstein) 1:36 am on July 14, 2016 Permalink
    Tags: design, ,   

    New Repo Open Beta 

    Please review the proposed new repository and leave some comments so Obenland can make all more awesome.

    Plugin Directory v3 Open Beta

     

     
  • Ipstenu (Mika Epstein) 8:59 pm on July 11, 2016 Permalink |
    Tags: , teams   

    Reviewing the Guidelines 

    The official plugin guidelines are currently found on DevHub under Detailed Plugin Guidelines. The older version now redirects (thank you!). Like the Codex and DevHub, we’re mid transition and apologize for any confusion when that redirect wasn’t happening.

    Historically, any time someone has a patently clear misunderstanding about what a guideline means, they are asked if they can help us understand what was confusing and how to make it better. I’m sad to tell you that in the history of me asking that question, less than five people out of the hundreds have replied.

    Since we have the goal in mind to expand the plugin review team, one of the requirements on me as the rep is to clarify the Plugin Repository Guidelines. In the last seven months (since the Community Summit 2015) I have been refining, tweaking, and editing them in an attempt to make them more clear so we can get them at a point where they will be easily enforceable by people who don’t have the deep history of understanding misbegotten behaviors that caused their creation in the first place.

    The sole reason this has been done in private was so that those currently on the team were all on the same page before we bring it up to the rest of the world.  Once we know we understand the guidelines, then we can educate the next generation. It’s taking us this long to straighten things out in part because we don’t have a handbook. Not a one. I’ve started from scratch to make a passable one, which is now being converted into something understandable and sharable with others.

    My personal goal is to have ‘beta’ release of the Handbook up by end of July and the revamped guidelines available for public discussion here no later than end of August.

    I am greatly sorry if anyone thinks they weren’t listened to, or that the guidelines were some great big secret circle of conspiracy. Neither are the case. We have always listened, we have always been adjusting things, and we’ve (almost always) been working on a major overhaul of everything. We were just starting from a very different position than nearly any team out there on WordPress.org, which made it exceptionally difficult.

    There have been a lot of hurt feelings both within the team and without, but I’m optimistic that we’re now, finally, at a good place to move forward.

    Please keep an eye on this blog for what’s next.

     
    • Gabriel Reguly 9:24 pm on July 11, 2016 Permalink | Log in to Reply

      Guidelines suck, but are needed to keep a sane environment.

      For all involved in creating the guidelines and applying them, thanks for the effort!

      Cheers,
      Gabriel

    • vovafeldman 9:57 pm on July 11, 2016 Permalink | Log in to Reply

      Thanks for refining the guidelines.

      I would like to ask for a clarification about point #8 “No sending executable code via third-party systems.”. It ends with “Executing outside code like this is not allowed except for specific and very carefully considered cases (such as during upgrades, for example).”

      I’m trying to understand if the following scenario is one of those “upgrades” exception cases:
      1. I have a free plugin on .org
      2. A user purchases the pro version and gets a license key
      3. The user fills the license key in the plugin’s settings page
      4. Instead of asking the user to manually download the paid version, deactivate the free one, and activate the pro, automatically fetch the pro version and replace with the free one.

      Whether it’s manual or automated process, in the end of the process, the same code will be installed on the site. It just makes the experience more user-friendly.

      Is that considered to be one of the valid exceptions?

      • Ipstenu (Mika Epstein) 10:22 pm on July 11, 2016 Permalink | Log in to Reply

        That would not be a valid exception and, in fact, is what this guideline is trying to prevent.

        Also keep in mind that license checks like that may also be a violation. I’d want to look at the specifics before I said anything set in stone. Your FREE plugin on .org has no need for a license check.

        Your pro version sounds like it’s doing a lot of duplication of effort, with the same code in two places if you’re replacing free with pro. In general, the add-on method is a lot saner. Then you could have the license check code in situ in the free version, but it’s only checked by the pro add-ons. EDD does this method, as does Woo. This also makes sure you never have the problem where your free and pro versions have the same folder names 🙂

        • vovafeldman 10:28 pm on July 11, 2016 Permalink | Log in to Reply

          The pro version was just an example, I can ask the same question about a pro add-on. Would that be ok to auto-install the add-on to save the hassle for the site owner?

          If not, would you mind giving an example for a valid case?

          • Ipstenu (Mika Epstein) 11:39 pm on July 11, 2016 Permalink | Log in to Reply

            I’m trying hard to think of a valid case, and I’m coming up short. FWIW, that’s one of the rules being currently totally re-written to make more sense 🙂

        • vovafeldman 10:44 pm on July 11, 2016 Permalink | Log in to Reply

          Btw. It’s an idea that I have in mind, not something that I have implemented yet. I think that there’s no need for any license checks, it only requires one request to validate the license when clicking the “Activate License”, and the user can get a clear disclaimer before that clarifying the request will trigger an external API call.

          Adding to that, what if the button’s label will be “Activate License & Install Plugin” + the user will have a clear disclaimer before saying “By clicking *Activate License & Install Plugin* the pro version/add-on will be automatically downloaded from my-cool-domain.com, installed and auto activated on your website.”

          It could also be with an opt-in checkbox:
          [ ] Auto download, install and activate

          As much as plugin installation/activation is easy, some “entry-level” users will benefit a lot from having this automation.

          • Ipstenu (Mika Epstein) 12:01 am on July 12, 2016 Permalink | Log in to Reply

            Soooo this quickly went down the slippery slope of exactly why these things are so gosh darn complicated! And a lot of this is why the plugins are getting a re-write.

            I need to stress that the plugin guidelines are being rewritten. That means a lot of these questions are going to change based on that, and I don’t really want to spend a lot of time explaining terrible-old-busted things when I know that soon we will be asking people to tear apart awesome-new-cool guidelines 🙂

            I’m NOT trying to avoid this question, it’s just a matter of how far down the road we want to go. So let me quickly touch on the issues.

            tl;dr: It appears to be a situation where I would say no, that’s not permitted.

            1. License checks like that are a no go. Using a license ONLY to check if someone has access to download your pro version is not a service, it’s not okay, don’t do it.

            2. ‘Activate and install’ is intended for other plugins hosted on .org only. Your plugin must not install software, automated or otherwise, from outside WordPress.org.

            3. All of this runs a HIGH risk of confusing users, such that they aren’t fully clear on where they got a plugin from and who they paid. Furthermore,

            That last one is huge. You’re considering the ease of a user to install a plugin from outside our purview. We’re considering the overall view of WordPress and all plugins and how this would impact all users in understanding what is part of WordPress.org, what is not, and what that means.

    • Raam Dev 10:24 pm on July 11, 2016 Permalink | Log in to Reply

      Mika, I’d love to help with Handbook. I have good proofreading skills and a knack for explaining technical topics to non-technical users (as I’m sure you do). If you could use my help in some way, please let me know. 🙂

  • Ipstenu (Mika Epstein) 4:36 pm on July 6, 2016 Permalink |
    Tags: , ,   

    Repository Guideline Reminder: Do Not Remote Load Content 

    In a very irregular feature, we’re posting about various plugin guidelines and what they really mean to you.

    This week, we want to remind you about a long-standing guideline in the repository, which is covered in item #7 – Don’t phone home without consent.

    No “phoning home” without user’s informed consent. This seemingly simple rule actually covers several different aspects:

    The guideline goes on to break down what we mean in four main points:

    1. No unauthorized collection of user data
    2. All images and scripts shown should be part of the plugin
    3. No 3rd party ad tracking
    4. No ad-spam

    That second item (which I emphasized) is what we want to remind you of today.

    Your images, your scripts, your CSS, etc, should all be included locally. Besides not tracking users, keeping everything locally will make your plugins faster. It obviates the problem of external load. It means when your server is down for maintenance, you didn’t just slow down everyone’s wp-admin. It means you’ll never DDoS yourself on accident.

    Unless you’re a service, your plugin has no business phoning home to your own servers to load data. If you are a service, you must have this clear in your readme as to what the service entails, preferably with a link to your ToS and and explanation as to what is tracked. This is for your protection. By remote loading files, you have the ability to track users. Data tracking is a huge deal, and while we understand you want to do it for metrics, it someone was taking your data without permission or consent and selling it or using it to promote their code, you’d be pretty ticked off.

    You can (and should) re-read all the guidelines on https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/ – we rarely change them though we may reword things for clarity.

    If you have suggestions as to how we can be more clear about #7, please leave a comment and let us know.

    Keep in mind, we’re not going to spell out everything to the letter, as in our experience that leads to people playing nit-picky fake-lawyers about everything, and still violating the ultimate rule of the guidelines which is ‘Don’t be a spammer.’ For example, we’re not going to make a rule for not stealing other people’s plugins. You already know stealing is bad, right? 😈

     
    • vovafeldman 12:58 am on July 7, 2016 Permalink | Log in to Reply

      Hey Mika, I totally understand the not phoning home guideline. What is the reviewers’ view on using JS libraries from popular CDNs like MaxCDN, ClodFlare… It’s beneficial for the site owner because it’s reducing the load to the CDN (efficiency, speed and $$$ wise), it reduces the size of the plugin so it saves storage on the SVN repo, etc.

      Just a thought, maybe you can create a collection of “approved” CDNs, or create a W.org CDN for the community. What do you think?

      • Ipstenu (Mika Epstein) 5:42 am on July 7, 2016 Permalink | Log in to Reply

        We currently do not recommend cdns for us libraries for a related reason – unnessecary dependencies. If the cdn is blocked, like if you’re on a private network, it causes a terrible experience to the user.

        Fonts are our only exception, and even then I caution developers often, as google fonts are NOT universally accessible.

        Edit: also it’s not as much of a money/speed gain as you’d think :/

    • Joel James 5:19 am on July 7, 2016 Permalink | Log in to Reply

      Hey @ipstenu,

      What if we ask for user permission to place a link, then place a link to the public site when search engines or bots (not real users) visits the site? Is that illegal?

      • Ipstenu (Mika Epstein) 5:46 am on July 7, 2016 Permalink | Log in to Reply

        Please don’t use the term ‘illegal’ – it’s an incorrect term.

        Short answer: don’t do it

        Long answer:

        Strictly speaking, it would be permissible in the guidelines, especially if you make it clear that’s exactly what’s happening.

        Now that said, you’ll screw up your SEO like that, because Google can tell when you’ve made bot/search engine only content. And they consider it a scam.

        So … Y’know, don’t 🙂 it would end badly for you, it would hurt your SEO, it MIGHT hurt that of the sites you’re linked from. It is a terrible idea.

    • Paul de Wouters 8:09 am on July 7, 2016 Permalink | Log in to Reply

      Does this mean a plugin cannot retrieve content from an API then?

      • Ipstenu (Mika Epstein) 2:34 pm on July 7, 2016 Permalink | Log in to Reply

        An API is a service, is it not? Services are noted, in this post and the guidelines, as being an exception.

        Make sure it’s clearly documented in the readme that your plugin uses a service, link to the service, explain how to sign up for it or what the tos are.

        • Paul de Wouters 6:42 am on July 8, 2016 Permalink | Log in to Reply

          thanks for clarifying. I personally didn’t know “service” had that meaning in this context

        • Paul de Wouters 6:44 am on July 8, 2016 Permalink | Log in to Reply

          we’re not a “service” though, we just just retrieve content via a call to the WP API on a remote site.

          • Ipstenu (Mika Epstein) 8:44 pm on July 11, 2016 Permalink | Log in to Reply

            I’m not really psychic 🙂 When you said “an API”I assumed “An external system or service that provides information not otherwise available to a WordPress site.”

            Now turning around and saying “The WP API” doesn’t make the source of your data any more clear to me. If you said “This plugin reaches out to the WordPress.org plugin API to pull in data…” I would still say “Document it as a service.”

            If you’re calling data from outside the user’s site and server, then the user MUST know. Plain and simple 🙂

    • Nathan Johnson 5:03 pm on July 7, 2016 Permalink | Log in to Reply

      FYI, WordFence attempts to load their logoon the dashboard widget from their domain.

      • Ipstenu (Mika Epstein) 8:56 pm on July 7, 2016 Permalink | Log in to Reply

        In general we ask you email `plugins@wordpress.org` with that, so as not to public shame people. I’ll contact them, though. Thank you for letting us know.

    • Chuck Reynolds 2:44 am on July 15, 2016 Permalink | Log in to Reply

      like this one i just found? [redacted]

  • Ipstenu (Mika Epstein) 8:44 pm on June 26, 2016 Permalink |
    Tags: ,   

    WCEU Contributor Day 

    I want to thank everyone for coming to the first ever plugin review contributor workshop!

    We did not get half as much covered as I’d like to but I hope that we were able to enlighten some of you as to how the repository and review system works.

    I’m looking forward to the near future when we’ll be able to start adding some of the wonderful people who came to contributor day to the review team! Since that’s still a bit in the future, what we can do right now is welcome everyone to #pluginreview !

    Slack

    That’s right, we have #pluginreview as a channel now. This channel is for us (yes, you and us) to talk about plugins, finding issues like base64 and creative commons code. At this time, in order not to put users at risk, please continue to send security issues to plugins@wordpress.org only.

    I plan on posting some plugins for you to download and look at and discuss, as well as possibly have open hours or a scheduled time every once in a while to talk about reviewing a plugin as a group.

    Also if you have a question about the plugin repository in general, please feel free to ask there. Please remember to be reasonable, though, and try not to ask “When will my plugin be reviewed?” 😁

    Getting Started

    In the mean time, what can you do to get started?

    First, read the guidelines. Read all the guidelines. Memorize them. Be familiar with things like phoning home, and the difference between a serviceware API and a license check that cripples software needlessly. Don’t worry too much about that, but do get familiar with the guidelines.

    Next! Grab the Mark Jaquith Plugin Directory Slurper. The repo is about 25 gigs, more or less, and will take you a few hours to download. By a few what I mean is set your laptop not to sleep, put it in a cool room with a fan, and go to bed. The Slurper doesn’t work well on Windows that I know of (sorry Windows people). Anyone who wants to improve that, pull requests and forks are welcome.

    Now once you have the whole repo, start poking at things. Look for code you know is not allowed in the repository (non-GPL is a great start, pick a popular library you know isn’t GPL and grep or ack for it).

    Talk about what you find in the Slack channel. Remember: Slack is public. Do not post anything rude, insulting, antagonistic, or mean there. Also don’t post security issues there. Please keep that to email.

    Finally, if you’re really super into code ideas, download the (broken) Plugin Check plugin! Have a look at it. Try to figure out how you’d make it work, and maybe fork it onto GitHub and start tinkering. Start with the basics (check for non GPL, calling wp-load directly, including jquery etc) and see how far you can get. More hands make light work, after all.

    When Will We Accept New Members?

    Soon! I’m sorry, but I just don’t have an ETA.

    We need the UX for the repository revamp to be usable and acceptable first. Until then, we’re on that lousy, single-threaded, bbPress setup. Once that changes, the plan is to start letting people apply (and yes, we will post requirements for that) and adding them with access to review privately. Think of it as moderated reviews. But trust me here, we can see the end and we have a plan.

    We’re like Cylons.

     
  • Ipstenu (Mika Epstein) 5:06 pm on June 24, 2016 Permalink |  

    FYI: Yes the reviews are backlogged.

    Please just be patient. Half of us are at WordCamp EU so it may be a bit before we catch up.

    We’re back on track.

     
  • Ipstenu (Mika Epstein) 8:55 pm on May 31, 2016 Permalink |
    Tags: bribery,   

    Reminder: Do Not Compensate Reviewers 

    It was brought to our attention that some plugin developers on WordPress.org have used various third party services to find new users for their plugins and to have them leave reviews on our site.

    It’s time for a reminder.

    We do not allow for compensated reviews to be on our site, by any means whatsoever, and consider those reviews to be disingenuous.

    The WordPress.org plugin and theme directories are for users to write their experiences, not for companies to use market their products. A compensated or recruited review should be posted on someone’s own site, the reviewers own site, or the 3rd party site itself.

    While you may not consider getting a product free (or at a discount) to be compensation, we do. It messes up the system, which really is meant for people who legitimately use a plugin to leave a review of their experience. It’s also misleading, in our eyes, because it was not made by an actual user of the product in question.

    Asking an existing user to leave a review is one thing. Emailing your user base, while possibly annoying to many people, is totally fine. Reaching out to new people and saying ‘please try and review’ inflates the number of reviews in an unnatural manner.

    You may have heard about how Amazon does permit reviews like that, as long as the reviewer “clearly and conspicuously disclose[s] that fact” in their review. We’re not Amazon, and being a much smaller community, we’re able to monitor our reviews in a tighter manner. Paid reviews, compensated reviews, or recruited reviews are all the same idea. You’re ‘paying’ someone to review.

    The Consumerist has a long article about this, asking Is Amazon Doing Anything To Fight Latest Wave Of Fake, Paid-For Reviews? This article illustrates the issues these kinds of reviews cause, primarily they break the trust a reader has in any review. Also keep in mind that companies like Yelp hire people to blacklist companies who reward people for leaving reviews.

    This is just something you should avoid and reviews that are found to have been compensated for will be removed.

     
    • A5hleyRich 9:04 pm on May 31, 2016 Permalink | Log in to Reply

      While I agree that those types of reviews are bad, it’s frustrating that you remove them but not the 1 star reviews left by users trying to pressure plugin authors into providing support.

      • FolioVision 9:25 pm on May 31, 2016 Permalink | Log in to Reply

        Yes, it’s quite ironic as Mika has personally told me that vendetta reviews (where one refuses to sell the product to someone demanding one build him a site for free) are fine. Otto has personally told me that ignorance reviews (criticizing a plugin for the absence of features it clearly has) and/or extortion reviews are fine (and should stand) – and that one should drown those bad reviews out with positive reviews.

        If encouraging one’s existing users to write positive reviews is considered over the edge, what is an honest plugin author supposed to do?

        What’s particularly irritating is that favourites like Yoast or JetPack get special treatment (they get direct heads up from the plugin team about bad reviews at which point storm troopers like Jan Dembowski are dispatched to bludgeon the reviewers senseless). A negative review on either of those products is not allowed comments and is closed immediately if one appears.

        It’s discouraging to see where the spirit of open source attached to VC and slick marketers and an insiders’ game is taking us.

        PS. Mika, I appreciate you trying to clean up the plugin directory but I fear it’s the honest long term participants who will suffer while the scoundrels will bribe or weasel their way out.

        • Drew Jaynes 9:34 pm on May 31, 2016 Permalink | Log in to Reply

          > If encouraging one’s existing users to write positive reviews is considered over the edge, what is an honest plugin author supposed to do?

          To be fair, that’s not what she said at all. You can reach out to your existing users all you want and ask them to write reviews. But you can’t ‘pay’ them in some way to do it.

          > Asking an existing user to leave a review is one thing. Emailing your user base, while possibly annoying to many people, is totally fine. Reaching out to new people and saying ‘please try and review’ inflates the number of reviews in an unnatural manner.

          Emphasis mine.

        • Ipstenu (Mika Epstein) 9:42 pm on May 31, 2016 Permalink | Log in to Reply

          A vendetta review is ‘fine’ is it’s one review. If someone is harassing you or stalking you off the site, tell us and they’ll be permabanned. We protect people from abuse.

          But people being pissed and acting like idiots because they don’t like your product? Okay… yes. Par for the course. It makes them an unreliable reviewer to pretty much everyone.

          What’s particularly irritating is that favourites like Yoast or JetPack get special treatment (they get direct heads up from the plugin team about bad reviews at which point storm troopers like Jan Dembowski are dispatched to bludgeon the reviewers senseless).

          Not true. Not once. Not ever. I have never, nor shall I ever, alert plugin devs to bad reviews UNLESS it’s “Hey, this user went insane and I deleted it, PLEASE DO NOT PICK A FIGHT!” And that’s happened… twice? Maybe.

          Also Jan is not ‘dispatched’ to do anything. He monitors the reviews as an ambassador without portfolio. We don’t ask him to. He does it because he cares.

          If encouraging one’s existing users to write positive reviews is considered over the edge, what is an honest plugin author supposed to do?

          You seem to have conflated the terms ‘encourage’ and ‘compensate’ somehow though I don’t really get how you did that.

          Encourage them all you want 🙂 Just don’t pay them with money, rewards, free stuff, etc etc.

          “Hey if you like this plugin, please consider leaving a five star review.”

          That’s encouragement.

          “Hey if you leave me a five star review, you can have this add-on for free!”

          That’s compensation.

          • FolioVision 11:55 pm on May 31, 2016 Permalink | Log in to Reply

            Hi Mika,

            Thanks for taking the time to answer. My experience is different. I could document my experience of this with specific threads and direct quotations but it would take us too far away from your original important topic.

            Encourage/compensate – I think it’s perfectly legitimate to give real clients small favors in exchange for getting off their backsides and writing detailed, helpful reviews. Beats nagging people to death (the alternative). Harassment via dashboard admin notifications is completely abusive and in my opinion highly destructive to WordPress (we’ll be introducing notification suppression and sestration in BusinessPress very soon).

            Bribing people who either don’t use your software or at least not that product to leave positive reviews that’s something I would have an issue with it. So no I don’t think the line is as clear as we’d all like it to be.

            Alec

            • Ipstenu (Mika Epstein) 12:22 am on June 1, 2016 Permalink

              If I could write something that was never misinterpreted by someone, I’d run for political office.

      • Ipstenu (Mika Epstein) 9:37 pm on May 31, 2016 Permalink | Log in to Reply

        We actually do, in some cases, but in general your mature and well mannered response, telling them to please open a support ticket, is better than an arbitrary number.

        Also they can change their reviews.

    • emanweb 10:09 pm on May 31, 2016 Permalink | Log in to Reply

      Some reviews are obviously not natural. Either good or bad. I guess the only way to help avoid a bit this problem is to do the same as Amazon and ask “Was this review helpful to you?” And of course only allow users withing certain “level” to judge. Then sort the reviews by relevance like Amazon also do. It would also help with right next to the reviewer username show a summary of his contribution to WP.

      • Ipstenu (Mika Epstein) 11:18 pm on May 31, 2016 Permalink | Log in to Reply

        Read the link at the bottom of the post. It actually talks about why what Amazon’s doing is making reviews LESS relevant :/

        Bots can mark things as helpful too, and yes, that’s ALSO a problem.

        Instead of adding more systems to the mix, we’re hoping that appealing to the humanity of things and ‘don’t ruin this for everyone’ will be more beneficial.

        • FolioVision 12:04 am on June 1, 2016 Permalink | Log in to Reply

          Would it be possible to build some kind of a trust score system which removes low quality reviewers votes, Mika? I know it’s not easy (simple systems are equally vulnerable to gaming) but sites like SlashDot and Reddit and StackExchange have managed to make reputation work well.

          As Emanuel notes, some members have been contributing to WordPress, Wordcamps and the ecosphere since 2007 or even earlier, with a rich history of presentations and/or plugins and/or core contribution. Many others are simple drivebys or paid flacks. It should be easy to see the difference (a simple visible trust score?).

          From what I’ve seen of the current internet, ‘don’t ruin this for everyone’ won’t work anymore. There’s also a fair number of people sending saboteurs out to hit up their competitors with negative reviews (hopefully you catch the obvious ones). This isn’t just a WordPress.org issue, sabotage (via fake reviews) is a real, real problem at MacUpdate for instance. It didn’t use to be (i.e. the weather is changing).

          Thanks, Alec

          • Ipstenu (Mika Epstein) 12:20 am on June 1, 2016 Permalink | Log in to Reply

            Not at this time. It’s a monumental amount of code, and no ones been able to make it work yet. The sites you mention have their own vote scam issues. We’d trade one for the other, and we know it.

            • FolioVision 12:53 pm on June 1, 2016 Permalink

              There’s a lot of open source code out there Mika that WordPress.org could tap into to make the reputation dance work. What we have now does NOT work for plugin publishers. We are vulnerable to both extortion demands (we had to pay the user to remove the bad review), revenge reviews (similar to extortion but the user has given up on getting what it is they want and simply wants to destroy your company – in particular the review here has nothing to do with plugin functionality or our free plugin), reviews where the user seems to be using another plugin (as we have no nag screens and never have: two posts at WordPress.org in five years, no response to our questions) and simple drivebys (one star, only review written, user clearly doesn’t have expertise to self-publish).

              On the other side, in certain areas plugin authors face competitors who are prepared to break every rule to win and as I mentioned before, “favored son” candidates like JetPack who have internal protectors as well as endless highlighting in “Featured” lists. Muddling along while it may suit the volunteer moderators does not suit most plugin authors. Some kind of reputation weighting would make the WordPress.org reviews much more useful to users and fairer to plugin authors.

              Once again thank you Mika for raising the important topic of bias in reviews and taking some action on the matter.

    • Monika 7:25 am on June 1, 2016 Permalink | Log in to Reply

      @FolioVision, Besides the fact that it is technically a lot of effort, there is a language problem. I can write qualified reviews in German, but hardly in English. English is not my first language.

      I use plugins and always ask my customers whether they would like to give a review. Very often they want, but can’t because they do not speak English.
      None of my clients have ever been on a WordCamp or MeetUp. But they are often happy, satisfied users. Therefore, the visibility in the “WordPress world” can’t be a measure of reputation for reviews.

      Each voting system can be manipulated. Fairness in the business world is an illusion. Even outside the WWW. 🙁

      • Marcel Pol 11:20 am on June 1, 2016 Permalink | Log in to Reply

        I am always happy to receive a 5-star review in German, Russian or Portuguese. So if your customers don’t speak English, you could tell them to post a review in German. I don’t see anything wrong with that, it would be even a bit charming.

      • Ipstenu (Mika Epstein) 3:13 pm on June 1, 2016 Permalink | Log in to Reply

        Most of us are happy to attempt to use Google and get reviews in any language. And with the new setup for international plugins, I think it may be easier to go to de.wordpress.org/plugins/hello-dolly to leave reviews.

    • Scott Wyden Kivowitz 12:57 pm on June 1, 2016 Permalink | Log in to Reply

      I agree with companies not compensating, however if that is going to be enforced I think illegitimate reviews (like ones that should be support forum threads) should be removed as well.

      • Ipstenu (Mika Epstein) 3:11 pm on June 1, 2016 Permalink | Log in to Reply

        Those aren’t really illegitimate, and it’s a totally different issue.

        Reviews that should be support are people who used your product and somehow can’t find how to do things but can find how to leave a review. They are real users.

        Paid for reviews are people who probably wouldn’t otherwise have touched your product being compensated for a review.

        Both are problematic. One is ignorance, and one is intentionally gaming a system.

        • FolioVision 10:23 pm on June 2, 2016 Permalink | Log in to Reply

          Scott’s point is sound. I really don’t understand why illegitimate accidental reviews should get better treatment than illegitimate deliberate reviews. Mika, your job (collective you, plugin repository moderators) should incorporate advocating for plugin authors and not just unqualified/casual users.

          High quality free plugin authors (Alex King, John Godley, Pippin Williamson, us to name just a few) are the people most responsible for WordPress’s popularity. Please give a thought to us and how to make our work easier. Fighting extortion reviews which should be support tickets is a crippling process which we should not have to go through. There should be a set process for disqualifying simply incorrect reviews (wrong plugin, no competence at all with web technology) and extortion reviews (should be support tickets).

          To keep it simple, when a 1 star review is so vague that it could be for any plugin and the plugin author has requested more information and has not been answered after a period of time the author could flag the review for a moderator. Then the moderator could request formally request more information, possibly screenshots. If the “reviewer” has a dead email or can’t be bothered to respond, the review disappears.

          Reviewing is not a right: it is a privilege. Plugin authors are the ones volunteering their time and contributing for free (in some cases for many years, we have maintained plugins which six years old and have contributed to plugins which are ten years old).

          In the end, higher quality reviews benefit both users and plugin authors. It’s a win-win situation.

          Thanks again for listening.

          • Ipstenu (Mika Epstein) 5:02 pm on June 3, 2016 Permalink | Log in to Reply

            It’s not the point of THIS post, folks.

            This post is merely about people who pay for reviews.

            Are there other issues? Of course. Am I going to get into every single one in a comment debate with people? Good lord no. It’s pointless and it detracts from people who are having questions about what we mean by ‘Don’t compensate people for their reviews.’

            If you have questions or concerns about that, please ask them here.

    • Joy 2:20 pm on June 1, 2016 Permalink | Log in to Reply

      The problem with reviews is that they live where the user doesn’t. The point at which you buy or download the product is where you should see usage stats, not where you should leave a review — because new users don’t have anything to say.
      The review system should be embedded in the user’s admin panel, and only become visible after a reasonable amount of usage.

      • Ipstenu (Mika Epstein) 3:13 pm on June 1, 2016 Permalink | Log in to Reply

        The only issue there is we still need them to have a .org account for … accountability.

        Also Amazon reviews aren’t where the users live either and it doesn’t seem to stop them.

        • Joy 7:56 pm on June 1, 2016 Permalink | Log in to Reply

          Having an account doesn’t sound like an issue. They need one today, don’t they? Or if you used the domain name as the accountability, you could limit them to one review per domain.
          Amazon reviews have all the issues you guys are arguing about. They have to cover digital and physical products, so they are at a disadvantage. WordPress has the advantage of being only digital *and* controlling that digital product so that only actual users can review. It seems like the perfect answer to me.

          • Ipstenu (Mika Epstein) 9:37 pm on June 1, 2016 Permalink | Log in to Reply

            Nope, you don’t need an account to download plugins or install them. And a domain wouldn’t work, since splogs and tracking domains without permission etc are major issues.

            The monitoring of accounts is something that cannot be automated sadly. We need acutall people checking on reviews and making sure they’re real people. Which … well. Not a lot of people want to do that 🙂

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