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.

As of Aug 2016, we are not able to accept new team members due to technical issues.

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) 10:27 pm on August 18, 2016 Permalink |
    Tags: , boom, deprecated, facebook   

    Facebook Changed Sharing Counts 

    Today, Facebook released version 2.7 of their API and changed the manner in which shared posts are counted.

    That would have been okay, except they also turned off the part of the 1.0 API (the one that didn’t use versions in their URLs because who needed that?) and blindsided everyone. Reading the Facebook Dev Changelog didn’t make that any more sensible to me either. But what I can tell you is here are some affected plugins/services:

    Anyone who has a plugin (or theme) with sharing buttons that count MAY be affected. If someone can come up with a way to scan the repository for impacted plugins, let me know and I’ll be happy to do that and email as many of them directly as we can.

     
    • Shareaholic 10:35 pm on August 18, 2016 Permalink | Log in to Reply

      We’re affected. It’s fixable and are working on a fix!

      Shareaholic: https://wordpress.org/plugins/shareaholic/

    • FolioVision 10:53 pm on August 18, 2016 Permalink | Log in to Reply

      Thanks for the heads up Mika. We ran into this last week with our (private) Pretty Social plugin, trying to keep track of Facebook like counts. The solution is to use the 2.7 API instead. Keep in mind that 2.7 has a short lifespan already scheduled to be deprecated in turn in July 2018.

      Moreover, the new API key has to be updated every two months!

      It’s the Access Token in queried URLwhich has to be updated. The use must log in via Facebook and generate the token. We haven’t managed to automatize it yet.

      For now, it works as follows: User must click on a notification link, which takes him to Facebook. Then s/he must authorize the app. At this point, Facebook should automatically generate long-access token via some query. Long access token expires in 60 days. We’ll be notifying admins in WP Admin a week or two before expirty to log in to Facebook to extend this token.

      I hope this helps those who are relying on the Facebook API fix their plugins more quickly. One service has completely shut down, in face of the endless API restrictions.

    • archon810 12:16 am on August 19, 2016 Permalink | Log in to Reply

      v1.0 hasn’t been available since April 30, 2015. What you’re thinking is v2.0 that got deprecated after plenty of announcements and several months lead time. Even though I got the notifications from Facebook, I procrastinated long enough for things to actually break when it was deprecated, but the fix was pretty easy: switch to using JSON values inside share->share_count.

      • Ipstenu (Mika Epstein) 1:29 pm on August 22, 2016 Permalink | Log in to Reply

        Nope. That’s what I thought too, but apparently the 1.0 urls were still working. So … It kind of is 1.0 still.

        Look, do not ask me to explain Facebook and their insane APIs. I barely use it.

    • Morten Rand-Hendriksen 6:39 am on August 19, 2016 Permalink | Log in to Reply

      Just for historical purposes, the Big Book of Faces has pulled this kind of stuff before. Moving forward I would urge anyone building plugins or themes relying on data from them to build in fallback features with the expectation that any service relied on can be pulled at any time without warning or proper error handling. This is not the first time this has happened, nor will it be the last.

    • Rene Hermenau 9:51 am on August 19, 2016 Permalink | Log in to Reply

      We have the same problem for our MashShare plugin. One workaround could be the use of the still public available graph api endpoint: http://graph.facebook.com/?id=https://www.yoursite.com

      I wrote something about this on our blog post:
      https://www.mashshare.net/rest-api-is-deprecated-for-versions-v2-1-and-higher/

      Until now it seems to be working without any access token.

      Doe anybody know if facebook is planning to make this endpoint available only for authenticated user?

    • Rene Hermenau 10:47 am on August 19, 2016 Permalink | Log in to Reply

      Ignore my last comment. The endpoint is NOT public available. Only accessible with a access token.

    • Jeremy Herve 6:36 pm on August 19, 2016 Permalink | Log in to Reply

      We’ve just released Jetpack 4.2.2 to address this issue. Facebook’s sharing counts are back. 🎉

    • Daniel15 8:56 pm on August 19, 2016 Permalink | Log in to Reply

      Version 1.0 of the API was deprecated way back in April 2015. I suspect you were actually using the REST API that was part of version 2.0. Version 2.1 (the replacement to 2.0) was released back in August 2014, and deprecated that old API. It’s been deprecated for two years, which should have been sufficient time to upgrade the code to use the new version.

      • Daniel15 8:59 pm on August 19, 2016 Permalink | Log in to Reply

        Also, ideally your API calls should all have a version number explicitly specified, rather than relying on the default version.

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

        That’s what I thought too, but _apparently_ the old 1.0 URLs were working for a long time on purpose. I know, right?

    • JP 9:58 pm on August 19, 2016 Permalink | Log in to Reply

      We have also already published an update for our one (Shariff Wrapper). It’s really just a simple change of the API request required. Seems a bit of an overkill to try to inform all possible affected plugin authors just for some share count issue. If they actively maintain their plugin, they will notice it easily and fix it soon after.

      • Ipstenu (Mika Epstein) 11:20 pm on August 19, 2016 Permalink | Log in to Reply

        We don’t consider making sure devs are informed and users are patched to be overkill 🙂 We think of that as being considerate towards our community. Besides, if Jetpack was blindsided, and I know they’re Johnny on the Ball with this stuff, then it was not as clear as it could have been from FaceyBookey.

    • Subharanjan 6:21 pm on August 20, 2016 Permalink | Log in to Reply

      Even some of the themes which provides this feature of showing share counts are OFF !! Going to check and submit an issue or a pull request with fix now. Thanks for this post !!

    • Dustin W. Stout 1:16 am on August 24, 2016 Permalink | Log in to Reply

      Hi Ipstenu! Just wanted to pop in and say THANK YOU for this! We had kind of caught wind of this but weren’t sure how it was going to affect our plugin. After it went into efffect, we made the necessary update to Social Warfare (https://wordpress.org/plugins/social-warfare/) and everything is working great! Really appreciate you letting the community know about this.

  • Ipstenu (Mika Epstein) 8:46 pm on August 3, 2016 Permalink
    Tags: , ,   

    Plugin Directory Revamp Meeting Today 

    Plugin Directory Chat Agenda

    This is _not_ a meeting about the plugin review process or guidelines. This is only about the revamp.

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

     
    • Clifford Paulick 6:46 am on July 29, 2016 Permalink | Log in to Reply

      Thanks for all the effort! Feel free to let me know if there’s some way I can help.

    • FolioVision 12:37 pm on July 29, 2016 Permalink | Log in to Reply

      Hi Mika. If you need any help with copyediting, please let me know.

      PS. Freezing the plugins of authors who don’t have working emails seems to be a reasonable step to me. Not sure how you should deal with the autoresponder types who do eventually answer though. You have my compassion (I deal with a lot email too).

      • Ipstenu (Mika Epstein) 3:55 pm on July 29, 2016 Permalink | Log in to Reply

        If someone with an auto-responder fixes the issue, we reopen the plugins. Simple as that 🙂 We’re not terrible people after all, and we strongly believe in second chances.

        Of course, if it happens again…

    • Mark O'Donnell 4:51 pm on July 29, 2016 Permalink | Log in to Reply

      Hi Mika,
      Thanks for all you do. I’ve done a lot of tech writing and editing in a former life, and I’d be happy to help wherever I can.
      -Mark

    • M Asif Rahman 7:54 pm on July 29, 2016 Permalink | Log in to Reply

      I would to love to help out, Mika. Let’s get it going.

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

      Thank you, Mika! I’d love to help review and edit.

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

    • usability.idealist 12:27 am on July 30, 2016 Permalink | Log in to Reply

      is that the reason why the one of the most important / helpful plugins just disappeared completely from the Plugin Repo?

      speaking of adminer, that is. Got an update info and a “last modification” of 2 days ago, but now its complete gone from the repo .. o.O

      cu, w0lf.

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

        We do not now, nor likely ever will, disclose why specific plugins are withdrawn from the repository. Either we’d be ‘dog shaming’ them by publicizing bad behavior, or we’d be making YOU more vulnerable to a hack. Since it’s a lose lose situation, we don’t disclose to ANYONE outside of the developers themselves. If they want to tell folks, that’s on them.

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

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

          Yup 🙂 When we say SEO, it is Google. Lol.

          Thanks @ipstenu

        • chesio 1:41 pm on August 17, 2016 Permalink | Log in to Reply

          @ipstenu, and still he did [link removed]

          I know that you are already aware of this situation. It just irritated me when I found @joelcj91 claiming “he was honestly not aware of this” [link removed]

          I hope he has learned his lesson well.

          • Ipstenu (Mika Epstein) 4:51 pm on August 17, 2016 Permalink | Log in to Reply

            I’m aware of the situation, I’ve spoken directly, privately, respectfully with Joel about the issue and why it was bad and what exactly was bad. It is my belief that this was a monumental screw up, and that he wasn’t aware of ‘this’ meaning he didn’t realize what his partner did.

            There are nuances to the ‘no remote loading’ that people often misunderstand. I don’t expect everyone to read my mind, and I know the quality of the guidelines is pretty bad right now. I am actively working on better ones to make things easier to understand.

            We can move on now and stop dog shaming people.

          • Joel James 5:29 pm on August 17, 2016 Permalink | Log in to Reply

            @chesio,

            Yes, I learned well.

            I never said(or at least I never meant) I was not aware about the remote loading. But I was not aware about the remote content changes he made. That made this serious spam.

            Also I misunderstood this – “Strictly speaking, it would be permissible in the guidelines, especially if you make it clear that’s exactly what’s happening”.

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

    • chesio 1:46 pm on August 17, 2016 Permalink | Log in to Reply

      Remote loading of content can also result in security issues when plugin domain expires: https://blog.sucuri.net/2016/08/plugin-expired-domain-security-threat.html

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

     
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