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 don’t offer help with using plugins, or with developing them. We act as gate-keepers and fresh eyes on newly submitted plugins, as well as reviewing any security or guideline violation that is reported.
Currently we have neither meetings nor office hours.

We can be reached by email at plugins AT wordpress.org

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Ipstenu (Mika Epstein) 10:21 pm on July 29, 2015 Permalink |
    Tags: 4.3, dfw   

    WordPress 4.3 Removes Old DFW 

    From Old Distraction Free Writing Code Removed in 4.3

    This release we removed all old DFW code, which hasn’t been used in core since 4.1. We left it in core for two releases so plugin authors had the time to update. If it is essential to your plugin, the files in 4.2 can still be reused and improved. See [32677].

    Please make sure you update your plugins before 4.3 is released.

  • Ipstenu (Mika Epstein) 5:31 pm on June 5, 2015 Permalink |
    Tags: ,   

    ‘Policy’ on PHP Versions 

    The official stance of WordPress.org is that WordPress is supported on PHP 5.2.4 or greater.

    The official stance of the Plugin Team regarding what version of PHP your plugins can use is .. not that.

    We don’t have an official stance. We’ve never needed one. We do (often) test complex plugins on multiple versions of PHP (and sometimes HHVM) to make sure there’s proper degradation and support, but at the same time, we do not have an official requirement that you must support version X or Y.

    This is not an official requirement post.

    This is a reminder post.

    Use whatever version of PHP works best with the code you’re writing. If you’re using, for example, Amazon S3’s library, you must use PHP 5.3 and up because otherwise the libraries won’t work. From that standpoint, your plugin should require PHP 5.3 and up. That’s a decision prompted by circumstances outside of WordPress.

    For everyone who just wants to know what to do if your plugin must be on PHP 5.3 or 5.4, the answer is this:

    Make sure your plugin checks for any and all requirements on activation and, if they’re not found, it should gracefully fail and alert the user as to why.

    This includes things like required software (if your plugin is an add-on to WooCommerce, yes, check that WooCommerce is installed and active), but also PHP versions and (if needed) SQL versions. That’s your responsibility. We’re not going to force you to do it at this time, but understand that your plugin’s reviews and ratings will be directly impacted by how you handle those things.

    Fail gracefully. Degrade gently. Error politely. Consider your users. Remember: WordPress can be used on anything.

    This can be complicated or not, depending on your requirements. The main thing to think of here is that if you don’t support PHP 5.2, then your main plugin still needs to work in PHP 5.2.

    Practical Examples

    Let’s say you use a function that only works in PHP 5.3 and up. A simple function_exists check will do the job:

    if ( !function_exists( 'some_function' ) ) {
        add_action( 'admin_notices', create_function( '', "echo '<div class=\"error\"><p>".__('Plugin Name requires PHP 5.3 to function properly. Please upgrade PHP or deactivate Plugin Name.', 'plugin-name') ."</p></div>';" ) );

    Note the use of create_function here, because anonymous functions (aka closures) don’t work in PHP 5.2.

    The use of return prevents the rest of the plugin from executing here, preventing that function call later from causing a syntax error.

    Sometimes though, you need more complicated checks. Let’s say your plugin uses PHP namespaces. Those are not supported in PHP 5.2, and will cause a syntax error just from having them in the file, before any of your code runs.

    So, your main plugin file needs to not have namespaces and basically only be a shiv to load the rest of the plugin from another file if the requirements are met:

    if ( version_compare( PHP_VERSION, '5.3', '<' ) ) {
        add_action( 'admin_notices', create_function( '', "echo '<div class=\"error\"><p>".__('Plugin Name requires PHP 5.3 to function properly. Please upgrade PHP or deactivate Plugin Name.', 'plugin-name') ."</p></div>';" ) );
    } else {
        include 'rest-of-plugin.php';

    Here, the plugin does not load the files that can cause errors unless the requirements are met.

    Maybe you need to check against the WordPress version. Plugins load in the global context, so the $wp_version variable is available to you to check:

    if ( version_compare( $wp_version, '4.0', '<' ) ) {
        add_action( 'admin_notices', create_function( '', "echo '<div class=\"error\"><p>".__('Plugin Name requires WordPress 4.0 to function properly. Please upgrade WordPress or deactivate Plugin Name.', 'plugin-name') ."</p></div>';" ) );

    Although, if you’re requiring a specific WordPress version, then you’re more likely to be requiring a specific function instead, in which you should check for that specific function as in the first example.

    If you want to be complicated about it, you can indeed do so. Here’s code for a plugin which will deactivate itself if the PHP version requirement is not met:

    if ( version_compare( PHP_VERSION, '5.4', '<' ) ) {
        add_action( 'admin_notices', create_function( '', "
            echo '<div class=\"error\"><p>".__('Plugin Name requires PHP 5.4 to function properly. Please upgrade PHP. The Plugin has been auto-deactivated.', 'plugin-name') ."</p></div>'; 
            if ( isset( $_GET['activate'] ) ) 
                unset( $_GET['activate'] );
            " ) );
        add_action( 'admin_init', 'pluginname_deactivate_self' );
        function pluginname_deactivate_self() {
            deactivate_plugins( plugin_basename( __FILE__ ) );
    } else {
        include 'rest-of-plugin.php';

    The reason for the unset of $_GET[‘activate’] here is so that the normal plugin activation process will not show the normal activation message, showing the plugin’s message only.

    These are not the only ways to perform a check like this, however they should be enough to get you started. Remember: Make things obvious to your users what the problem is, so they can understand the situation and take action.

  • Ipstenu (Mika Epstein) 3:41 am on May 7, 2015 Permalink |  

    Genericons Example File is Unsafe 

    If you use Genericons in your plugin, please exclude the example.html (which is no longer included in the Genericons package itself).

    The Genericons icon font package, which is used in a number of popular themes and plugins, contained an HTML file vulnerable to a cross-site scripting attack. All affected themes and plugins hosted on WordPress.org (including the Twenty Fifteen default theme) have been updated today by the WordPress security team to address this issue by removing this nonessential file. To help protect other Genericons usage, WordPress 4.2.2 proactively scans the wp-content directory for this HTML file and removes it. Reported by Robert Abela of Netsparker.

    See the full release notes: https://wordpress.org/news/2015/05/wordpress-4-2-2/

  • Ipstenu (Mika Epstein) 6:00 am on May 4, 2015 Permalink |
    Tags: ,   

    Reporting Plugin Issues 

    Note: I’ll be using Hello Dolly as my example ‘bad’ plugin for this post. It’s fine and not (to my knowledge) vulnerable.

    There are a few reasons people report plugins but the main two are as follows:

    • Guideline violations
    • Security vulnerabilities

    If you report a plugin, you can make everyone’s life easier if you do the following:

    Verify that it’s still applicable

    Before you do anything, check if the exploit is on the latest version of the code or not. If it’s not, we may not do anything about it, depending on how popular the plugin is.

    Use a good subject line

    “Plugin Vulnerability” is actually not good at all. “Plugin Vulnerability in Hello Dolly – 0 Day” is great.

    Send it in plain text

    SupportPress is a simple creature. It doesn’t like your fancy fonts and inline images. Attachments are fine, but we cannot read your ‘Replies in-line in red’ so just keep it simple.

    Link to the plugin


    Yes, it’s that easy. Put the URL on it’s own line, no punctuation around it, for maximum compatibility. With over 35k plugins, and a lot with similar names, don’t assume, link.

    If the plugin is not hosted on WordPress.org, I’m sorry, but there’s nothing we can do, so please don’t bother reporting it to us. We have no power there.

    Explain the problem succinctly

    Keep it simple.

    “Hello Dolly has an XSS vulnerability” or “The Author of Hello Dolly is calling people names in the forums” or “Hello Dolly puts a link back to casino sites in your footer.”

    Think of your intro like a tweet. Boil it down to the absolutely basic ‘this is what’s wrong.’

    Keep the details clear

    If someone’s acting up in the forums, link to the forum threads.

    If you know that on line 53, the plugin has a vulnerability (or a link back to that casino site), then you can actually link right to that line: https://plugins.trac.wordpress.org/browser/hello-dolly/tags/1.6/hello.php#L53

    We love that. If you don’t have that line, it’s okay. Tell us exactly what you see. “When I activate the plugin using theme X, I see a link to a casino site by my ‘powered by WordPress’ link.” Perfect. Now we know where to look when we test.

    Show us how to exploit it

    Don’t ask us ‘Can I send you an exploit?’ Just send us all the information. If the exploit’s already up online, like on Secunia, link us to it.

    If you know exactly how to exploit it, tell us with a walk through. If the walkthrough involves a lot of weird code, you may want to consider using a PDF.

    We’re going to take that information and, often, pass it on directly to the developers.

    Tell us if you want them to have your contact info

    We default to not passing it on, out of privacy, so “If the developer needs more help, I can be reached at…” is nice. Even “You can give the developer my information so they can credit me…”

    We’re probably not going to follow up with you

    We love the report, we review them, but we’re not going to loop you back in and tell you everything that’s going on for one very simple reason. We don’t have the time. If you told us to give the dev your contact info, then we did, but we don’t have any way to promise they will, and we don’t have the time to play middle management.

    Emailing us over and over asking for status gets your emails deleted. It’s not personal, it’s seriously a time issue. We’re nothing more than gatekeepers, we are not a security company and we’re not equipped for keeping everyone up to date. We don’t have an administrative assistant to handle that. We work with the developer to fix the issue and we work with the .org team to see if we need to force update the plugin, and that takes a lot of time.

    We don’t do bounties

    This is a little interesting but basically we’re not going to pay you. A lot of people ask for ‘credit’ so they can ‘earn’ a bounty, and that’s cool, but we’re not going to report that for you. Generally if you say you want a bounty, we give your info to the plugin dev, though, so they do know you’re interested.

    How do you report?

    You can report plugins by emailing plugins@wordpress.org

    That’s it :) Thanks!

    • J.D. Grimes 1:09 pm on May 4, 2015 Permalink | Log in to Reply

      Thank you for laying this out for everyone, it’s nice to have things clear. Now if we could just get this into the hands of people who are/should be reporting plugin issues… :-)

      • Chad Butler 3:55 pm on May 4, 2015 Permalink | Log in to Reply

        Awesomely descriptive! Thanks, Mika.

        I want to second J.D.’s comment – how to get this into the hands of the general public who report these things? I’m guessing they don’t follow Make threads.

        • Ipstenu (Mika Epstein) 4:01 pm on May 4, 2015 Permalink | Log in to Reply

          Man, if you guys have an idea I’d love to hear it.

          The idea of ‘Make a button!’ is not a great one since we’d just get a lot of bad reports and spam :/

          • J.D. Grimes 4:09 pm on May 4, 2015 Permalink | Log in to Reply

            What about just a link to this article or similar, “How to report vulnerabilities/violations”? Then people would have to read it to figure out how. But I guess some folks would still just scroll down to get the email address and you’d still get bad reports.

            I’ve been following https://wpvulndb.com/, and I’ve noticed that some of the researches don’t seem to know how to report the vulnerabilities to the plugins team. Maybe the folks at WPScan could help out with educating security researchers by including a note and a link to this article somewhere.

    • M Asif Rahman 4:23 pm on May 4, 2015 Permalink | Log in to Reply

      We already have button to report broken plugins. Maybe add another like “Report a plugin”. the button will lead to this post. And instead of emailing, maybe lets make a mail to form, with captcha.

    • Nile Flores 12:27 am on May 5, 2015 Permalink | Log in to Reply

      I’ll refer to this article, Mika. Thanks for putting this up. My co-mod shared it in All About WordPress on FB. :)

    • ethicalhack3r 9:05 pm on May 13, 2015 Permalink | Log in to Reply

      What incentive is there for any one who volunteers their time to email you about a plugin vulnerability to do so again if you’re not even going to acknowledge their email?

      You need to gamify this process, give them an incentive to do it again. After all, they are taking their own time to email you about the issue which helps protect *your* users.

      I’m sorry but ‘we do not have the time’ is not an excuse. If there is not enough time then not enough resources are being used for this.

      • J.D. Grimes 9:15 pm on May 13, 2015 Permalink | Log in to Reply

        Note that the email will be acknowledged in my experience. While the heading says “We’re probably not going to follow up with you”, it clarifies that to actually mean “we’re not going to loop you back in and tell you everything that’s going on.” However, the response is usually from a can (but not automated).

        • ethicalhack3r 9:22 pm on May 13, 2015 Permalink | Log in to Reply

          Maybe I miss interpreted it. I can confirm that, looking back through my emails, I have only ever not received a reply once.

          • J.D. Grimes 9:32 pm on May 13, 2015 Permalink | Log in to Reply

            But of course, it isn’t acknowledged in the sense of giving any kind of recognition to reporters, like rep points or a hall of fame mention. Maybe that was more the gist of what you were trying to get across?

            • ethicalhack3r 9:43 pm on May 13, 2015 Permalink

              Yea, that was part of what I was trying to get across. Even just building up a ‘relationship’ with the reporters by following up and saying ‘hey, thanks, we really appreciate the effort’.

              I think a another commenter touched on a submission form type idea. Most people who contact wordpress won’t have read this post. A submission form with all the necessary fields and explaining what wordpress want. I think this would increase the quality of submissions and thus waste less time.

              Full disclosure: I work on wpvulndb.com

              I think a wordpress supported version of what we are doing would improve plugin/theme security. Shine a light on vulnerabilities and credit researchers/reporters. I would be more than happy to work with WordPress in any way we can if they wanted.

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

            I can promise you we do reply. Always. Even if just to say “Thank you!”

            Normally people get a form email reply, but it’s something a human had to manually do.

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

        We ALWAYS reply to the email. Always. Even yours. I see it in our out boxes. Maybe you need to check you spam filter and make sure pluginsATwordpress.org is on the whitelist? Gmail has been particularly daft about it…

        Nope, not gamifying.

        Incentive? What’s my incentive for doing any of this? I’m not compensated by .org :) I do it because it’s the right thing to do for my community. Do it or don’t do it, we can’t make you, but we can suggest how it would best help US if you choose to. And we do greatly appreciate those who do.

  • Ipstenu (Mika Epstein) 5:04 am on April 21, 2015 Permalink |
    Tags: , testing   

    Reminder: Please Test Your Plugins With 4.2 

    WordPress 4.2 is being released this week. Are your plugins ready?

    After testing your plugins and ensuring compatibility, it only takes a few moments to change the readme “Tested up to:” value to 4.2. 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.

    In the same vein, please take the time to make sure the people listed as committers on your plugin are only the people who are actively developing the plugin.

    Finally, if the email associated with your wordpress.org plugin author’s account has an auto-reply, please for the love of peanut butter change that or put plugins@wordpress.org on a magic whitelist that doesn’t get the auto-replies. We very rarely send you out important emails, but when we do, they’re related to security or upgrades. When you give us an auto-reply, it delays things and makes our in-box insanely large.

    • Varun Sridharan 5:07 am on April 21, 2015 Permalink | Log in to Reply

      :) Thanks For The Info

    • Pär Thernström 6:25 am on April 21, 2015 Permalink | Log in to Reply

      > In the same vein, please take the time to make sure the people listed as committers on your plugin are only the people who are actively developing the plugin.

      Is that the Contributors-field, or is there any other field that I have missed in my plugins? :)

    • rahul286 7:03 am on April 21, 2015 Permalink | Log in to Reply

      > When you give us an auto-reply, it delays things and makes our in-box insanely large.

      Just wondering if outgoing emails can have reply-to header set to no-reply@wordpress.org or some mail address which is not monitored. It might save plugins@wordpress.org inbox.

    • Rami Yushuvaev 3:38 pm on May 11, 2015 Permalink | Log in to Reply

      make sure the people listed as committers on your plugin are only the people who are actively developing the plugin.

      Actually, this is not correct. If I develop plugins for brands, and I’m the only committer, I can’t remove the brand username, it’s against your policy.

      • Ipstenu (Mika Epstein) 10:44 pm on May 11, 2015 Permalink | Log in to Reply

        Not our “policy,” but that’s a different thing and it’s actually exactly what I mean.

        What Rami’s talking about is that if you make a plugin for a company (say LiveJournal hires me to make a plugin to autopost), then I really should be using a LiveJournal company account to MAKE the plugin because the company owns the trademark, not you.

        So in that example, there might be two committers.

        1) LiveJournal – The plugin owner who is responsible for all things security, guideline, etc.
        2) My Account – The person who is in charge of writing the code.

        And there, Rami, you may be the only person actively developing the plugin, but the owner is someone else.

        What we meant by that statement is that if you quit development for a plugin, you should have your name removed. Otherwise you get all the emails about all the issues, and you may not want them.

  • Gary Pendergast 5:00 pm on April 20, 2015 Permalink |

    Fixing add_query_arg() and remove_query_arg() usage 

    Background: Due to a now-fixed ambiguity in the documentation for the add_query_arg() and remove_query_arg() functions, many plugins were using them incorrectly, allowing for potential XSS attack vectors in their code.

    Both add_query_arg() and remove_query_arg() have an optional argument to define the base query string to use. If this argument is undefined, it will use $_SERVER['REQUEST_URI'], which is unescaped. When printed out to a page, this could be used as an XSS attack vector.

    The easiest way to fix this in your plugin is to escape the output of add_query_arg() and remove_query_arg(). When it’s being printed to a page (for example as a link), you should use esc_url(). When it’s being used in HTTP headers or as part of a HTTP request (for example, as part of a location redirect header or in a wp_remote_get() call), you should use esc_url_raw().

    Edit by Ipstenu: Also read Sucuri’s reasonable disclosure on the matter. Many plugins have been patched and auto-updated in a massive coordinated effort to stem this one before it gets nasty.

    • Ipstenu (Mika Epstein) 5:15 pm on April 20, 2015 Permalink | Log in to Reply

      Edited: Also read Sucuri’s reasonable disclosure on the matter here: https://blog.sucuri.net/2015/04/security-advisory-xss-vulnerability-affecting-multiple-wordpress-plugins.html

      Many plugins have been patched and auto-updated in a massive coordinated effort to stem this one before it gets nasty. Thanks @pento and everyone else who was in there working on this. You all make WP awesome.

    • Pau Iglesias 5:53 pm on April 20, 2015 Permalink | Log in to Reply

      Hi, a question, wp_safe_redirect argument need esc_url when the URL value comes from add_query_arg o remove_query_arg?

      • Alex Mills (Viper007Bond) 8:03 pm on April 20, 2015 Permalink | Log in to Reply

        Always, always use esc_url() or esc_url_raw(). There’s just zero reason not to.

        • Pau Iglesias 7:52 am on April 21, 2015 Permalink | Log in to Reply

          Thanks Alex, beside this, I think it would be right to add esc_url natively to add_query_arg function in next WordPress version.

      • Samuel Wood (Otto) 11:42 pm on April 20, 2015 Permalink | Log in to Reply

        Yes, if you’re using wp_safe_redirect with a value obtained from one of the query_arg functions, then you should pass it through esc_url_raw first. The reason to use the raw version is because a redirect is essentially sending a Location: header.

        • Pau Iglesias 7:48 am on April 21, 2015 Permalink | Log in to Reply

          Ok, I’ve been inspecting the code and esc_url_raw is intented to use to avoid esc_url escapes ampersand and single quotes, necessary to work with Location URL’s, I understand now, thanks Samuel.

    • Tomas Mackevicius 10:51 pm on April 20, 2015 Permalink | Log in to Reply

      Does it apply also for themes? I see that Twenty Fifteen is using it in functions.php:

      if ( $fonts ) {
      $fonts_url = add_query_arg( array(
      'family' => urlencode( implode( '|', $fonts ) ),
      'subset' => urlencode( $subsets ),
      ), '//fonts.googleapis.com/css' );

      • Samuel Wood (Otto) 11:46 pm on April 20, 2015 Permalink | Log in to Reply

        It applies to everything, however, note that the returned value is only potentially unsafe when you’re not passing a URL (the second parameter) to the the add_query_arg function.

        If you don’t pass a URL to the function, then it uses $_SERVER[‘REQUEST_URI’] instead. That’s the potential problem, because that URL originally comes from the web browser. If you’re passing in your own URL, like ‘//fonts.googleapis.com/css’, then there’s no data being used which comes from the browser, and so the result will be safe.

        You can, and probably should, use escaping functions anyway, just as a good practice. But it’s a very specific type of use-case that is affected here, one which was not obvious from the documentation of those functions.

      • SimonRWaters 10:21 am on April 21, 2015 Permalink | Log in to Reply

        As Samuel says this usage looks safe.

        However tweaking URLs for this kind of XSS issue is done by all good web security tools.

        We used Burp Suite to find a couple of these issues in common plugins (WP_Supercache and Simple Page Ordering).

        You may want to run such a tool over your plugins, especially if you handle a lot of user input, or do clever stuff with URLs. I found a common case of this was people making “tabbed” interfaces, probably cut and paste propagation.

        Also any plugin exposing functionality to roles below editor should make sure those roles can’t inject JavaScript that will be run by editor/admin.

        The most obvious attacks against these weaknesses are caught by XSS auditors in Chrome and IE, but Firefox doesn’t have such an auditor, and they aren’t foolproof by any means.

    • _smartik_ 7:50 pm on April 21, 2015 Permalink | Log in to Reply

      To fix this in my plugins quick and easy I will simply replace the function names with with custom functions.
      Here is how I did it: http://smartik.ws/2015/04/safe-add_query_var-and-remove_query_var/

      Hope this helps.

    • modifiedcontent 5:13 pm on April 22, 2015 Permalink | Log in to Reply

      How can I fix this in plugins that are no longer maintained/updated and custom theme code?

      I tried _smartik’s solution, but it only caused more errors – and then notices he is targeting the wrong functions anyway, ‘var’ instead of ‘arg’

      Could someone please give a ‘for dummies’ explanation how to replace this?

      FeedWordPress has this for example:

      " wp_redirect( add_query_arg( array('zapped' => 1, 'ids' => $post_id), $sendback ) ); "

      How do I ‘escape the output of add_query_arg() and remove_query_arg()’?

      • _smartik_ 10:57 am on April 23, 2015 Permalink | Log in to Reply

        Try esc_url($sendback) or if this still not works esc_url_raw($sendback).
        As for the link. Sorry I miswritten the function names.

    • beda69 7:04 pm on April 29, 2015 Permalink | Log in to Reply

      I am a noob but concerned

      REDUX is using this:

      <a class="nav-tab "
      href=" 'redux-about' ), 'tools.php' ) ) ); ?>">

      at least 6 times.

      since the second argument here is tools.php, no need to escape that, right?

      • beda69 7:06 pm on April 29, 2015 Permalink | Log in to Reply

        sorry, code got cut off

        <a class="nav-tab "
        href=" 'redux-about' ), 'tools.php' ) ) ); ?>">

        main issue:

        echo esc_url( admin_url( add_query_arg( array( 'page' => 'redux-about' ), 'tools.php' ) ) );

  • Ipstenu (Mika Epstein) 5:50 pm on April 14, 2015 Permalink |
    Tags: js,   

    Isotope 2.2 And Up is GPL Compatible 

    For a long time, the Isotope jquery library has had a commercial license that made it not really compatible with the GPL.

    Isotope v2.2.0 has shipped with revised licensing model that is GPLv3 by default. Purchasing a commercial license allows use outside of the GPL, under the Commercial License terms, without causing conflicts. You can read details at: http://isotope.metafizzy.co/license.html

    You can see the whole history here: https://github.com/metafizzy/isotope/issues/800

    The tl;dr is this: If you’re using Isotope 2.2 and up in your plugin, it’s permitted in the plugin repository but you need to license YOUR plugin as GPLv3.

  • Dion Hulse 3:19 am on March 14, 2015 Permalink |

    Automatic Plugin Security Updates 

    The WordPress.org security and plugin review teams have recently been working together to push automatic security updates for plugins to fix critical vulnerabilities. These updates are supported by WordPress 3.7+.

    Andrew Nacin, a fellow lead developer of WordPress who helped write this post, wrote this after WordPress 3.7 was released:

    “The automatic updater also supports themes and plugins on an opt-in basis. And by default, translations (for themes, plugins, and eventually core) are updated automatically. At some point in the future, the WordPress.org plugin security team will be able to suggest that installs automatically update malicious or dangerously insecure plugins. That’s a huge win for a safer web.”

    Some have interpreted this as the end-user is required to opt-in, but it’s always been the case that it could be opt-in by either the site administrator, or by the WordPress.org security team if we deemed an issue severe enough to warrant it.

    Back in April of 2014, the WordPress.org security team was contacted by Automattic with the details of a security issue affecting Jetpack, looking for help to get the update out to affected users as fast as possible (you can read more about that release over on the Jetpack Blog).

    The team ultimately decided that leveraging our ability to issue a background update was the best option for the security of any WordPress site running the plugin. This decision was not made lightly, as it was the first time we would use the functionality.

    A situation where we would have used automatic plugin updates was the security incident in July of 2011 where accounts of three plugin authors were breached and malicious updates were released. We were able to confirm that no other plugins were affected, as a precaution we reset the passwords of all WordPress.org users, but tens of thousands of sites were updated to a malicious version during a narrow window.

    Unfortunately we weren’t so lucky back then, as we didn’t have automatic updates available to us. Thankfully, the malicious updates were detected quickly. But if a plugin author’s account is ever compromised again in the future, we’ll be able to remove the malicious update, and then push a security update for any site affected ASAP.

    Since WordPress 3.7 was released, many sites have used the plugin automatic updates functionality, either by opting in directly through filters, or by using one of the many remote management services for WordPress that are available. We’ve had very few bug reports from those early users of the automatic plugin update functionality.

    What is the process for the security team to push an update for a plugin?

    The WordPress.org security team has only recently started to push more of these updates, only a handful of plugins have received the treatment, with vulnerability severity ranging from major to critical, affecting anywhere from 10,000 active installs to more than a million (Such as the WordPress SEO plugin this past week).

    The process of approving a plugin for an automatic update, and rolling it out to WordPress users, is highly manual. The security team reviews all code changes in the release, verifies the issue and the fix, and confirms the plugin is safe to trigger an update. Rolling out an automatic update requires modification and deployment of the API code. This is the same standard and process for a core security release.

    Because the process of pushing these updates is relatively recent, we haven’t previously formulated any guidelines as to when these pushes happen. We’re still iterating on them, but the current criteria we take into consideration for a security push is a simple list:

    1. Has the security team been made aware of the issue?
    2. How severe is the issue? What impact would it have on the security of a WordPress install, and the greater internet?
    3. Is the fix for the issue self-contained or does it add significant extra superfluous code?
    4. If multiple branches of the plugin are affected, has a release per branch been prepared?
    5. Can the update be safely installed automatically?

    These requirements are defined in a way that anyone should be able to tick each box. (If a plugin author needs help, we’ll help them to make that happen.)

    The first criterion — making the security team aware of the issue — is critical. Since it’s a tightly controlled process, the WordPress security team needs to be notified as early as possible. Letting us know is as simple as emailing us at plugins@wordpress.org with the details. If you’re not the plugin author, we’ll put you in touch with the plugin author and help coordinate the fix.

    We’ll work with the plugin author (and the reporter, if different) to study the vulnerability and its exact exposure, verify the proposed fix, and determine what versions will be released and when.

    As with WordPress core security releases, we prefer to see plugin releases which fix only the security issue, with minimal code changes and with no unrelated changes. It allows us to review the changes quickly and to be far more confident in them.

    If a plugin has a security vulnerability in versions 2.0–2.1.1, and 2.1 introduced several new features but 2.1.1 only fixed a few minor bugs, we’d enable an automatic update for 2.1.x to 2.1.2 but not for 2.0.x to 2.1.2. If a significant amount of installs still used 2.0, we’d ask for a 2.0.x release to be made, which 2.0.x users would be updated to, securing their installations, but without significantly changing the plugin they run. (For Jetpack’s release, release packages were generated from 11 different branches.)

    We want code changes to be minimal. The plugin shouldn’t require additional assistance during the update process in the form of user interaction or an upgrade routine — we want the process to “just work” every time.

    Millions have received automatic updates for security releases of WordPress core. We want automatic plugin updates to be as safe, and as trusted.

    We hope this clarifies why and when we’ll push automatic plugin security releases. It isn’t a decision we make lightly. The WordPress.org security and plugins teams only want to make the web a safer place for you and your visitors.



    Q: Why did plugin A get a automatic update, but plugin B didn’t?

    It’s not bias from WordPress.org, it’s just a throwback to the manual process we’ve been using. If we’re alerted to an issue, we’ll work to handle it. If we find out several days later, the window of opportunity to get the fix rolled out has usually passed and it won’t be as effective.

    If any plugin authors reading this have recently issued a security update and would like us to consider pushing an automatic update for the remaining users, please get in touch with us and we’ll do whatever we can to help.

    Q: I keep my plugins updated already and don’t wish to have plugin security updates pushed automatically. How can I disable them?

    There are several options to disable this functionality. The previous article for disabling core automatic updates applies here. Anything that disables all automatic update functionality will prevent plugin updates.
    If you only wish to disable plugin updates, whether for all plugins or a single plugin, you can do so with a single filter call. See this Codex article for more.

    Q: If I discover a security issue in my plugin, what should I do?

    Email plugins@wordpress.org to seek support from us. We’re here to help you. You should start working on a fix for the issue, and share a patch of the changes for review before you release it if you want us to review the change or if you think an automatic update could be needed.

    Q: Will you ever push an automatic theme update?

    One day, perhaps — but not until we can do this safely. This is a complicated problem to solve. We don’t currently have a way to verify whether a theme was edited to customize a site. We never want an update to break a site or lose customizations.

    You can always enable automatic theme updates using the filters outlined in this Codex article. Also, the theme review team catches most issues long before the theme is available for download, making theme updates far less likely to be needed.

    Q: How can I get involved with the plugins review team?

    As the plugins team deals with very sensitive issues, it’s a small group of well-known, highly trusted community members. It’s grinding work with a seemingly never-ending queue. If you’re interested, email plugins@wordpress.org.

    Q: How can the WordPress security team trigger a background update for a plugin?

    The auto_update_plugin filter is run on a flag present in the plugins update API response. By default, the flag is false, but it can be specifically enabled for a plugin. Core and translation background updates use the exact same mechanism, the only difference being their API responses have the flag enabled by default.

    • Ahmad Awais 7:27 pm on March 14, 2015 Permalink | Log in to Reply

      Hey Dion,

      I think it is a great step forward in ref to web security and it might keep WordPress from earning a bad name due to such hacks.

      That said.

      It’s great to find out that plugin review team will be closely working with us (plugin authors) to troubleshoot such situations.

    • Rafael Ehlers 7:34 pm on March 14, 2015 Permalink | Log in to Reply

      Thanks for this post, Dion.

      Here’s a *personal* tip to Plugin authors: if you ever get contacted by a “security company”, that is notifying you about a security breach on your code. As soon as you fix the code, talk to the security team at wordpress.org FIRST. Then if your fixed code is approved by the .org team to be on an automatic update, feel free to reply back to the “security company” mentioning that your code is fixed. Otherwise they’ll disclose it on the same day as you push your new code to the repo. And your users won’t have enough time to be notified about the fix to update. Trust me, *hackers/crackers* are faster to exploit that breach on your users website than they can update your plugin. That’s because we still don’t have a clear policy on the WordPress community about the amount of time a plugin author have to work, before the breach goes public. And that’s where the problem is.

    • Stephen Edgar 2:11 am on March 15, 2015 Permalink | Log in to Reply

      Thinking out loud…

      If an install is using v2.1.1 and a bug fix v2.1.2 has been previously released and now a security release v2.1.3 is about to be deployed, will sites running both v2.1.1 and v2.1.2 be updated to v2.1.3?

      Presumably this would need reviewing on a case by case basis but I think worth thinking about how this may affect your plugin nonetheless.

      • Jon Brown 5:40 pm on March 15, 2015 Permalink | Log in to Reply

        I was wondering about something along these lines too. Can these auto-updates only target certain version numbers?

        If 2.1 was secure, but 2.2 introduced a vulnerability that went unfixed through version 3.0. Can updates be forced only on 2.2-3.0 installs? or would the secure 2.1 instances get updated as well? (For reference this was an issue with TimThumb were hosts were going around warning about and updating ancient but secure versions of TimThumb).

        P.S. Thrilled this conversation is happening and full support clarifying the policies around this and encouraging more of it.

      • Andrew Nacin 7:14 am on March 16, 2015 Permalink | Log in to Reply

        The answer is yes. All version criteria can be determined on a case-by-case basis, however.

    • deltafactory 8:00 pm on March 15, 2015 Permalink | Log in to Reply

      What has been discussed internally as far as complex upgrade scenarios and perhaps multiple minor upgrade paths?

      For example, based on a very recent situation:

      WooCommerce patched a vulnerability in v2.3.x that also exists in v2.2.x etc. The jump to v2.3 is non-trivial for many of us who would otherwise opt in to automatic updates. Would it be possible to push an update as v2.2.12 to address the bug with minimal other changes for v2.2.x users, while v2.3.x users receive v2.3.6?

      The exact upgrade criteria and releases would be within the control of the plugin author. I’m just suggesting that there is a way for those closest to the code to determine whether the side-effects may cause more harm (to the reputation of the site owner, plugin author, WordPress, and the auto-upgrade system) than the fix.

      • Andrew Nacin 7:13 am on March 16, 2015 Permalink | Log in to Reply

        The post spent a few paragraphs on this. (Look for the word “branch”.) We’ve done this a few times, including for WordPress SEO.

        The exact criteria is in the hands of the security team. The plugin author can advise, but we must consent.

    • Tom Lany 10:28 pm on March 15, 2015 Permalink | Log in to Reply

      Last week, I was working to upgrade plugins on a couple of WordPress websites. I manually updated the WordPress SEO plugin on one site. Then, I logged in to another site, thinking that I would need to complete the same upgrades. Once logged in, I saw that the WordPress SEO plugin had already been upgraded. While this is good, I was confused, as I knew I had not updated it myself, and I am not used to automatic plugin updates. Before doing some research and finding out that this update had been pushed out, I wondered if my site had been hacked.

      I did not receive an email indicating that this plugin was updated, in the way I do when maintenance releases are automatically installed. It would have been very helpful if I would have received an email notification when this plugin was updated.

      Thanks for posting about how this process works. It’s great to hear about the commitment the security team has to keeping WordPress installations secure.

      • Dion Hulse 6:31 am on March 17, 2015 Permalink | Log in to Reply

        It’s certainly strange that you didn’t get an email, as emails should be sent out by default. I had seen others post screenshots to Twitter of it, so it’s possible a spam filter has blocked it..

    • Derek Herman 1:48 pm on March 16, 2015 Permalink | Log in to Reply

      Could we add an admin notice that references what was automatically upgraded and why to minimize confusion for end-users?

      • Dion Hulse 6:33 am on March 17, 2015 Permalink | Log in to Reply

        I’d like to add a “Update History” to the Dashboard -> Updates page which lists what updates have occurred on a site (either manual or automatic), having an admin notice to go along with that isn’t out of the question :)

        We’ll see what the WordPress 4.3 dev cycle brings with it.

    • Soflyy 2:31 am on March 18, 2015 Permalink | Log in to Reply

      There was a massive security hole in WP All Import that we just patched. I saw this thread so I thought “Yeah, we should probably push that out as an automatic update.”

      I sent an e-mail to plugins@wordpress.org informing them of the situation. 30 minutes later Dion Hulse got back to me saying 3.2.5 looked good for an automated update, and pushed it out.

      No back and forth. No headache. Nothing complicated.

      7900+ downloads of the update today and not a single report of a problem so far.



      Plugins team, thank you so much. This is awesome.

    • programmin 4:04 pm on March 20, 2015 Permalink | Log in to Reply

      This sounds great, but do you have a specific plugin/version you can install to test the auto-upgrade process is fully working in an install? Also, does it notify the admin if the process fails?

      If it’s using the normal plugin-upgrade process it may cause breakage of the plugin if ftp fails midway, or even if some permissions were not what it expected – see https://core.trac.wordpress.org/ticket/29610#comment:3

    • Ryan Hellyer 8:22 pm on March 22, 2015 Permalink | Log in to Reply

      It would be nice if we as plugin developers could force these updates. It would be nice to keep everyone on the same code base.

      • Rene Hermenau 10:31 am on March 23, 2015 Permalink | Log in to Reply

        I understand the reason for it, but this is a terrible idea and should better be done like it currently is – by the website owner of his own responsibility. User would hate you and immediately remove your plugin if a forced update should break their wordpress installation. It also allows malicious plugin updates if a plugin developer decides to switch to the dark side of the force.

        • FolioVision 12:44 pm on June 27, 2015 Permalink | Log in to Reply

          I second Rene’s opinion. Not breaking publishers’ websites should be the priority of plugin developers.

          And as Rene notes, allowing developers to force non-vetted updates offers far too much opportunity for security hacks. I’m concerned that even the WordPress.org capability of pushing out updates is fairly easily exploitable by state hacking teams like Tailored Access Operations or even freelance networks.

          For me, push access is crossing a red line for open source. I’m sure the WordPress.org administrators are individuals of the highest moral standing but to allow them to indiscriminately push updates on millions of websites is more power than I’d like to give any small group. My vote is that opt-out stays in. Opt out should be accessible in the front end admin GUI..

    • programmin 3:34 am on April 7, 2015 Permalink | Log in to Reply

      As I noted earlier, I don’t know how to test this auto-update-plugin feature. It’s super easy to test the WP security upgrade process – just install WP 4.0.0, or 3.9.0 for example, clear transient entries from db. I don’t see how I can test the effects of auto plugin upgrading though. Any thoughts?

    • nationalsecurityguard 11:14 am on April 28, 2015 Permalink | Log in to Reply

      A situation where we would have used automatic plugin updates was the security guards incident in July of 2011 where accounts of three plugin authors were breached and malicious updates were released. We were able to confirm that no other plugins were affected, as a precaution we reset the passwords of all WordPress.org users, but tens of thousands of sites were updated to a malicious version during a narrow window.

  • Ipstenu (Mika Epstein) 7:25 pm on February 27, 2015 Permalink |
    Tags: , ratings, , reviews   

    Ratings Rebuilt 

    Did your ratings suddenly change dramatically? Hopefully not, but if they did, it’s because the ratings for all plugins were recently reset and rebuilt earlier this week. All ratings now correspond exactly with existing, non-deleted, reviews.

    As Otto put it:

    Back when we launched the review system 2.5 years ago, we tied ratings to reviews. However, up until that point, we had existing ratings in the system. At the time, some argued that the ratings should be wiped and everybody start fresh. I argued for the opposite, that we should leave the existing ratings in place until such time as we had enough reviews in the system to build up a good body of ratings.

    That time has finally come. What you see now is the ratings that correspond to your reviews. The data comes directly from the reviews themselves, and is accurate. Any ratings previously left over from the pre-review world are no longer available.

    Additionally, the ratings now will accurately reflect the actions of the moderation team. If a review is deleted for whatever reason, then the associated rating for it will not be reflected in the results.

    Please keep in mind, this means that all of the people who thought making sockpuppets to spam the reviews with 5-stars on their own plugins (or 1-stars on their competitors) have had the biggest swings. It should go without saying that you should never leave multiple reviews on your own product (we’re pretty sure you like it 😉 ) and you should never attempt to hide behind proxies and fake accounts to leave reviews. Be honest. It works out better.

    • Drew Jaynes 11:11 pm on February 27, 2015 Permalink | Log in to Reply

      Awesome! Thanks for the update @ipstenu :)

    • jeangalea 3:27 am on February 28, 2015 Permalink | Log in to Reply

      These changes are very welcome, thanks! I also notice that there is now an estimate of the number of installs on the main page of every plugin, rather than the amount of times it has been downloaded. How is that figure being calculated? I’d like to know how accurate it is.

    • Varun Sridharan 8:07 am on February 28, 2015 Permalink | Log in to Reply

      Awesome!.. thanks for good update .. @ipstenu

    • WPSecureOps 11:40 am on February 28, 2015 Permalink | Log in to Reply

      Oops, we’ve some weird error on our plugin’s stats page:
      “Cannot read property ‘title’ of undefined×”

      Any ideas what can be causing that?

      • WPSecureOps 11:41 am on February 28, 2015 Permalink | Log in to Reply

        In case that this is helpful: Chrome Version 40.0.2214.111 (64-bit) (OSX)

      • Samuel Wood (Otto) 5:31 pm on February 28, 2015 Permalink | Log in to Reply

        This has nothing to do with the ratings, as the stats are a separate change still being worked on. However, the people in the know about that have been notified of the issue and will look at it soon. :)

        • WPSecureOps 5:30 pm on March 1, 2015 Permalink | Log in to Reply

          At least, i’m happy that I was able to help to report another problem then :)

          Good luck with the new stats, they look awesome, especially this new version specific bar!

    • Varun Sridharan 1:58 am on March 1, 2015 Permalink | Log in to Reply

      Can i please know how do you calculate `Active Installs: Less than 10`. because
      https://wordpress.org/plugins/wpsecureops-easy-firewall/ = is used by more that 10 live sites. but in that status its only less than 10 ??

      • Ipstenu (Mika Epstein) 2:23 am on March 1, 2015 Permalink | Log in to Reply

        That code isn’t complete yet, which Otto said in the post above. Obviously there’s an issue, since the graph isn’t even showing. Don’t spend your time worrying about this yet, we’ll post and explain it when it’s done.

        Now if you have a question about the RATINGS, please let us know. That’s done and that’s why we posted here :)

      • WPSecureOps 5:33 pm on March 1, 2015 Permalink | Log in to Reply

        You are using our plugin on more than 10 live sites?!

        WOW! We are really happy to hear that !!!!

        If you have any feedback/suggestions/need of help or simply want to say “Hi!”, don’t hesitate to ping us at support@wpsecureops.com :)

        PS: Sorry for going a bit off topic, but …. :)

    • Joachim Jensen (Intox Studio) 5:09 pm on March 1, 2015 Permalink | Log in to Reply

      I wondered why the total number went down for Content Aware Sidebars, but the average rating didn’t change. This “cleanup” is appreciated very much!
      I’ve noticed a few plugins with very questionable reviews though, and those have not been removed? I won’t call out anyone, but I’ll be glad to give the info to @ipstenu so you can check it out?

    • Chad Butler 10:15 pm on March 2, 2015 Permalink | Log in to Reply

      Thanks for the update Mika. I am really glad to see this change implemented as it will improve the usefulness of the rating system.

    • Ajay 12:43 pm on March 6, 2015 Permalink | Log in to Reply

      Mika, this cleanup is definitely a good one. Helped improve ratings on most of my plugins. However, there remains one issue that might be worth considering. Some plugins have very few reviews. Shouldn’t there be a threshold post which you start displaying ratings? e.g. maybe 10 reviews/ratings?

  • Ipstenu (Mika Epstein) 4:47 pm on February 26, 2015 Permalink |
    Tags: ,   

    Getting Support Notifications For Your Plugin 

    When you have a plugin, it’s important that you get notified when people have support questions. We have a way for you to keep up to date on these things and have since the Great Plugin Refresh of 2012. But for those of you who missed the news or need a refresher, here we go.

    All Plugins

    We’ve always had a couple convenience views of plugin-committers and plugin-contributors, and these are still there as well. Committers are managed in on the Admin tab (i.e. people who have access to commit code via SVN), while contributors are taken from readme.txt (which is why it’s important for you to use the proper WPORG forum ID, capitalization and all).

    Example URLS:

    Your username is case sensitive. Otto42 will work, otto42 will not. Not sure what yours is? Go to https://wordpress.org/support/profile/ (yes, that works for everyone) and look at the header:

    Example of Otto's profile, his name is capitalized

    The name in the grey header is capitalized, thus he must use a capital_O_dangit.

    Otto fixed this, lowercase works, still, check your login name because I know some of you have weird spaces and stuff

    Since anyone can add you as a plugin contributor, I recommend following plugin-committer.

    The RSS URLs for this look like https://wordpress.org/support/rss/view/plugin-committer/Otto42

    At this time, we don’t have email for this.

    Per Plugin

    Every single plugin allows you to follow it by email. Go to the Support Page for your plugin, scroll down to the bottom, and you’ll see this:

    Example of Email/RSS links

    RSS and email. Done. Even if there are no posts you can register for those emails, so make that a part of your workflow.

    • Lester Chan 4:59 pm on February 26, 2015 Permalink | Log in to Reply

      Thanks for this! It is a #TIL for me!

    • Chad Butler 5:16 pm on February 26, 2015 Permalink | Log in to Reply

      Great insight! Thanks for posting it. I was never aware of the “convenience” views before.

    • danieliser 5:36 pm on February 26, 2015 Permalink | Log in to Reply

      The one thing that is missing and I would desperately love to see is a new view for unresolved issues only. Would make sorting through hundreds of tickets much easier.

    • Samuel Wood (Otto) 5:44 pm on February 26, 2015 Permalink | Log in to Reply

      You know, if you would email me before writing these things, then I could go in and fix the bugs in them before you finish writing them. 😉

      I’ve just made two important corrections to this code:

      1. It no longer uses your login name. It uses your URL slug (aka “nicename” for those who know what that means). This would be the same as in the URL of your profiles page.

      So, my profiles page is https://profiles.wordpress.org/otto42 . This means that my feed would be https://wordpress.org/support/view/plugin-committer/otto42 .

      2. Because of this, the case-sensitivity is now gone. Or rather, it will redirect you to the lowercase URL instead. No more case-sensitive BS for us, not when we can avoid it.

      The associated RSS feed should also no longer be case sensitive.

    • Paul de Wouters 8:20 am on February 27, 2015 Permalink | Log in to Reply

      We have the RSS feed trigger a Slack notification with Zapier or IFTTT, which is handy.

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