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

  • Samuel Sidler 10:56 pm on September 1, 2015 Permalink |
    Tags: translations   

    Plugin Translations on WordPress.org 

    Howdy plugin authors!

    In case you haven’t heard, WordPress.org will be expanding the services we provide to you, offering language packs to all plugins. This post is to outline exactly what the plan is and when your plugin will take part.

    For a bit of background, see this post on make/meta and this one on make/themes.

    Over the past few months, the meta team has been working behind the scenes to enable language packs for themes and plugins, just like the ones core has. Language packs on WordPress.org are powered by translate.wordpress.org and the polyglots team, who translate WordPress.

    As of today, all themes have been imported into translate.wordpress.org and can take advantage of language packs (see also). We chose to import themes first to work out any weirdness with translate.wordpress.org, which has never seen this many projects. There were a few bumps along the way, but language packs are now flowing for themes and we’ve added a number of improvements to translate.wordpress.org to make it the process easier for translators.

    Now, it’s time to do the same for plugins.

    The gist of plugin translations are as follows (see the FAQ below for more information):

    1. Eventually, all active plugins will be imported into translate.wordpress.org and made available for translation. However, we will import them in phases.
    2. Upon import, if you have any translations, we will import them into translate.wordpress.org. This only happens during initial import.
    3. Before importing your plugin, we will email you when your plugin is in the next “batch” of imports. You should ensure that all translations are up-to-date.
    4. If you do not wish to use language packs, you may continue to ship translations with your plugin.

    I am sure there are some questions. Let me try and address them:

    Why do I want WordPress.org managing translations for my plugin?

    WordPress.org provides translations in dozens of languages and is ever expanding as new contributors join. (There are currently 140 locales on translate.wordpress.org, but not all are active.) While you may have translated your plugin into a few languages (or none at all), there are likely more translators on WordPress.org in more languages.

    But that’s not all! Plugins in the WordPress.org directory will be able to take advantage of language packs! That means smaller download sizes for users, because plugins will no longer need to ship translations. Eventually, we also plan to give priority to localized plugins in localized directories; e.g., someone searching the Romanian plugin directory will see Romanian plugins prioritized over English-only plugins.

    A great example of what your plugin will look like in a translated directory is Akismet.

    When will you import my plugin into translate.wordpress.org?

    We will import plugins in order, by the number of active installs they have, starting with the most active installs and working down to the least active installs. You will be emailed when your plugin is in the next batch of imports. Be sure to keep translations up-to-date.

    Will you import my plugin ahead of time?

    We’re importing in stages to monitor our systems and ensure the entire site does not break. We will not import your plugin out of order.

    How do you define “active” plugins?

    Plugins are considered “active” if they have been updated in the last two years. This is the same standard that the plugin directory uses when showing plugins in the search results.

    My plugin doesn’t have any strings to translate. Does this apply to me?

    Yes! Translators have the ability to translate your plugin’s readme.txt file and even its name.

    What if my plugin already ships translations?

    Translations that are already shipped in plugins will be initially imported into translate.wordpress.org. Again: we’ll import the strings and the translations on the initial import. We won’t continue to do that because the end goal would be for plugin authors to remove the translations from their download, allowing language packs to fill the void.

    What if I don’t want language packs?

    As mentioned, you can opt out of language packs and plugin translations on WordPress.org, by shipping translations in your plugin, just as you do now.

    I currently ship translations with my plugin. How do I enable language packs?

    WordPress ships with a mechanism that gives priority to shipped translations over language packs. If you wish to take advantage of language packs, you must remove the languages from your plugin zip.

    How do I add support for translations and language packs?

    @Otto42 wrote up a great post on the topic back in 2013. (Wow, it’s been a long time!) There’s also a great page in the plugin developer handbook which walks through how to internationalize your plugin.

    Keep in mind, your plugin’s textdomain must match its slug and, as mentioned above, to fully support language packs, you’ll want to remove translations from your plugin after the import, when language packs are going out (language packs go out as soon as a translation is at 100%).

    What if I want my translators to approve translations on WordPress.org?

    Many plugins already have their own translators and will want to bring them over to translate.wordpress.org. We’ve written up a plan for working with the polyglots team to enable this. There will be some initial pain in adding new, project-specific (aka plugin-specific) translation editors, but afterwards, your translators will join a growing group of WordPress translators and help make the entire ecosystem better.

    If you have any other questions, you’re probably not the only one, so leave them in the comments below.


  • Ipstenu (Mika Epstein) 2:16 pm on August 26, 2015 Permalink |
    Tags: fork, policy   

    Forks and Copies 

    This has come up recently. What happens when someone submits a plugin that’s a copy of another?

    The tl;dr here is this: Please email us at plugins@wordpress.org if you find someone has slipped an uncredited fork or identical copy of another plugin into the repository.

    In general, we spot these before they ever get published. We rejected 10s of plugins a month for being identical copies. That said, we also approve double that for being legitimate forks.

    While the GPL and it’s compatible licenses allow for forking, we have an ‘above and beyond’ rule for hosting here, that means your plugin must be a substantial change of the original. We do not allow direct copies of other plugins to be re-listed under somebody else’s name, we allow changed forks.

    What does that mean? It’s very simple. You have to add new features, remove features, modernize, fix, clean up, or otherwise make a change to the plugin that differentiates it from the original. In rare cases, a simple clean-up will be accepted, but normally we try to get a hold of the original authors and have the fixes folded in to the original plugin. If you have a fork, we require you to retain all credit and/or copyright information.

    That’s all well and good. What happens when we miss one?

    Contact us. Email us at plugins@wordpress.org and tell us “Plugin A is a copy of Plugin B.” If both plugins are on the WordPress.org repository, provide links — there are 45k plugins in our repository, no links means it takes us an extra email or three to sort out which plugin you were talking about. Anyone can report this, though we ask you be reasonable and not accusatory. We are real humans who will read your emails. Treat us like that :)

    We’ll open up both plugins, the current versions and the originals, and run a diff between them to see what’s different. If it’s just renaming plugin functions, we’re going to close the copy. If it’s clearly a full rewrite, with moving functions to namespaces etc, we’re likely to keep both versions open. A full modernized rewrite is a legit fork. We will go back and ask them to put credits and copyright info back in, but rarely more.

    If the original plugin is NOT hosted on WordPress.org, then it’s more complicated because we need to see them to compare. This means if you, as a user, see a copy of a premium plugin, you need to ask the original developers to contact us. Why? Well, have you ever tried, as a non-paying customer, to contact some of these folks? It’s an uphill battle. It’s worse when they’re hosted on places which protect their email addresses. That’s great, we totally get why you do that, but we have no way to contact them. Many times we’ve reached out and gotten auto-replies that take weeks to get back to us with a real human.

    If you’re the original developer, email us a copy of your plugin (we promise not to steal it) and if you can, explain how you know it’s a copy and not a fork.

    But whatever you do, please, please, please, don’t take all this to the forums and post complaints that the forked plugin authors are evil or what have you. That doesn’t make for a happy community. Report things properly. Let us know. We’ll take the angry hit from them for you.

    If you’ve written a fork or a copy? Please make sure you’re really making a fork! Just slapping on your name and changing function names isn’t enough of a fork for us to host it here. We don’t want to have 100 plugins that are the same, save the credits. We want to have plugins that do different things.

    Edit: All questions about the GPL-100% rule and how it applies to WORDCAMPS needs to be asked of the https://make.wordpress.org/community/ team – All those comments are being deleted for derailing the topic here.

    • Brajesh Singh 2:37 pm on August 26, 2015 Permalink | Log in to Reply

      Thank you for the write up Mika.
      That’s some seriously great points about properly forking/reporting the shallow forks properly. It would be nice to have these points as part of the developer faq section too.

    • Rene Hermenau 2:41 pm on August 26, 2015 Permalink | Log in to Reply

      > This has come up recently.

      I follow the case you are probably approaching and had a look at both plugins so I really welcome this official statement.

      Thanks for making it clear!

      I feel vindicated to continue to publish my plugins under the GPL and on wordpress.org, Now more than ever because the WP team does not allow to have simple copies of my plugins be listed in the wp repository.

    • Dave Navarro, Jr. 2:57 pm on August 26, 2015 Permalink | Log in to Reply

      Do derivatives of plugins/themes in the repo that are NOT GPL compatible effect their eligibility to be in the repo?

      For example, I know of a plugin in the repo that is 100% GPL. However, the same author sells a forked version of his own plugin as a premium plugin and he claims copyright in the code (not GPL).

      I ask because WordPress has started banning developers from officially sanctioned WP events who do not release EVERYTHING WordPress related as 100% GPL. So I’m wondering if the same standard applies to putting free versions of premium plugins in the repo when the premium version is not compliant.

      • Pippin Williamson 3:03 pm on August 26, 2015 Permalink | Log in to Reply

        What someone does outside of the repo does not effect their eligibility to be listed in the repo as long as the code in the repo follows the guidelines and does not violate any repo regulations.

        Note: this is where it gets super tricky so don’t take this as fact or legal advice.

        WP plugins themselves cannot be non-GPL, only other items (non-derivatives of WP) included with the plugin can be non-GPL. As long as the fork does not contain any of the non-GPL components, it’s perfectly acceptable to have a fork in the repo.

        • Dave Navarro, Jr. 3:08 pm on August 26, 2015 Permalink | Log in to Reply

          Thanks Pippin, I know about the whole “cannot be non GPL” debate, which I agree with.

          I just know that Automattic is preventing developers who “claim” non GPL compliance from officially participating in WP events. So it would make sense if developers were pulling the same shenanigans with premium versions of their free plugins in the repo from similarly having WordPress allow them to participate in the repository.

          • Pippin Williamson 3:15 pm on August 26, 2015 Permalink | Log in to Reply

            The event participation issues for non-GPL products is a super sticky situation. I can’t (read won’t) say anything much there since I have no affiliation with Automattic.

        • Andrey "Rarst" Savchenko 3:30 pm on August 26, 2015 Permalink | Log in to Reply

          > WP plugins themselves cannot be non-GPL

          Official repository rules allow GPL–compatible plugins (such as MIT), which are non–GPL.

          Tangential to the question, but pet peeve when people make hard statements like this.

        • FolioVision 12:55 pm on August 27, 2015 Permalink | Log in to Reply

          Hi Pippin,

          Your statement below is a legal opinion:

          WP plugins themselves cannot be non-GPL, only other items (non-derivatives of WP) included with the plugin can be non-GPL.

          The opinion is extremely contentious. As it is not fact it should not be cited as such.


      • Casey Driscoll 6:12 pm on August 26, 2015 Permalink | Log in to Reply

        > WordPress has started banning developers from officially sanctioned WP events who do not release EVERYTHING WordPress related as 100% GPL

        [citation needed] please.

      • Ipstenu (Mika Epstein) 11:03 pm on August 26, 2015 Permalink | Log in to Reply

        https://plan.wordcamp.org/planning-details/speakers/ – Speakers have to be 100% GPL. One presumes that extends to staff as well.

        What the WordPress Foundation choses to require in order to maintain their oversight of WordCamps is their decision. Just like we have a requirement that we don’t permit a split license, or powered-by links that aren’t opt in, and so on for hosting your code here, they’re allowed to have ‘above and beyond the GPL’ requirements for what they control.

    • Lisa 3:44 pm on August 26, 2015 Permalink | Log in to Reply

      Do the non-GPL components mean graphics and CSS?

    • George Stephanis 6:29 pm on August 26, 2015 Permalink | Log in to Reply

    • Dylan Ryan 2:31 am on August 27, 2015 Permalink | Log in to Reply

      If file_A.php has WordPress related functions (imagine, add_actions) and includes file_B.php (imagine, custom PHP), which has NO WordPress functions, then could you license file_B.php as MIT and leave file_A.php as GPL? Delete this if it’s off-topic – I’ve always just been curious where the line is drawn between GPL and Non-GPL.

      • Dion Hulse 2:46 am on August 27, 2015 Permalink | Log in to Reply

        As MIT is an even more permissive license than the GPLv2 license (ie. it does not apply extra restrictions upon the codes usage) then it’s classified as an GPLv2-compatible license and as a result you can license the entire plugin as MIT and be accepted into the Plugins Directory.

        The issue is where the license applies restrictions above/beyond what what GPLv2 license does, in that case it won’t be accepted into the WordPress.org directory as the entire plugin is not GPLv2 compatible.

        You may be interested in this older post and it’s linked resources:

    • Vladimir Prelovac 9:32 am on August 27, 2015 Permalink | Log in to Reply

      Hi Mika

      This is indeed a good move.

      I am wondering what is the stance towards cases when this happened in the past.

      Let’s say there was a plugin A and plugin B forked it and entered the repo as an almost identical copy, two years ago. Now both have significantly changed. Could plugin A author still request removal of plugin B?

      • FolioVision 1:06 pm on August 27, 2015 Permalink | Log in to Reply

        Good point Vladimir. I think that the rule should be applied retroactively. Stopping code copiers/code thieves should be public policy.

        In these cases, the copycat plugins could then redirect to the original (so people don’t end up stranded).

        If the copiers want back into the repository, they’d better make substantial changes and improvements. Those caught systematically copying should face slightly higher standards than accidental clones, just as professional con men face stricter standards in court.

        • Ipstenu (Mika Epstein) 1:33 pm on August 27, 2015 Permalink | Log in to Reply

          Those caught systematically copying have all their plugins removed and get banned. It’s not happened a lot. Most people are mature about this.

        • Samuel Wood (Otto) 12:35 pm on August 28, 2015 Permalink | Log in to Reply

          The rule is absolutely not applied retroactively, and you and Vladimir need to understand what a proper “fork” is.

          A proper fork is when you take a copy of something, and modify it to suit your needs. Obviously, at first, that copy is a *copy*. So just because it started out as a copy does not mean it’s not okay. It absolutely is okay to do that, the GPL explicitly allows it. That’s the whole point of open source, to be open.

          What Mika is saying in this post is that we require forks to be *forks*. Not just copies. Even if a plugin started out as a copy, if it has undergone substantive change over time, then we will not remove it just because it started as a copy. All forks start as copies. That is the nature of forking.

          Some plugins go into the directory with nothing more than the function names changed and the credits scrubbed off. Then they never get changed again. That’s not okay, and we do not allow that. But a plugin that was copied, edited, modified in some meaningful way, that’s a legitimate fork. That’s acceptable.

          • Ipstenu (Mika Epstein) 2:36 pm on August 28, 2015 Permalink | Log in to Reply

            It would only be applied retroactively if it was something like Plugin B was always 100% copying Plugin A, and only changing function names. I can honestly tell you that’s so rare, I only think I MIGHT have once seen one…

            • Vladimir Prelovac 5:22 pm on August 28, 2015 Permalink

              There is a ‘timing’ confusion here.

              Otto you basically say that a plugin can enter the repo as a copy and you expect it to change with time or be removed.

              However what happened to LeadPages confirms a different view, one aligned with what Mika explicitly wrote:

              “In general, we spot these before they ever get published. We rejected 10s of plugins a month for being identical copies. ”

              This implies copies are not allowed to be published at all, which is consistent with the removal of leadpages plugin.

              Couple of sentences later adding:

              “We do not allow direct copies of other plugins to be re-listed under somebody else’s name, we allow changed forks.”

              Again this implies a copy would never be allowed into the repo, only a changed fork is allowed.

            • Ipstenu (Mika Epstein) 8:06 pm on August 28, 2015 Permalink

              @freediver – No there isn’t a confusion at all.

              Again this implies a copy would never be allowed into the repo, only a changed fork is allowed.

              Yes, that is 100% exactly what we’re saying.

              If you’re about to kvetch that we miss plugins, please accept our apologies. We’re sorry we missed every single copy we missed, but we don’t have a TARDIS and crossing time streams is bad, so we can’t go back and be 100% perfect every single time we do these things.

              The point of posting this was to remind you all that if you see something, there is a place to say something instead of making a stink on Twitter or your blogs. You can come to us for HELP.

            • Samuel Wood (Otto) 11:25 pm on August 28, 2015 Permalink

              > Again this implies a copy would never be allowed into the repo, only a changed fork is allowed.

              But lets say we miss that fact, and a copy does make it into the repo. That doesn’t instantly damn it forever with no hope of recovery.

              If a copy gets substantive change over time, then it is no longer a copy, it’s now a legitimate fork. Because that’s what a fork is: a copy that got modified for some purpose.

              Forks are welcome in the Plugin Directory, regardless of their origins.

      • Ipstenu (Mika Epstein) 1:32 pm on August 27, 2015 Permalink | Log in to Reply

        Plugin A can always request. What we do depends on how divergent they are.

        Edited to note of course you can ask, but we expect you to have put a measure of thought into it. Is it a COPY or a FORK? Copy bad, fork good.

        We tend to enforce that plugin B put in credit/copyright information, or at least say “Inspired by A”

        You can usually still see the bones of the original, after all, and a show of good faith goes a long way to making a happier community.

        I will note that we did have a case where a fork was a total rewrite. They moved the whole thing to Singletons, moved files around, and had ONE (yes one) function that was identical. We asked them to credit the original, and nothing more. That was a legit fork.

    • FolioVision 1:09 pm on August 27, 2015 Permalink | Log in to Reply

      Thank you for making these rules clear and explicit Mika. They are a big help to those developers making a real contribution. Sharks and scam artists are only going to become more common in the WordPress world. Not giving them breathing space in the repository is one very good step to making the WordPress world safer, fairer and more fun.

    • Ahmad Awais 1:18 pm on August 27, 2015 Permalink | Log in to Reply

      Hey, Mika!

      Thanks for posting this. As much as I love GPL and have it in my plugins/themes as the only license, I was wondering if someone could do that to me, but then when a recent plugin got removed from W.org repo, I was actually looking forward to an official response.

      Copying something, slapping one’s name on it and forking to improve and enhance the code are two different things.

    • Ipstenu (Mika Epstein) 1:28 pm on August 27, 2015 Permalink | Log in to Reply

      If you folks have questions about the WordCamp rules, please talk to the https://make.wordpress.org/community/ team – I’m nuking them here because you’re at the place where it’s off topic to the point of wasting Pippin’s and my time. We (he and I) aren’t on that team. We cannot tell you fact. Be smart. Go to the source.

    • @modemlooper 3:52 pm on August 27, 2015 Permalink | Log in to Reply

      Here’s a remark about forking and releasing to repo; I had someone who would take every one of my BuddyPress plugins and fork and re-release into the repo. Then I got a ton of support requests via email for this forked plugins. One person, who, when I said I don’t support forked versions decided to send me DEATH THREATS.

    • webdevmattcrom 4:07 pm on August 27, 2015 Permalink | Log in to Reply

      Excellent response and clarification, Mika. Thanks to all on the Plugin Team for their dilligence here. We appreciate it!

    • webdevmattcrom 4:20 pm on August 27, 2015 Permalink | Log in to Reply

      I’m curious though whether this “above and beyond” approach will be mentioned in the Plugin Guidelines so that authors are aware before submitting: https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/

      • Ipstenu (Mika Epstein) 4:41 pm on August 27, 2015 Permalink | Log in to Reply

        18. We reserve the right to alter this list in the future. We reserve the right to arbitrarily disable or remove any plugin for any reason whatsoever. Basically, this is our repository, and we will attempt to maintain a standard of conduct and code quality. We may not always succeed, but that is our goal, and we will do whatever we feel is necessary in furtherance of that goal.

        The issue with enumerating every single thing is you get a bunch of rules lawyers who will nit-pick and argue that we said it had to be significantly different, and this is because they did XYZ.

        It’s really hard to have the rule be “Don’t be a thief, a liar, a spammer, or otherwise a not cool and good person.” Because that’s really what all of this boils down to. Respect everyone. Treat everyone how you would like to be treated. Don’t be mean.

    • Dejan Markovic 1:44 pm on August 28, 2015 Permalink | Log in to Reply

      Hi I have “technical/GPL/forking” question for Mika or Pippin.

      I am currently working on a Pro version of one of my themes. Instead of re-inventing the wheel I would like to use some free plugins from WordPress.org repo (not pro versions) to fulfill my needs. For example testimonials plugin for CPT testimonials and so on. I will create my own HTML and CCS for displaying the Testimonials on the front end but on a back-end I would like to use the functionality from that plugin (take something out that I don’t need but also add some of the features that I need). I will put a GPL v2 license on that theme and on those plugins.

      Is that OK thing to do regarding WordPress.org policies? Also, I don’t want to be accused of stealing somebody’s work as I think this is a proper forking approach as I am adding:

      • my front end look,
      • my features in the back-end
      • allowing everybody to do whatever they want to do with my version/fork of that code.

      Thank you very much, your help is greatly appreciated!

    • Dejan Markovic 4:14 pm on August 28, 2015 Permalink | Log in to Reply

      Thank you Pippin and Mika!
      I will credit the original plugins and of course have their copyright present in my fork.
      Thank you so much!

  • Ipstenu (Mika Epstein) 4:03 pm on August 19, 2015 Permalink |
    Tags: guidelines, submissions   

    Plugin Submission ZIP files 

    This comes up now and then so I thought we should have a quick post about what your plugin zip should be when you submit.

    Keep in mind, if we email you and tell you we cannot download or open your zip, please don’t just say “Well it works for me!” The fact is, we’re smart people. If we cannot get the zip to open, there actually is a problem. Check the link and check the zip. Attach the zip to your email reply.

    It should be a zip file

    I know, that’s obvious, but we actually force you to send a zip for a number of reasons. I strongly urge you NOT to use anything fancy like winrar to compress it, because that can make your zip un-openable on Mac or Linux boxes. Protip? We all use Mac or Linux.

    Use a real URL

    Don’t use localhost. Don’t use your dev environment. Don’t try to upload the zip. It’s a link to where your zip is publicly accessible. No more, no less.

    Be very careful when you use ‘free’ upload sites. If they open up a dozen popups, we’re not going to risk them. We don’t like viruses.

    Speaking of…

    The link should be one that’s accessible to NON-logged in users

    Bitbucket folks, this means you, eh? If you’re using GitHub, you can link us to the zip they make UNLESS you’re including submodules. Surprise! Github’s autogenerated zips don’t include that. Drives me nuts. I know.

    Test the URL in an incognito window, just to be sure. It takes a second and you’ll see exactly what we see.

    The zip should be only the plugin

    It should be exactly what you would upload manually to WordPress to test (which you did test, right?) because that’s what we are going to do! Don’t include themes or other zips or required plugins. All of those requirements should be accounted for in your plugin by making checks and properly informing users as to what they need to do.

    By the way, please don’t nest your zips. Seriously. We see a lot of zips that have a readme.txt and then a second zip file. That means we have to open the zip, extract the other zip, check that it’s right, and then upload it.

  • Samuel Sidler 2:47 am on August 8, 2015 Permalink |
    Tags: ,   

    WordPress 4.3 Field Notes (Lots of Changes for Plugin Developers!) 

    Do you follow the make/core blog? If not, you should!

    Over on the make/core blog, we compiled all of the developer-focused changes in WordPress 4.3 in one spot. In case you don’t want to click, here’s a reprint of those changes:

    Just a week and a half left to get your plugins updated. Thanks for all your hard work!

  • Ipstenu (Mika Epstein) 8:51 pm on August 3, 2015 Permalink |
    Tags: , , core   

    4.3 Change to Plugin Dashboard Pages 

    Per #31650, there’s been a change to the way headers are processed.

    Previously we used H2 in order to create the header at the top of our pages like this:

    <div class="wrap">
        <h2><?php _e("My Cool Plugin", 'my-plugin'); ?></h2>
        <p>All my cool dashboard things</p>

    This was done because, prior to the Toolbar, WordPress put in an H1 header itself. With the change to the Toolbar quite a while ago, that was removed and it created a new problem for accessibility. In order to fix that issue the H2s were changed to H1s in core.

    This will not break your plugins.

    There is no visual difference, the styles stayed the same. Only the underlying markup has been changed.

    If you want to fix your plugins, just change that H2 to H1 and call it a day. Screenreaders will thank you.

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

    • Cx Rana 4:14 pm on August 13, 2015 Permalink | Log in to Reply

      currently i have 5/6 plugin hosted on wordpress.org
      but i didn’t got plugin developer badge in my profile…. why and how can i fixed it ?

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

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