WordPress.org

Make WordPress Plugins

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

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

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

  • Ipstenu (Mika Epstein) 11:55 pm on May 19, 2016 Permalink  

    Please check out the proposed plugin directory redesign 

    Plugin Directory Prototypes

    This is talking about the theme only 🙂 Jump in and leave constructive comments please!

     
    • Varun Sridharan 1:20 am on May 20, 2016 Permalink

      Hi,
      I really like this.. the plugin homepage with a featured slider and also the plugin listing.. 🙂

      any changes on single plugin page too ?
      and i hope you will add sliders for the plugin listing like Beta Plugins in homepage 🙂

  • Ipstenu (Mika Epstein) 10:14 pm on May 12, 2016 Permalink |
    Tags: ,   

    Policy Reminder: Tracking Users 

    Do not, under any circumstances, track usage of your plugin without explicit consent.

    If you want to ask your users if you can track them, by all means ask. But you may not require it, and you shouldn’t make it look like they have to in order to use your plugin. That’s being dishonest.

    This has been a guideline for a very long time, it’s not negotiable. Assume people do not want to be tracked and have it to be an opt-in feature.

    If your plugin uses Google Analytics, emails you on plugin activation, triggers some complex check on your servers when a plugin is updated, or tracks usage in any other way when a user has not clearly said “Yes, I allow you to track me,” your plugin will be removed from the repository and you will have to correct this in order to get it back.

    This extends to ads provided by a third party service. If your plugin includes advertising from a third party service, then it has to default to completely disabled. This is to prevent tracking information from being collected from the user without their consent. Again, this is all about people opting into being tracked.

    (For those thinking about using Adsense, don’t. Re-read their Adsense Display Guidelines and note that they do not want you to put ads on non-content pages … which is what the whole WP Dashboard is.)

    Don’t assume that just because someone said they agreed to have usage tracked by you that they’re okay with usage tracked by someone else. Don’t be shady or vague. Tell people upfront “This is who will get the following data…”

    Remember, user trust is paramount to your plugin’s success. If people find out you’re sneaky tracking them, you will lose that trust in a heartbeat and there’s nothing anyone can do to help you restore it.

     
    • buzztone 10:49 pm on May 12, 2016 Permalink | Log in to Reply

      RE: “you shouldn’t make it look like they have to in order to use your plugin”

      I’ve recently noticed some plugins in the repository that do this. What’s the best way to report of this?

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

        First be a good person and point it out to them directly 🙂 “Hey, I like your plugin, but you’re making it look like people have to do X… Did you know that was against the rules?”

        Sometimes people simply don’t know. They should, but I can’t make people RTFM 🙂 Link them back here and give them a chance to be good people. If they don’t, then report it to us as a guideline violation (plugins AT wordpress.org) and we’ll be a little firmer.

    • David Anderson 10:07 am on May 13, 2016 Permalink | Log in to Reply

      Hi Mika,

      Thanks for the continual drip-feed of articles reminding plugin authors of best practices. Can I make a suggestion for a future one? One problem that eats up enormous amounts of man hours (for both site owners and plugin developers) is plugin conflicts. Lots could easily be avoided by simply enqueueing your scripts/stylesheets only on relevant pages.

      e.g. In wp-admin, first check it’s your page before your enqueue. That way, all issues of incompatible scripts/CSS would just disappear for a lot of cases.
      Similarly for loading PHP SDKs – only register your auto-loader, or whatever, for an SDK when it’s time to use it, instead of globally every time WP loads (which is also bad for performance).

      If more plugin authors were aware of some of these best practices, and spent a few minutes implementing them, it’d save huge amounts of time for people finding problems on their sites, investigating, forum-posting, etc.

      David

  • Ipstenu (Mika Epstein) 4:24 pm on May 3, 2016 Permalink |
    Tags: ,   

    Handling Bad Reviews 

    In general, the Plugin Review team is not the go-to recourse for bad reviews.  Instead, we have a totally brilliant forum support team! There’s some overlap of jurisdiction of course, and some of us are on both teams, but the point here is you should go to the right group to get the right help.

    I’m also going to put this out there. You will get a bad review. Most of the time, it will not be deleted. So before you get any further in this post, know that the way you chose to respond, in public, to a 1-star review of your plugin is your own choice.

    Our goal with the WordPress.org repository is to have a good place for users to get plugins that fulfill their needs. The reviews are an extension of that, and should viewed as a way for users to educate other users on their experiences. Also a review is about an experience. If someone’s experience with your product is poor, that doesn’t make their review invalid. And to go back to that previous statement, the way you react to those poor experiences is going to impact your reputation, and that of your plugin, a heck of a lot more than that review.

    Now, that said, we have a few ‘common’ types of problems with reviews. This post is going to help you handle them and explain when you should call for help, as well as from whom. Later on we’ll be adding it to our documentation, once it’s refined as best we can make it. Please remember, we do not want to make a ‘rule’ for everything. That just invites people to play rules-lawyers and tip over everyone’s cornflakes.

    Here’s how you do it and when and why.

    First off… How to add a tag!

    99.999999% of the time, you’re going to be adding ‘tags’ to posts. This is so easy, you may kick yourself for missing it. On a post, look on the right hand side, under About this Topic and you’ll see a section for Tags

    Tags are listed on the right hand side of a post

    This is a free-form field where you can add any tag you want. Anyone can add any tag. The forum moderators have an easy way to know who added what, though, so keep in mind we do monitor that. If you want to add a tag to a post and reply, add the tag, press the Add button, and THEN come back to reply. It works better.

    Tag abuse (that is calling moderators needlessly) is not okay. Be smart. Be thoughtful. Remember that every last member of the forum and plugin teams is a volunteer. We’re not being paid by Automattic to do this.

    The spam review

    This is easy. Don’t reply, just add the tag modlook to the post and walk away. The forum team will delete it. If you think it may not be obvious spam, add the tag spam as well.

    The sockpuppet review

    When a person (or group of persons) 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.

    This behavior is expressly NOT welcome on the WordPress Forums as it is spamming. But it comes in two flavors:

    1. Someone 5-star spamming their own plugin
    2. Someone 1-star spamming their competition

    Both are bad behavior. Both will get plugins removed from the repository and a stern email from us. If you’re doing this, stop right away. Contact your team and tell them ‘Don’t do this!’ Also keep in mind, asking everyone in your company to 5-star review your own plugins is gauche. I mean, really. You’re stacking the deck on purpose and that’s not beneficial to anyone.

    Again, do not reply! Add the tag modlook AND sockpuppet to the post and walk away.

    The attack/troll review

    These are the worst. When someone attacks you and the review seems like all it exists for is to make you feel terrible, you’re going to have to take a deep breath and walk away. An attack is a troll, regardless of how the original poster (OP) feels, they’ve basically been a troll. They’re writing something they know will make you mad and hurt and angry, and they’re doing it on purpose. That’s a troll. And you shouldn’t feed the trolls. You won’t win, and you’ll just make yourself look bad.

    Again, do not reply! Add the tag modlook to the post and walk away. These are usually pretty self evident after all.

    The review that should have been a support post

    This includes the sub-genre “People who submit 1-star reviews in order to emotionally blackmail you for support.”

    We all get them.

    1. Reply with a link to the support section of your plugin (or directions on how to get support, or even a note that you don’t provide free support) and remind them that next time, they should ask for help before reviewing.
    2. See if you can fix the problem, but give it no more or less priority than you would any other support request.
    3. If you can solve it, ask them to modify their review. If they go back to https://wordpress.org/support/view/plugin-reviews/PLUGINNAME and scroll to the bottom, they can edit their reviews!

    You’ll notice we’re not telling you to tag the post? Right now we can’t move a review into the support forums and vice versa, so there’s really no point. The forum moderators won’t do anything about it except say “Well, that does suck.” If we could move them, we would, but right now we technically don’t have that ability.

    The review about your premium/pro version

    If you upsell your plugin’s pro version in the free one, and someone leaves a bad review because the pro version they bought, on the basis of your free one, is bad, congratulations. The review stays. You opened the door with your upsell, encouraging them to do this, and that experience reflects on your plugin as a whole.

    If you do not upsell, and there’s no direct link between the free and pro version, or the plugin having the issue is a premium only add-on, tag it modlook and someone will come take a look.

    The review about someone else’s plugin

    This one can be fixed! Reply and let them know it’s not your plugin, it’s the other one, and then tag it modlook and then use the tag wrongplugin (all one word) to let the mods know what’s going on.

    But I really need a plugin moderator!

    Okay. So you think you’re an exception? Use the tag pluginmod and a plugin admin will come take a look. Be prepared, though, as we generally will perform a full review on your plugin and any and all guideline violations will result in your plugin being removed until you fix them. Including using too many tags.

     
    • Austin Passy 4:39 pm on May 3, 2016 Permalink | Log in to Reply

      Thanks Mika!

      It’s good to know that these tags exist.

    • Phil Derksen 4:48 pm on May 3, 2016 Permalink | Log in to Reply

      Very helpful Mika. Thanks.

      I also found it helpful to use the #forums channel on wordpress.slack.com. Great place to discuss how to respond to negative reviews.

    • Syed Balkhi 5:06 pm on May 3, 2016 Permalink | Log in to Reply

      Thanks Mika – this would be very helpful.

    • dudo 5:20 pm on May 3, 2016 Permalink | Log in to Reply

      Hi Mika, thank you for sharing this.

      Some people just rate 1 star because there is not a function that they want/need.

      Does the pluginmod tag can be used in a case this?

      • dudo 5:21 pm on May 3, 2016 Permalink | Log in to Reply

        Sorry for typos

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

        No, do not use pluginmod for that. That would be the “People who submit 1-star reviews in order to emotionally blackmail you for support.” folk. We won’t remove them, but you can learn from them by either improving your documentation to be more clear about what features aren’t included, or maybe add them. Either way, that was someone’s experience. They used your plugin, they wanted it to have more to be truly functional for them.

    • Chad Butler 7:13 pm on May 3, 2016 Permalink | Log in to Reply

      Awesome information as usual Mika!

      I am in general agreeance with the policies, and having been around awhile, I know these have been the general policies for quite some time.

      My personal feeling is that the weakest point of the plugin review system is brought on by misuse by a small number of users in the community (most of whom aren’t really even participants in the community). In general, the community is great – and most people post worthwhile reviews.

      But there is a portion of the community that improperly uses the review system, as you’ve already pointed out – trolls, reviews that should be support questions, etc. And then there’s they guy who I place in a separate category – the useless review: 1 star, invalid complaint, never to be heard from again.

      Would it be possible to consider adding review voting to the system at some point in the future? Something similar to Amazon where people who read reviews can answer whether they found the review helpful or not.

      I think this would allow the community to self police this since the majority of the WP community are reasonable people.

      I was tremendously glad to see the addition of requiring an actual review in addition to just the star rating (that seems so long ago…). Would this be a next logical step?

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

        It’s a possibility, but it’s low on the to-do list. It would have to come well after the plugin revamp (in progress) and the forum rebuild (getting started).

        Limited resources.

    • Sakin Shrestha 1:37 am on May 4, 2016 Permalink | Log in to Reply

      Thanks Mika for sharing.

    • dartiss 8:31 am on May 4, 2016 Permalink | Log in to Reply

      That. Is. Brilliant. Never knew these existed but glad they do!

      • dartiss 8:36 am on May 4, 2016 Permalink | Log in to Reply

        One quick question – I have a review that I’d like looking at but it’s old enough that it’s closed so I can’t add tags. Is there a way around this?

    • Brad Touesnard 12:03 pm on May 4, 2016 Permalink | Log in to Reply

      Very helpful, thanks!

    • Maruti Mohanty 6:55 am on May 5, 2016 Permalink | Log in to Reply

      Superb. Thanks a ton

    • David Anderson 12:19 pm on May 6, 2016 Permalink | Log in to Reply

      One modest improvement I’d love to see to the review system, is that only reviews from the last 2 years (or some other value) affect a plugin’s rating.

      As it is currently, for mature plugins, there’ll be plenty of reviews which – whether for better or worse – are reviews of a plugin that doesn’t really exist any more. Currently, both good and bad reviews (fair or unfair) are part of a plugin’s rating forever.

      • Max Foundry 3:02 pm on May 6, 2016 Permalink | Log in to Reply

        I agree with this David.

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

        The reviews reflect the growth and development of the plugin in both code and attitude. For now, they bear weight as a historical basis.

        Maybe one day we’ll have ‘reviews for this version’ like Apple does. That would be more fair than just age, since not all plugins change that much 🙂

        • David Anderson 10:09 am on May 13, 2016 Permalink | Log in to Reply

          Hi Mika,

          I wasn’t suggesting removing old reviews – I agree that there’s value in seeing the growth/development. The suggestion was that they stop affecting the star rating after a reasonable amount of time. This allows the star rating to better reflect the current plugin, rather than being dragged towards a historical average which doesn’t affect what users can actually download and use.

          David

    • screamingdev 8:13 pm on May 7, 2016 Permalink | Log in to Reply

      Wow Mika Epstein. This phrase really catched me: “and any and all guideline violations will result in your plugin being removed”. Maybe we can get in touch because I am serving codebook.cc which does and will do a lot of checks for your guidelines on many plugins 😉 Please ping me via reply or Twitter @ScreamingDev. Cheers!

    • Ahmad Awais 12:28 am on June 3, 2016 Permalink | Log in to Reply

      Thanks Mika for this one. I didn’t know a few of those.

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