Make WordPress Plugins

Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

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

  • Ipstenu (Mika Epstein) 9:14 pm on January 23, 2015 Permalink |
    Tags: ,   

    It's Not You – The repo cache is very sticky right now 

    FYI: This should be resolved now

    So you made an update recently and it’s stuck on the old version, but the downloads are right for your new release?

    We know.

    It will update, eventually. We’ve made some recent changes to everything and updates are running a little slower to sync and flush the cache. We’re aware of the delays and kicking the gerbils running the servers to make it faster.

    You should refrain from making multiple updates to ‘fix’ it right now, though. It won’t help.

  • Ipstenu (Mika Epstein) 9:47 pm on November 3, 2014 Permalink
    Tags: community summit, status,   

    Post Summit Status 

    The number one question asked at the summit of me was “Can I join the plugin review team?” I told everyone “Follow make/plugins and I’ll post there by [last] Friday.”

    Sorry about the delay, we had coordination issues which ironically is why the current answer is “No, we’re not adding anyone new to the review team.”

    State of Things

    The way the review of new submissions is sorted right now, it’s a single-thread system. There is a single queue that contains all submitted plugins, and it can only be viewed by one person at a time – or we run the risk for two people reviewing a plugin at once, which can end with one rejecting and one approving simultaneously. In order to avoid this, we are constantly asking each other which of us is currently in the queue. Even then, the system is archaic and has issues. So yes, it’s entirely a technical limitation and it’s one we ARE actively addressing. We’ve all talked (in one-offs) about what we want and need, and we have it spelled out. A lot of this is because we were intentionally waiting for the inevitable bbPress 2.x upgrade, but since that’s not happening any time soon, we’re going to have to make an interim plan.

    What We Do

    But there IS a future where we will want more people to help out in various roles and it’s with that in mind I want to talk to you all about what we actually do.

    Review New Submissions

    This means we download a submission, check it for any violations against the guidelines, test it on a sandbox of our own, and make sure there isn’t anything egregiously wrong. We also have to check for licensing and trademarks, which leads to fun things like the time I rejected the Official Facebook plugin because they used a gmail email address and a dropbox URL for the zip.

    Right now, the check is 100% manual. We’re developing a Plugin Checker (like the Theme Checker) but it’s much harder since themes are pretty standard when you compare them to how crazy plugins get. We have, finally, boiled down to what we know we can auto-reject and what we need to warn/inform people about, so we’re making progress on that end.

    One thing we don’t do is put our own feelings into a plugin review. If the code is good and there’s nothing ‘morally offensive’ about it, it comes in. That’s why we have a bajillion twitter plugins. Determining what is and is not offensive is hard, though. We don’t allow things we determine to be black-hat SEO (“This plugin will improve your SEO by 1000%!”) and we don’t allow things we feel would be detrimental to the community, but we do allow things we know will offend some people. It’s a fine line.

    Handle Guideline Violations

    Every single email you send to plugins AT wordpress.org saying ‘So and So’s plugin puts in powered by links!’ has to be verified. Usually this is easy, but once you report one user, we check all of their plugins. This can take a while and it gets worse when we get a submission like “Joe’s twitter plugin emails him when installed!” Sounds easy, right? Go on and figure out how many twitter plugins that might actually refer to. I reply to those a lot and ask “WHICH plugin? Please link to the repository page.”

    What we really need is simple.

    1) A link to the plugin page (ex: wordpress.org/plugins/evil-twitter/
    2) A clear explanation as to what’s wrong (ex: The widget puts in a link for non logged in users)
    3) Optional: A link to where the evil code is (ex: https://plugins.trac.wordpress.org/browser/evil-twitter/trunk/index.php#L2 )

    With that it speeds up everything.

    Handle Security Reports

    Everything we do in the guideline violations has to be done here, but worse, we have to reproduce the bug and give suggestions/information about possibly fixing it. Why? Because not everyone actually understands why they have to sanitize, or why their plugin which we approved 4 years ago, calling wp-load.php directly, needs to remove that now. The guidelines and standards change over time, and while we don’t expect people to keep up with them 100%, when they do change, it’s a waste of time to argue with us that they changed… Which bring us to the number one thing we actually do.

    Be patient with angry people

    If you’re not good at handling support tickets or forum posts, I have news for you. You will not survive the plugin team. Getting sent the dread “Your plugin has been removed…” email is possibly the worst day for a plugin developer. It’s earned us a lot of anger from the community, from people who feel we single them out or that we specifically hate them. We don’t.

    Just because you’re the most awesome person when it comes to reverse engineering security issues and solving them doesn’t mean you’re great at explaining to people why they can’t phone home or why something that was okay 4 years ago isn’t now, or even teaching them how to fix an issue even if it’s not actually our responsibility. And yes, people absolutely lose their minds to the plugin team fairly regularly. Buy me a coffee, I’ll tell you about the guy who tried to impersonate me by sending emails ‘from me’ telling other devs their plugins were removed, because I’d closed his.

    The point here is that we really need people who either are great communicators from day one, or who are comfortable asking for help when they know someone’s gone off the rails and can’t be reasoned with by them. If you’re this guy, you’re not ready:

    Duty Calls

    So … now what?

    Well now we just want this post to get you all on the page we are. And we want you to understand that until we fix the technical issues, we can’t actually address the training people up to help out. I promise you, I’m just as riled up about not having more people on the team as you are, because right now if two of us go away for a week, we have a massive queue which is just depressing. Trust me, we’re all in agreement here. But since they won’t let me reboot the plugins directory, we’re going to have to take this seriously and careful, and I beg of you to be patient.

    And that’s what we need most of all. Be patient. Stick around here. Be understanding. Don’t nag. Seriously, that never helps. We know who’s interested, and maybe we’ll come up with some quizzes and tests to see ‘Would you approve this plugin?’ and sort folks out even more. But it’s not today, and it’s not because we don’t want more people. It’s because more people would break a broken system worse.

    And that is your state of the plugin review team at this moment.

    • Alberto Hornero 10:03 pm on November 3, 2014 Permalink

      Thank you very much for your complete explanation.

      I agree to this procedure, and please tell me if I can help you. I want to help.


    • Slava UA 10:09 pm on November 3, 2014 Permalink

      Several questions:
      1) what about using tags to gain more downloads? Like BuddyPress tag – https://wordpress.org/plugins/tags/buddypress – lots of plugins include it but give 0 functionality around BuddyPress
      2) Sometimes approved plugins just don’t work, as they use for example php short tags like <? instead of <?php.
      Codex article: https://make.wordpress.org/core/handbook/coding-standards/php/#no-shorthand-php-tags
      Guilty plugin: https://wordpress.org/support/topic/errors-everywhere-4?replies=6
      How such plugins come into the repository (reviewer overlook?) and will that be checked in future somehow?

      • Ipstenu (Mika Epstein) 10:33 pm on November 3, 2014 Permalink

        Because not everyone actually understands why a plugin which we approved 4 years ago, calling wp-load.php directly, needs to remove that now.

        The guidelines have evolved over time. We change and fix and evolve and we do not usually go back. So if no one takes the time to email plugins AT wordpress.org and tell us, we probably don’t know. Now that I do, I’ll go handle that one.

        We’re also not being overly naggy about tags at the moment, though that may change.

    • Arnan de Gans 11:03 pm on November 3, 2014 Permalink

      A plugin of mine has a php file that may be loaded directly via an AJAX request. It loads wp-load.php to get to $wpdb and some other stuff. I noticed you mentioned that’s not ok anymore? What’s the alternative, I can’t seem to find a conclusive answer.

      • Ipstenu (Mika Epstein) 11:30 pm on November 3, 2014 Permalink

        The official reply:

        ## Calling core loading files directly

        Including wp-config.php, wp-blog-header.php, wp-load.php, or pretty much any other WordPress core file that you have to call directly via an include is not a good idea and we cannot approve a plugin that does so unless it has a very good reason to load the file(s). It is prone to failure since not all WordPress installs have the exact same file structure.

        Usually plugins will include wp-config.php or wp-load.php in order to gain access to core WordPress functions, but there are much better ways to do this. It’s best if you tie your processing functions (the ones that need but don’t have access to core functions) into an action hook, such as “init” or “admin_init”.

        Please consult the Plugins API reference for more information: https://codex.wordpress.org/Plugin_API

        If you’re trying to use AJAX, please read this: https://codex.wordpress.org/AJAX_in_Plugins

        For other possibilities, or to better understand why we disallow this, read this: http://ottopress.com/2010/dont-include-wp-load-please/

        If you’re trying to use it because you need to access WordPress functions outside of WordPress, we’d actually much rather you didn’t do that at all. Your plugin should be inside WordPress, only accessible to people who are logged in and authorized, if it needs that kind of access. Your plugin’s pages should be called via the dashboard like all the other settings panels, and in that way, they’ll always have access to WordPress functions.

    • webaware 1:36 am on November 4, 2014 Permalink

      Love your work (all of you); keep the faith!

      Sounds like maybe you’re fighting with the wrong tools. I’d imagine something like HelpScout would be beneficial here — a queue of issues, reviewers who can self-assign as they pick one off the queue, canned responses, notes, reassignment / unassignment. Even hooks for magic like auto-scanning zip files perhaps. I say HelpScout but basically anything similar. Surely better than bbpress.

      Such things cost something, but what price your own time? Who pays might be an issue, I don’t know, but I’m sure sponsorship wouldn’t be hard to find. Even “reviewer pays” where the reviewers stump up the $15/month for the privilege of putting WordPress Plugin Review Team (if you see me running, try to keep up) on their T-shirts.


      • Ipstenu (Mika Epstein) 1:53 am on November 4, 2014 Permalink

        The real issue we’re facing is integration with the system, otherwise we’re right back to the same issue. Multiple people in the queue at once == disaster. Until we fix THAT, everything else is theory. We already have notes, canned replies, and actually a queue. We just have it single-threaded. We need to fix it :)

        Also we will never ever EVER ever ever consider ‘paying’ for reviews. If you see me tweet about how I’ll review faster for Smarties or Kinder Eggs, that’s just me being a goof. No. No monetization of this. EVER. That’s just the antithesis of the repositories.

        • webaware 6:04 am on November 4, 2014 Permalink

          OK, cool. Sounds like maybe you just need assignment / ownership to take something from the queue so others know to get the next available victim.

          To be clear, I wasn’t implying payment for plugin reviews, just sponsorship for a non-free system (like HelpScout). But let me know about the Smarties, OK? :)


          • Ipstenu (Mika Epstein) 2:32 pm on November 4, 2014 Permalink

            Sponsorship for anything review related starts coming across like bribery to a lot of people, even with the best intentions. “I give money/time, I should get precedence in reviews!” We don’t even review our own new plugins first!

            But yes, the ownership/assignment ability is what we’re working on.

    • Hugh Lashbrooke 4:16 am on November 4, 2014 Permalink

      Thanks for the really thorough explanation. I’ve nagged Pippin a few times about joining the plugin review team, but now that I know all this I’ll stop nagging and wait patiently :) I’m really keen to help out, so looking forward to when it becomes possible.

    • Daniel Dvorkin (MZAWeb) 12:59 pm on November 4, 2014 Permalink

      Am I the only one that went to wordpress.org/plugins/evil-twitter/ expecting to find something there? 😛

  • Ipstenu (Mika Epstein) 10:31 pm on August 21, 2014 Permalink |  

    Plugin Icons 

    In December 2011, we added header images to the top of plugin screens. In 2012 we made even more changes to the plugin directory and started supporting HiDPI images for those plugin headers as well. Then we let you put screenshots in the assets folder too.

    Continuing that grand tradition of making your plugins prettier, we’re tossing a new one into the mix. Plugin Icons.

    Plugin icons are 128 pixels square. HiDPI (retina) icons are supported at 256 pixels square. Like banners, these go into your /assets directory and can be either a PNG or JPG. So just create assets/icon-128x128.(png|jpg) and/or assets/icon-256x256.(png|jpg) and you have an icon.

    You also have another option: SVG. Vectors are perfect for icons like this, as they can be scaled to any size and the file itself is small. For an SVG file, you simply need an assets/icon.svg file.

    We may implement SVG-to-images fallbacks in core for browsers that don’t support them, so if you go the SVG route, I’d suggest also turning your SVG into a PNG. (SVG takes precedence.)

    Huzzah! Make ’em rock, folks! But don’t worry, there are fallbacks

    Read the announcement post. Enjoy.

  • Samuel Wood (Otto) 6:57 am on April 7, 2014 Permalink |
    Tags: mysql, mysqli, php, wpdb   

    MySQL in WordPress 3.9 – Implications for Plugin Authors 

    If you’re a plugin developer and you have a plugin using any of the php mysql functions directly, then you might start to see breakage in WordPress 3.9.

    See, the php mysql extension is very old. As of PHP 5.5, it’s also deprecated and will very likely not be receiving further updates.

    So starting in WordPress 3.9, if PHP 5.5 is being used, the built in WPDB class will switch to using the mysqli extension instead.

    What this means for your plugin is that if you’re using any mysql_* functions directly, and somebody tries to use your plugin on a WordPress 3.9 + PHP 5.5 system, then all your database code will no longer work properly. Since the mysql functions are no longer being used in such a case by WordPress, then there is no longer an implicit database connection available to these function calls.

    Instead of using a direct database connection, you can switch to using the global $wpdb instance of the WPDB class to access the database. @pento gives a great rundown on what functions to use as drop-in replacements on this make/core post: https://make.wordpress.org/core/2014/04/07/mysql-in-wordpress-3-9/

    Now, as this is currently limited to PHP 5.5 and up only, the amount of breakage will likely be very minor. Our stats currently show that PHP 5.5 is being used on less than 1% of installations. Nevertheless, hosts are starting to upgrade PHP versions more and more frequently. This number is thus expected to grow over the next year or two. So before your users start having broken sites, please, take the time to switch your plugins over to the WPDB based methods. This will ensure future compatibility and minimal breakage.

    WordPress will always maintain backward compatibility in its own functions, so using them ensures that you’ll be good for the forseeable future, no matter what database methods are being used internally.

    • rahul286 7:27 am on April 7, 2014 Permalink | Log in to Reply

      Glad to hear this. mysqli is much better.

      We use PHP 5.5 and mysqli on all sites. I hope WordPress site’s running PHP 5.5 and mysqli will run faster soon. :-)

  • Ipstenu (Mika Epstein) 7:24 pm on March 20, 2014 Permalink |  

    Plugin Screenshots Downloading? 

    It’s not you, it’s SVN. And you.

    The tl;dr is that the MIME Types on your images aren’t correct. Per Otto:

    On Windows, using TortoiseSVN, you can right click the screenshot file, and select the TortoiseSVN->Properties menu. There you will find the svn:mime-type property, probably incorrectly set to “application/octet-stream”. Change that to the proper mime type of “image/png” or “image/jpg” accordingly. Afterwards, commit the change.

    If you prefer command line SVN:

    svn propset svn:mime-type image/png screenshot-1.png
    svn commit

    Or similar. If somebody uses a different SVN client, look for “properties” and then the svn:mime-type property.

    Once you do that, upload the changes and go make coffee. The information will sync out, but it may take a little while.

  • Ipstenu (Mika Epstein) 10:06 pm on February 6, 2014 Permalink |  

    Clarification on Taking Over Plugins 

    Sometimes people get random emails from strangers about taking over their old plugins, and I wanted to take a moment to explain how that works.

    First of all, the plugin team does not hand out your email. If you’ve been contacted by someone, they got your email or contact information off your website or plugin code.

    When someone comes to us asking about taking over a plugin, we ask if they’ve attempted to contact the original dev first. If they have and gotten no reply (or if they can’t find a way to contact you), we’ll email you about it and give you their email so you can contact them back. It is possible that someone may just email you out of the blue asking about taking over your plugin. However. Under absolutely no circumstances should you feel like you must give up your plugin, even if it’s old and out of date.

    Your plugin is yours. We will only close it if there are security issues or guideline violations, and we will always email you about that (so remember to keep your email up to date in your forum profile!). We also will never just give away your plugin without contacting you first, and getting your approval. The only exception to this is if you’ve totally dropped off the planet, your email bounces, and your website is gone. Then we assume you’re done.

    If someone would rather close a plugin than hand it over, that’s their call and we support it. We would rather have the plugin carry on, of course, but hey, things happen. That’s why some names are ‘blocked’ from the repository, by the way. We’ve closed an older plugin.

    If you want to close your plugin email us at pluginsATwordpress.org and link us to the plugin page. But do consider giving it away too!

    • Eric Amundson 10:10 pm on February 6, 2014 Permalink | Log in to Reply


      Is there a list or wiki page where plugin authors can add their plugins to a list of those in need of new ownership?

      If not, would it be helpful to have one for people who don’t want to, or can’t, support their plugins anymore to offer them up to the community for new development and support blood before closing them down?

      • Ipstenu (Mika Epstein) 10:12 pm on February 6, 2014 Permalink | Log in to Reply

        No, and since the Wiki is editable by anyone, it wouldn’t be maintainable and verifiable easily. Generally I suggest people update their readme to say “This is no longer maintained.”

      • Alex Mills (Viper007Bond) 7:37 am on February 7, 2014 Permalink | Log in to Reply

        It’d be cool if there we could just flag our plugins in need of new management.

        EDIT: Mika’s suggestion of editing the readme to say so is probably better as it’s unlikely it’d be useful to have a list of plugins that need new ownership.

      • Cleanshooter 6:31 pm on July 1, 2014 Permalink | Log in to Reply

        This is a great idea as there are some really great plugins out there that have simply fallen into disrepair. They get copied re-coded/updated then re-released as new plugins resulting in multiple version out their doing essentially the same thing (with similar code bases) but for different versions of WordPress.

    • Ben Lobaugh (blobaugh) 10:12 pm on February 6, 2014 Permalink | Log in to Reply

      Thanks Mika! As someone who has been on both sides of this I have to say the plugin team does a great job!

      Eric- I do not think there is one on WordPress.org anywhere, but there are a couple 3rd party sites that have setup systems like that.

    • Chad Butler 10:20 pm on February 6, 2014 Permalink | Log in to Reply

      Thanks Mika! This is great clarification.

      I always assumed that the plugin team approached it the way you described, but it is good to have it said out loud.

    • Andrew Nacin 10:35 pm on February 6, 2014 Permalink | Log in to Reply

      I’d say that it’d be cool if we have a system for putting plugins up for adoption, but I think this would work fine: If a plugin author wanted to put a plugin up for adoption, I’d suggest they create a post in their plugin forum and make it “sticky”. They could also update their readme if they wanted to link to that post. Those interested could then comment.

    • Ajay 12:10 am on February 7, 2014 Permalink | Log in to Reply

      What about cases where the plugin developer has disappeared and is no longer contactable?

    • Stephen Cronin 2:49 am on February 7, 2014 Permalink | Log in to Reply


      What happens when you close a plugin? Does the plugin slug become reserved or can it be reassigned at a later date?

      If it can be re-assigned, then someone could release a plugin reusing a retired slug and anyone out there still using the original plugin would get an update notice (assuming sufficiently high version number). That could potentially be confusing / dangerous.

      I’ve always wondered about that..

      • Ipstenu (Mika Epstein) 4:06 am on February 7, 2014 Permalink | Log in to Reply

        The slug is reserved and remains so unless the owner wants to give it to someone else.

        Example of something that happened once. A plugin was closed for security issues. Dev said “meh, I’m done.” Another dev asked to take it over. Original Dev said “Sure!” We added the new Dev, but the code was required to be patched before we reopened the plugin. Everything worked out better than expected :)

      • Ajay 8:45 pm on February 8, 2014 Permalink | Log in to Reply

        I closed a few plugins since they really couldn’t be used again because the services they were integrating no longer existed. I can still see the URL with a big RED message saying it is closed.

    • Workshopshed 9:58 am on February 7, 2014 Permalink | Log in to Reply

      I had someone contact me regarding taking over a plugin I was no longer interested in maintaining as it needed significant changes to work with an API change.
      However all that seemed to happen was a banner advert was placed on it and no further changes were done.


      • Ipstenu (Mika Epstein) 4:48 pm on February 7, 2014 Permalink | Log in to Reply

        An … ad? Is not okay. I’ll take a look to see if it’s violating our guidelines. That said, I often ask that people show me what code they want to update BEFORE I give a plugin away. I gave away one that I just don’t care to work on anymore :)

    • FranceImage 2:04 pm on February 8, 2014 Permalink | Log in to Reply


      I think the repository would gain in adopting another paradigm like github.

      As it is, plugins are abandoned because the authors are demotivated; an easy way to accept code from contributors may help them keep their motivation.

      If an author neglects his project, code consumers could see if it has been forked; the forked project would gain momentum if it is more alive.

      My 2 cents

    • Todd Lahman 1:01 pm on February 11, 2014 Permalink | Log in to Reply

      This post from Mike Jolley completely sums up what needs to be done:


      I would add to this, the developers need mod permission to delete comments that are off topic. My preference would be to fully integrate with Github, adopting their system entirely. WordPress.org is outdated, and the moderators system reminds me of the IRC back in the mid 1990s when Eggdrop bots ruled the chat rooms.

    • theforgotten35 8:53 am on October 7, 2014 Permalink | Log in to Reply

      Hi Mika,
      I have installed the post notification plugin and deployed upon a 5.5 mysql database.
      There is a mysql evolution that makes the plugin installation obsolete (due to a timestamp field).
      The plugin is no longer maintained and I wondered if anyone took over its development ?
      I also wondered how the development is handled i.e. how could I update the repository (SVN) … ?

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