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.

For documentation on creating a plugin, as well as all guidelines and support information, please visit developer.wordpress.org/plugins/

Currently we have neither meetings nor office hours.

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

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Ipstenu (Mika Epstein) 8:20 am on November 23, 2015 Permalink |
    Tags: reminder,   

    Your Plugin Committers Should be Your Developers 

    After we started pushing back on the auto-reply stuff, a couple plugin devs said that they used their support accounts (like support@example.com) as their committer so that they could get email updates from the forums.

    This is a terrible idea. It’s insecure and rather dangerous.

    That means the support account is the one with write access to your plugin. And that means anyone with access to your group email (or your support tool) can click on reset password, get the password, change it, and blow up your plugin. Obviously that’s a major security issue. The only people who should have write access to your plugin should be people who know how to code and are responsible and reliable and trustworthy. And remember, people can go nutters in a company of any size and seek out revenge in weird ways. Limiting the damage they can do is your responsibility.

    This also means that when we send you an email about your plugin, you may be accidentally sharing privileged information with people who have no business knowing these things. With a support account for a company of four people, it may be okay for everyone to know your plugin was pulled from the repository for a security hole. When you have a company of 300 and you use a system like ZenDesk (not to pick on them, but they are popular), now everyone knows. This may not seem like a big deal, but if one person tweets “OMG! Plugin FOO has a security hole!” then there’s a major risk that you’ve opened up the floodgates of potential hacks. Limiting the risks you put on your users is important.

    Only allow your developer account(s) to have commit access to your plugin.

    If you want one joint email-alias (wp-plugin-dev@example.com) that forwards to everyone, that’s okay, but not great. Remember, if everyone has their OWN user account, then you can easily track who pushed what change to a system. If you’re only using SVN as your version control, it’s a good idea to make sure you know who did what. If you’re using Git or Mercurial or your own SVN to track the changes, then make sure that only responsible, reliable, people have access to that dev account. Again, remember that we’re talking about access to push code to (say) a million users.

    Remember: Anyone listed as a developer has the ability to remove anyone else as a committer. So you really want to limit those users.

    Make a separate account to handle support

    Make a separate account (wp-plugin-support@example.com) that does whatever it needs to do. Then you can sign up for email alerts. Go to https://wordpress.org/support/plugin/YOUR-PLUGIN and scroll to the bottom where it says “Subscribe to Emails for this Plugin”:

    Click "Subscribe to Emails for this Plugin" when logged in.

    Click “Subscribe to Emails for this Plugin” when logged in.

    Click the link and baboom, that account gets email alerts. You can do the same for reviews at https://wordpress.org/support/view/plugin-reviews/YOUR-PLUGIN if you want to catch the inevitable ‘this review should have been a support post’ threads.

    Remember: If you sign a support account up for getting those emails, you should still disable auto-replies. Otherwise you’ll be generating a lot of unnecessary email every time someone replies to your threads and you may get caught as a spammer.

    Add your support accounts as Contributors

    Contributors are the people you list under the ‘Authors’ field on your readme. They do not have any commit access to a plugin. They can’t edit the code.

    Example: “Automattic” has an account for Jetpack. That account can be a placeholder account. It can be a support account if you want to use it in the forums. It can be marked as a Contributor in the plugin’s readme.txt in order to get special markings in the forums for replies from that account for that plugin.

    The other accounts should be individual accounts, belonging to the devs, and preferably using their company email addresses. This way, if the organization changes, an individual leaves, etc, the email address still goes to the company and the plugin can be recovered, if necessary.

    Back on Jetpack, there are over 70 people listed as ‘authors.’ They all get that happy plugin author green lozenge in their forum replies and they can officially help people without you worrying they’ll miss a semi-colon and take down 20 thousand users with a bad push of code.

    Remember: Anyone listed as an author is going to get that green lozenge. If you don’t want people representing you, credit them in the readme but remove them as an author.

  • Ipstenu (Mika Epstein) 10:33 am on November 19, 2015 Permalink |
    Tags: , libraries, timthumb   

    TimThumb EOL 

    If you’re using (or thinking of using) TimThumb in the repository, please read.

    TimThumb has reached it’s end of life. As such, we strongly recommend you stop using it in your plugins as soon as possible. It’s not supported, it’s not maintained, and that means the 130ish of you who have it are going to have a bad day if another exploit is found because we will close your plugins.

    Please note, we’re not retroactively banning it from the repository at this time, though that may change. Right now, we’re asking everyone to take the first step and find an alternative. All new plugins are being required to use something else.

    In general, please keep an eye on your third party libraries. If they’re no longer supported, look for a replacement. If they’re out of date, update your plugins. This is the best way to keep your code secure and avoid those awful emails about how we closed your plugin.

  • Ipstenu (Mika Epstein) 12:00 am on November 19, 2015 Permalink |
    Tags: ,   

    AutoReply Sucks 

    Did you know we have no auto-replies at all sent from WordPress plugins?

    Every single email, even the predefined ones, are written and picked and sent by hand. Even the one that goes out to all 22,573 user accounts with commit access to a plugin.

    But you know what happens when we send out that nice reminder to test on WordPress 4.4?

    We get a few hundred auto-replies from support systems.


    Please change the address on your WordPress.org forums account to one that does not go to an automated support system. We need to be able to communicate directly with plugin authors, and having automated responses don’t help us much.

    THIS IS A REQUIREMENT. If we continue to receive automated responses from your support system, we will have to shut down your plugin and remove it from the WordPress.org directory.

    We require that we have the ability to contact you about updates on a regular basis. If we also get automated responses, then this eats up our time, and is a problem for us.

    Please do whatever is necessary to STOP these automated responses. We would prefer that you use an email address on the forums that goes to actual people, not into a support system. Our forums send emails for all sorts of reasons, and automated responses eat up our bandwidth needlessly, since they don’t go anywhere.

    Basically it’s this: If we can’t get in touch with you, we can’t host your plugin.

    Please whitelist pluginsATwordpress.org and please exclude us from your auto-replies.

    (A quick note – A personal autoreply, like “I’m at a wedding and won’t be back until December 3rd” is not the same thing. Those are fine!)

    • Claudio Sanches 12:30 am on November 19, 2015 Permalink | Log in to Reply

      +1 for “THIS IS A REQUIREMENT. If we continue to receive automated responses from your support system, we will have to shut down your plugin and remove it from the WordPress.org directory.” :)

    • jeffmcneill 12:33 am on November 19, 2015 Permalink | Log in to Reply


    • Zack Katz 12:54 am on November 19, 2015 Permalink | Log in to Reply

      Serious question: how can I change my profile email? I don’t see it in https://profiles.wordpress.org/%5Busername%5D/profile/edit/group/1/

    • Gustavo Bordoni 1:29 am on November 19, 2015 Permalink | Log in to Reply

      I love this +1 requirement!

    • Lester Chan 2:26 am on November 19, 2015 Permalink | Log in to Reply

      +1 to this! Just received the “WordPress 4.4 is imminent. Are your plugins ready?” Can;t wait!

    • Valerio Souza 2:42 am on November 19, 2015 Permalink | Log in to Reply


    • Matheus Martins 6:11 am on November 19, 2015 Permalink | Log in to Reply


    • Kaspars 10:33 am on November 19, 2015 Permalink | Log in to Reply

      What if a plugin author uses some kind of ticketing system to keep track of things that need to be done? How is that worse than an email being ignored?

      Secondly, are you actually supposed to read all the replies or act on them in any way? There must be equal amounts of “out of office” automated replies and standard rejects.

      • Samuel Wood (Otto) 3:10 pm on November 19, 2015 Permalink | Log in to Reply

        No, we actually don’t get many out-of-office replies.

        And if you use a ticketing system, then that’s fine. But use it for your own support system, not for the email address we have on the forums.

        Our forums send emails for things like replies, and those are pretty useless to go into a ticketing system, and it is especially useless for you to auto-reply back to the automated email from the forums.

        We need an email that goes to *you*. Not to your support systems. We don’t need “support”, after all. :)

      • Ipstenu (Mika Epstein) 4:17 pm on November 19, 2015 Permalink | Log in to Reply

        We do check if it’s an out of office before sending the notice about no auto reply. Like I said, real humans check every email. We don’t even auto-spam filter.

        It only gets muddled if the email is support@company.com and has an out of office. That’s something where we can’t tell what it is.

    • Rene Hermenau 11:24 am on November 19, 2015 Permalink | Log in to Reply

      I am guily as well and had been on business trip for a few days when the wordpress mailing was send
      I was sending out an autoreply about my trip to tell people that i will answer their mail asap when i am back and they do not have to wonder when i do not answer as fast as usual.

      The predefined mail server i am using is not self hosted and i am not able to exclude pluginsATwordpress.org from autoreplies.

      What do you recommend for this?

      • Rene Hermenau 11:30 am on November 19, 2015 Permalink | Log in to Reply

        Forget the question. I will create a dedicated mail for wordpress.org so that you do not receive any autoreply from me ever-)

        > Every single email, even the predefined ones, are written and picked and sent by hand. Even the one that goes out to all 22,573 user accounts with commit access to a plugin.

        I appreciate all the good work

      • Ipstenu (Mika Epstein) 4:18 pm on November 19, 2015 Permalink | Log in to Reply

        We do check those actually. There were two emails this cycle that were out of office replies AND came from support or other no-reply formatted emails. Those get us a little confused… We can’t easily tell the difference between a support email address that doesn’t auto reply in that situation.

    • Ahmad Awais 2:44 pm on November 19, 2015 Permalink | Log in to Reply

      +1 for this!

    • rudwolf 6:38 pm on November 19, 2015 Permalink | Log in to Reply

      +1 Absolutely!

    • AnjitVishwakarma 12:41 pm on November 25, 2015 Permalink | Log in to Reply


  • Samuel Wood (Otto) 9:53 pm on November 11, 2015 Permalink |
    Tags: banners,   

    Making Better Banners for your Plugins 

    With the plugin directory now being converted to use language packs, it’s more and more likely that your plugin will be translated by others and available in our various international plugin directories. But banners are kind of a problem for a few of those directories.

    Compare the Hebrew plugin directory to the English plugin directory. One thing you’ll probably notice right away is that the icons are on the other side. Hebrew is a Right to Left language, so the design for it is flipped. Click through to any of the plugin and you’ll notice something else: The banner image is the same, but the title is now on the opposite side of the page.

    For some plugins, especially those who designed banners thinking that the title was in a fixed place, this can present a problem.

    Probably the best solution is simply to make your banner work with either method. Compare Ninja Forms old banner vs. their new banner:





    For another example, take a look at Yoast’s SEO plugin.





    It’s an interesting stylistic difference, but the point is that they simply made the banner work for either case of title positioning. That’s honestly the best solution, IMO, because it also eliminates something from the banner that shouldn’t be there to begin with: Text.

    Text in images is bad. It’s non-accessible. Screen-readers can’t read it. It’s non-translatable to other languages. It’s a pain. Avoid it.

    However, sometimes people really like their designs. The design of a banner says a lot about the plugin, even though it’s just a big image. Some authors may want to be able to adjust their banner designs to adapt to the RTL language pages.

    For this reason, a couple of weeks ago, we added RTL support to the banners. I’ve been holding off on announcing this here to make sure it worked okay, and it appears to work fine, so, here’s the announcement. :)

    How to do it? There’s no magic to it. Just make your new banner, and name it with -rtl at the end of the name. Banner images live in the same directory as always, /assets. Nothing else changes.

    An example if you want to see how this looks in the SVN: https://plugins.svn.wordpress.org/pluginception/assets/

    And how it looks on the plugin page:





    Strictly speaking, the banner on Pluginception didn’t need to be reversed. I only did so as a demonstration, to show you how it’s done. Nothing tricky to it.

    In the future, adding support for specific locales may or may not happen. It is undecided if it is necessary, because, frankly, there’s a LOT of locales we have. Who wants to make individual banner images for 80+ languages? Best to just leave the text out of the banner instead.

    Note that while the RTL banners are now active for WordPress.org, they have not yet made their way into core, so the banners won’t yet show up properly in WordPress installations. Working on it. :)

    • Joost de Valk 10:08 pm on November 11, 2015 Permalink | Log in to Reply

      Honestly the solution we chose is…. Far from optimal. I’d prefer having the option to make RTL and LTR banners. We do similar things in CSS in WP core.

    • Rami Yushuvaev 10:30 pm on November 11, 2015 Permalink | Log in to Reply

      In other words, plugin authors has two options:

      1. Create one bidirectional banner – https://GenerateWP.com/how-to-improve-your-plugin-header-image/

      2. Create two banners for LTR and RTL views.

    • jeffmcneill 2:12 am on November 12, 2015 Permalink | Log in to Reply

      > The design of a banner says a lot about the plugin

      No, it doesn’t. The design of a banner should convey something about the plugin, the author, or a brand, but it doesn’t “say a lot” about it. There are crap plugins with good banners, and good plugins with crap banners. there is no essential link between banner quality and plugin quality, banner functionality and plugin functionality, or any other aspect. The tail should not try and wag the dog.

      • Samuel Wood (Otto) 2:59 pm on November 12, 2015 Permalink | Log in to Reply

        > there is no essential link between banner quality and plugin quality

        Sure there is: The author. A spammy looking banner probably has a spammy plugin behind it. Not saying this is always true, but hey, take a closer look at some of the banners on what you might consider to be “bad” plugins.

    • Rene Hermenau 9:08 am on November 12, 2015 Permalink | Log in to Reply

      I love the new banner RTL feature. Thanks for this!

    • dartiss 9:55 am on November 12, 2015 Permalink | Log in to Reply

      Brilliant solution Otto, thanks. I hadn’t considered this when designing my banners. Making alternative RTL banners is going to work best for me, so I have some work to do!

    • Torsten Landsiedel 12:22 pm on November 12, 2015 Permalink | Log in to Reply

      Great work! Thanks Rami for bringing this up and Otto for this solution!

    • Alex Mills (Viper007Bond) 1:11 am on November 13, 2015 Permalink | Log in to Reply

      One problem I see with Yoast’s SEO plugin’s solution is that in some languages the title could be very long and go on top of the center logo. Just something to keep in mind.

  • Ipstenu (Mika Epstein) 1:14 am on November 11, 2015 Permalink |

    Tis the Season for Snow 

    Edit: Please read this understanding we LITERALLY mean don’t submit a snow plugin that is 100% the same code as another one. If you have a new way to do it, or a functional change, that’s different. But if it’s a basic ‘this plugin makes snow show on your blog’ and it’s not different from the 21 I listed here, we’re probably going to reject it. We encourage innovation.

    Every year about this time, we get people submitting plugins to make it snow on a website.

    Besides the fact that making it snow can make your site inaccessible to people with visual issues, we actually have a lot of snow plugins.

    No, we have a blizzard of them.

    And unless your brand new ‘snow’ plugin does something in a magically new and different way, we’re not going to accept it.

    We’re all about innovation and creating new ways to solve problems. That’s why we allow so many similar plugins in the first place. There are a hundred ways around design decisions, and we love how people create their solutions. There just aren’t that many ways to make it snow, though, and in the last two years, I haven’t seen a single new ‘snow’ plugin that didn’t do things another one already did.

    If you’re going to submit a snow plugin, please make sure it’s significantly different from the ones we already have. Make sure it does something in a cool way.

    To help you with that, here’s a randomly ordered list of only some of the plugins that make it snow. I picked the top 21. There are more.

    If you want to code this just for your own coding exercise, awesome. But for now, if it’s not terribly different than what we already have, please put it on Github.

    • Archie22is 7:00 am on November 11, 2015 Permalink | Log in to Reply

      #word – I couldn’t have said it better myself

    • Rene Hermenau 10:56 am on November 11, 2015 Permalink | Log in to Reply

      I totally understand this decision from a plugin reviewer standpoint but it leaves a bad taste considering what could happen in future with other plugin requests. “Snow” only delivers 36 plugins which is much less than other plugin categories like “caching” or seo.

      I just hope that such general refusals will still be considered very well in future otherwise we only have jetpack, Yoast and wooCommerce all over;-) Think you get the point.

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

        Then make the plugin different. But I promise you that 100% of the submitted plugins for snowing are identical to one of those 21. Identical. The same JS and php.

        The point I’m trying to make is that IDENTICAL plugins aren’t helping the repository, or you. There are a lot of similar plugins, and that’s fine. But I am literally saying don’t be identical.

        Not kidding.

        If someone does it in a new and different way, I will gladly approve it. It’s just been two years since anyone has.

        • ArtissTheGeek 11:48 am on November 12, 2015 Permalink | Log in to Reply

          This is slightly at odds to discussions I’ve had in the past. I’m passionate not so much about this issue but the problem of abandoned plugins. I believe there should be an easy for people like me, who’d love to take over some abandoned plugins, to do so. But when I’ve brought this up with you guys I’ve been told I just need to copy the original and create my own branch. That doesn’t help – you end up with duplicates and I’m unable to easily transfer the user base over.

          So, can I ask again, any chance of putting some thought on how to deal better with abandoned plugins? I’m sure I can’t be the only developer who would love to assist with this.

          • Marcel Pol 4:06 pm on November 12, 2015 Permalink | Log in to Reply


            I am not on the plugin review team, but have some experience.
            There are different scenario’s possible:

            • There is a contact listed in that plugin. You can email the author, and request svn access. Only he can give that, through his admin interface on the plugin page.
            • If the author cannot be reached, you can talk with the plugin team, to see what they can do. They might have a different way to contact. They can (but not must) give you admin access. They might request certain things for that, like an already updated plugin in a zip, to show that you can and will make updates).
            • If the author doesn’t want to give you SVN access, and doesn’t want to give up that plugin. Then you can just fork it under a different name if you want to.
            • There might be more scenario’s, but these are ones I had experienced.
            • Ipstenu (Mika Epstein) 7:28 pm on November 13, 2015 Permalink

              99% accurate :)

              “They can (but not must) give you admin access.”

              That’s where things get messy :) And yes, we do require an updated zip first.

          • Ipstenu (Mika Epstein) 7:28 pm on November 13, 2015 Permalink | Log in to Reply

            It’s off topic and no it’s not at odds with discussions about adoption. You’re not reading this properly.

            If your code is 100% the same as another snow plugin out there, please don’t submit it.

            Seriously. I’m not making an exaggeration. THESE SUBMISSIONS ARE 100% COPIES. If your plugin is a fork that does something notably different (like say it snows based on the strength of the snow in your blog’s physical location), then I’d happily approve it. That’s different.

            Stop thinking this is us trying to stifle innovation or even about preventing similar plugins in the repository. In fact, it’s us attempting to FORCE people to make similar, but different, code. Different.

            I swear to you, the code is 100% the same. In two years I have not seen something new with basic snow plugins.

            Now to answer your question… To be perfectly honest, I’ve talked to hundreds of people about taking over plugins. I do not remember the conversations with you personally. I also don’t see a single email from you to the support email about asking to take over a plugin, so I can only address this anecdotally.

            We _do_ allow takeovers of plugins now. We didn’t because we hadn’t sorted out a proper way of handling it. We did. A couple years ago.

            Right now if there’s an abandoned plugin you want to take over, here’s how it works:

            1) Fork the plugin and update it. Modernize it for 2015 (or whatever). Make sure it’s using good code, is secure, and would otherwise pass a new-plugin-check today.

            2) Email us and say “Hi, I want to take over plugin X (link). Here’s my updated version.”

            3) We will review the new code and, if it would pass muster, contact the original dev.

            At this point it gets messy. If they say ‘no’ that’s the end. If they say ‘yes’ then we hand it over. If they don’t reply, we internally have a longer conversation about what to do. In some cases, we decide not to hand over the plugin based on who the new author is or who the old author is or myriad reasons. It’s a bit of a judgement call.

            Some plugins are too important to hand over to just anyone. Sorry. Other plugins are used by too many people and the upgrade would break. And sometimes the plugin belonged to a beloved member of our community who has passed away, and we’d rather give it to someone closer to them.

            If you have further questions about the details of taking over someone else’s plugin, please email plugins@wordpress.org

    • Lara Littlefield 6:07 pm on November 13, 2015 Permalink | Log in to Reply

      I can’t believe there are a complete top 21 to choose from! Thank you for sharing!!

    • WebberZone 3:43 pm on November 16, 2015 Permalink | Log in to Reply

      Just too much snow plugins in my opinion. Am curious as to other plugins that you’ve noticed that are highly similar!

  • Samuel Wood (Otto) 10:51 pm on November 6, 2015 Permalink |
    Tags: cc, cc-by, cc-by-sa, creative commons,   

    Creative Commons Licenses in the Plugin Directory 

    Back in February, the Creative Commons organization began taking steps to introduce compatibility between their licenses and the GPL. At that time, we took notice and started discussing the problems we’ve had with CC licenses in the directory in the past.

    Part of the problem is that the Creative Commons licenses are so fragmented. It’s very much a choose-your-own adventure landscape for CC licenses, and many people don’t understand licensing very well in the first place (it can be confusing, I admit).

    Since we require everything in our directory to be GPL Compatible, then it’s something we have to constantly scan for when even an accidental violation occurs.

    Then, things became even more interesting in March, when gnu.org silently changed their compatibility page to state that CC-BY 4.0 was now considered compatible with all versions of the GPL. So, at that time, we started trying to ignore that particular case. It isn’t easy, because a lot of CC licensed code is licensed under version 3.0 of their licenses, which is not GPL Compatible. And the issue of CC-BY-SA was still very much up in the air.

    However, last month, Creative Commons finally stepped up. CC-BY-SA 4.0 is now compatible with the GPLv3.

    Accordingly, you can now use CC-BY 4.0 and CC-BY-SA 4.0 licensed code or images or anything else in the WordPress.org plugin and theme directories.

    A few points of note:

    • Only version 4.0 is acceptable. Check before using third party code which may still be licensed using 3.0.
    • Only the Attribution (BY) and Share-Alike (SA) clauses are acceptable. The No-Derivs (ND) and Non-Commercial (NC) clauses are definitely not GPL-Compatible. Code or images using them cannot be used.
    • If the code you’re wanting to use has the Share-Alike (SA) clause, then it is only compatible with the GPLv3, not GPLv2. This means your plugin and all the other code in it must be licensed under the GPLv3. The GPLv2 is not compatible with the GPLv3.

    The license compatibility page does mention that the compatibility is one-way. This is important, but probably not relevant for the most common cases we’re concerned with. The cases for plugins is likely that they want to use CC licensed code such as javascripts. The cases for themes is likely that they want to use images or other artistic work in the themes. Well, now you can do that. Just mention in the readme.txt for either where the work you’re using was obtained from, and the license that work is available under. Since you’re not relicensing the work, then one-way compatibility is not really an issue.

    If you need it in simpler terms:

    • CC0 – This is equivalent to a public domain declaration, essentially, compatible with everything, and we have always allowed it.
    • CC-BY 4.0 – Compatible with any version of the GPL.
    • CC-BY-SA 4.0 – Compatible with the GPLv3 only.
    • Previous versions of CC licenses (like 3.0) – not compatible.
    • Any CC license containing “NC” or “ND” terms – not compatible.

    So, if you have a favorite library or image that we’ve had to push back on you in the past for, take another look at it. The license might be compatible now. Also, if something is CC 3.0, consider asking the author of the work to bump that up to 4.0, so you can use it. It’s nicer for everybody to have more things out there compatible with each other.

    (Note: everything above applies to themes too. I just don’t want to write two posts. :) )

  • Ipstenu (Mika Epstein) 2:30 pm on October 20, 2015 Permalink |
    Tags: , warning   

    Regarding Offers to “Buy” Plugins 

    Did you get this email:

    We’re reaching out to the WordPress community, looking for
    individuals/companies like yourself who are keen to explore the opportunity
    of a joint venture/sale of their WordPress plugin/s.

    If you are interested in discussing your plugin and what we’re offering
    please fill out the form on the attached website, and we will be in contact
    with you.

    This was a blast email sent to a few hundred people by an unknown person.

    Please delete it. It’s not from anyone we can trace back to the WordPress community, and selling your plugins will likely end with your users being highly upset that the changes in the plugin are not what they wanted. At the best, you’ll end up on a spam list.

    If you are a company looking to ‘buy’ plugins please don’t use tactics like this. It makes you look like a sleazy sort of person, whom no one would want to do business with. Purchase plugins by directly talking to people who have made a plugin you had a need for.

    If you do sell your plugin (or give it away to someone else), please make sure the new owners understand all the guidelines of the repository. Should they violate our terms the plugin will be removed, and we may not give it back depending on the level of the violation. Whomever has commit access to a plugin has the ownership and responsibility of it’s behavior for users. Spamming, inserting tracking data, and adding junk features are the fastest way to ruin your plugin.

    We advocate only giving your plugin to people you personally have vetted, and that you trust with being responsible with your code and your users.

    • Varun Sridharan 2:35 pm on October 20, 2015 Permalink | Log in to Reply

      Thanks For The Information :)

    • David Anderson 2:35 pm on October 20, 2015 Permalink | Log in to Reply

      I’ve had multiple of these. It would be interesting to see what someone gets if they fill in the form – not because I’m interested in selling any plugins to random email contacts (I’m certainly not!), but it’s always useful to understand the landscape of what kind of interesting ventures, curious escapades and downright scams different people out there are up to.

    • Brajesh Singh 2:40 pm on October 20, 2015 Permalink | Log in to Reply

      Thank you for posting Mika.
      Had received an email from some guy named Michael Jenkins today and was wondering how they got my email. The strange thing was they were not using any of the emails I use on wp.org instead my sites admin email.

      Had seen this earlier a few months ago, but did not care as anything serious due to there footer mailing list link.
      Anyway, never considered selling the plugins to any company, so was not much of an issue.

    • Joost de Valk 2:54 pm on October 20, 2015 Permalink | Log in to Reply

      So if you do have a nice plugin and want to sell it or otherwise hand it to someone else, talk to me :)

    • Aaron D. Campbell 2:57 pm on October 20, 2015 Permalink | Log in to Reply

      I’ve gotten three this week. The one you posted above was so ridiculously impersonal that I actually wrote back and chastised them for adding plugin authors to a list and doing a blast without even taking the time to set up a merge with a name or plugin name.

      The other two at least called me by name, listed the plugin they wanted to buy, and had business sites.

    • Aaron D. Campbell 3:02 pm on October 20, 2015 Permalink | Log in to Reply

      There was also an unsubscribe link in the footer, which is one of the things that really ticked me off. They made a list and added people to it with no opt-in of any kind.

    • Shareaholic 3:37 pm on October 20, 2015 Permalink | Log in to Reply

      +1 Mika vet people personally, and talk to only those that you trust being responsible with your users.

      +1 Joost… if you do have a nice plugin related to social, analytics, content recommendations or lead capture and want to sell it or otherwise hand it to someone else who will invest in and support and take care of the userbase, please reach out!

    • WPspider 2:30 am on October 21, 2015 Permalink | Log in to Reply

      It was probably a capitalist! Boy, those guys really get on my nerves.

    • FolioVision 3:17 am on November 3, 2015 Permalink | Log in to Reply

      We’ve had a few of these emails as well. Thanks for the heads up and reminder Mika. (Grievous) misbehaviour could count across an account which would demotivate these acquirers (unless people are willing to sign off their WordPress.org accounts to them: at that point you could track by IP and find most miscreants pretty quickly).

  • Pippin Williamson 3:06 pm on October 5, 2015 Permalink |
    Tags: , ,   

    Guidelines for Plugins that Include Company and/or Product Names in the Plugin Name 

    When submitting plugins to the WordPress.org repository, there are a number of guidelines for what is and is not acceptable. One of those guidelines has to do with the name of your plugin, especially when it includes the name of a company, trademark, or product.

    If you have submitted a plugin and received a rejection email that started with something like the quote below, it means you need to adjust the name of your plugin.

    We’re no longer accepting plugins that include a trademarked product name or term as the name or slug of a plugin. Nor are we accepting plugins that include the name of another plugin at the beginning of the name/slug.

    Before you submit your plugin for review, take the name of your plugin into consideration and try and pick a name that will not be rejected. To help you choose a better name, here are a few guidelines to keep in mind.

    Your plugin includes the name of a company, trademark, or product

    Take WooCommerce as an example.

    The following names will be rejected:

    • WooCommerce – Product Add Ons
    • WooCommerce – Better Stats

    We will, however, accept the following (if not already taken):

    • Product Add Ons for WooCommerce
    • Better Stats in WooCommerce

    One of the key points is that your plugin’s name cannot start with the company/trademark/product name.

    Here’s another example. Stripe Payments will be rejected. Payment Form for Stripe will be accepted (if available).

    You work for the company whose product’s name you are using

    You are permitted to submit plugins that include the company/trademark/product name If you work for the company owns it.

    For example, if you work for PayPal, you may submit a plugin named PayPal Payments.

    In order to have your plugin approved, you must submit the plugin from an official company account. This usually means the email address on the account is {yourname}@{company}.com If you submit it from a non-company account, your plugin will be rejected.

    You do not work for the company but you have permission to use the company/product/trademark in your plugin’s name

    In this case, we will ask you for proof of written permission from the company that explicitly states you have permission to use the name.

    For example, if you wish to submit a plugin called Gravity Forms – CSV Exporter, you must have proof of written permission from Rocket Genius, Inc. to include Gravity Forms in the name.

    Please provide proof with your initial submission, otherwise it will be rejected.

    Questions, Feedback, Comments

    If any of this is unclear or you have comments or questions, feel free to leave them below.

    Update 1

    There was some confusion as to some of the guidelines regarding trademarks, company names, and product names.

    To help clarify:

    1. If your plugin name includes a trademarked product name or term, you must be the owner of that trademark, work for the company that owns the trademark, or you must have permission from the owner to use it.

    2. If your plugin’s name includes the name of a company or the name of a company’s product, you may not use their name at the beginning of the plugin’s slug. “WooCommerce – Product Addons” is not permitted. “Product Addons for WooCommerce” is permitted.

    3. These guidelines are specifically at the slug of the plugin (wordpress.org/plugins/this-is-your-slug). The slug is auto generated based on the name you enter when submitting your plugin. After submission, you can still alter the exact name that is displayed on your plugin’s page via the readme.txt file.

    Note: these are not 100% hard-fast rules and there are always exceptions. It is up to the reviewer’s discretion how strongly they wish to enforce these guidelines. To best ensure your plugin is approved in a timely manner, however, do your best to follow these guidelines.

    • Gabriel Reguly 3:12 pm on October 5, 2015 Permalink | Log in to Reply

      Off-topic but hopefully worth to say :-)

      Very nice to see you here Pippin!!


    • kjbenk 3:13 pm on October 5, 2015 Permalink | Log in to Reply

      This is a great improvement. I would say that for the slug names would you accept strings like ‘company-plugin-name’ instead of just ‘plugin-name’? I truly believe that prefixing your plugin slug with your company is extremely useful for conflicting plugins. Although, I do understand why you are making these rule more strict since many developers are creating plugins with company names that are not theirs.

    • Drivingralle 3:15 pm on October 5, 2015 Permalink | Log in to Reply

      I dislike that addon plugin names like “WooCommerce – Better Stats” will now longer be possible.

      The very good thing about this way of writing the name is/was that in the plugin list in the admin all the plugins related to for example WooCommerce where close to each other.

      Also I think it’s easier to see that this plugin is an add on.


      Like that without permission the company name is no longer allowed.

      • Gabriel Reguly 3:19 pm on October 5, 2015 Permalink | Log in to Reply

        The plugin name is different from the plugin slug, check this one:


        The slug is wc-free-shipping and the readme.txt name is WooCommerce Free Shipping.

        Rule is followed and sorting is preserved. :-)


        • Pippin Williamson 3:29 pm on October 5, 2015 Permalink | Log in to Reply

          Gabriel, thank you for clarifying that.

          @Drivingralle What Gabriel said is correct. You can still set the name in your readme.txt to “WooCommerce – Better Stats”. You just cannot use that for the plugin’s slug.

          • Drivingralle 3:33 pm on October 5, 2015 Permalink | Log in to Reply

            Perfect. Was not obviously to me by reading.

          • maxfoundry 9:11 pm on October 8, 2015 Permalink | Log in to Reply

            Hey Pippin. Hope you’re well.

            The real question for us is how this is going to effect search with Google because that’s where a lot of search begins. And with that the title plays a big role in it. So are we kicking all of those folks out of search. The same way you can’t purchase keywords on Google with ‘WordPress’ in them?

            • ggwicz 11:39 pm on October 8, 2015 Permalink

              Nobody’s being kicked out. If “WooCommerce – Better Stats” is good at showing up in search results, it’s because of the keywords “WooCommerce” and “Stats”. Both keywords still happily exist in the alternative “Better Stats for WooCommerce”; shifting the position of these keywords slightly will not make or break your search rankings and/or, by extension, the success or failue of the plugin.

    • David Anderson 3:19 pm on October 5, 2015 Permalink | Log in to Reply

      This immediately made me think of something not entirely unrelated: https://xkcd.com/1562/

      The implicit logic here is that having a product name at the beginning of a sentence makes an implicit claim about endorsement/official status, whilst having it at the end, preceded by “For” makes a significantly different claim. I think that’s an extremely crude bit of grammatical (mis-)parsing.

      The English language allows plenty of compression. It is common to elide prepositions, such as “for”, by re-arranging the word order. I think this change is much too defensive, and assumes a patronising default position that users of the plugin directory can’t parse grammar. Or is it to avoid litigation from lawyers whose clients can’t parse grammar? Either way, it seems a retrograde step.

      • Pippin Williamson 3:31 pm on October 5, 2015 Permalink | Log in to Reply

        David, one of the primary reasons for this is to help address the issue where the actual product / company owners are unable to use their own plugin’s name because someone else who is completely unaffiliated with them has already taken it. Companies have a right to be able to use their own product names, and it’s a right that should be reserved for them.

        • David Anderson 3:42 pm on October 5, 2015 Permalink | Log in to Reply

          Hi Pippin,

          No objection to companies being able to use their own company/product name. But, I’m seeing a disconnect between the problem and the solution. “Product Addons for WooCommerce” still uses the WooCommerce trademark just as much as “WooCommerce – Product Addons” does. It either creates a new convention that companies must name their products using their trade-mark at the start of their product name, or it assumes that that is always the case. It seems a crude solution to the problem.

    • Waseem Senjer 3:57 pm on October 5, 2015 Permalink | Log in to Reply

      What about the plugins which they already in the repository?

      • Pippin Williamson 4:00 pm on October 5, 2015 Permalink | Log in to Reply

        This only applies to newly submitted plugins.

        • Arnan de Gans 11:27 pm on October 6, 2015 Permalink | Log in to Reply

          You should take requests to deal with existing plugins as well, I have a few guys who used my trademarked name without consent that I don’t want in the repo.

          Last year when I raised this issue nobody at WP seemed to care or be willing to do anything – I guess buying WooCommerce suddenly made this a worthy item?

          • Pippin Williamson 12:20 am on October 7, 2015 Permalink | Log in to Reply

            We can. Send a request to plugins(at)wordpress(dot)org

            When we said it only applies to new plugins, we just mean mean that we will not be actively hunting down and forcing existing plugins to change their name on our own volition. We’ll happily work with you though.

            Sidenote: the plugin repository is managed by volunteers, none of whom work for Automattic, the company that purchased WooThemes.

    • dlouwe 4:30 pm on October 5, 2015 Permalink | Log in to Reply

      The guidelines above, as well as some of the clarifications made in reply seem to have some inconsistencies.

      The email quoted at the top of the post says “We’re no longer accepting plugins that include a trademarked product name or term as the name or slug of a plugin.” indicating that trademarks are not allowed in the name or slug at all, however the guidelines then indicate that names *may* include a trademark in the form of “[Plugin] for [Trademark]”

      Further, the guidelines outright state: “The following names will be rejected: WooCommerce – Better Stats”, without any qualifier about the slug. But in a follow-up comment Pippin clarifies: “You can still set the name in your readme.txt to “WooCommerce – Better Stats”. You just cannot use that for the plugin’s slug.” These two statements seem to be contradictory. Perhaps I’m missing something?

      • Pippin Williamson 5:34 pm on October 5, 2015 Permalink | Log in to Reply

        When a plugin name has a trademarked name or term in it, it will almost always be rejected unless you have permission from the trademark holder to use it. Product and company names are less restrictive, so those will usually get accepted if in the format of “Some Feature for {Product/Company}”.

        Note: these are also all just guidelines and none of them are hardfast legal rules. It is still up to the reviewer’s discretion whether or not to accept a submission based on the name provided.

        • dlouwe 6:02 pm on October 5, 2015 Permalink | Log in to Reply

          Okay, that makes a bit more sense. If reviewers are going to be more strict regarding trademarks as opposed to company/product names, maybe it’d be beneficial to address that in the guidelines? As it stands, I don’t get that impression from reading the post above, as “company/trademark/product name” is used collectively so many times.

          Similarly, if there are cases where the readme.txt name may be treated more or less strictly than the slug, it might alleviate some confusion to provide an example that illustrates the difference.

        • Laurens Offereins 6:24 pm on October 5, 2015 Permalink | Log in to Reply

          I’m with @dlouwe on the seemingly inconsistent use of “company/trademark/product name” in the explanations.

    • Pippin Williamson 6:33 pm on October 5, 2015 Permalink | Log in to Reply

      I’ve posted some updates above to help clarify a few points.

    • carlhancock 8:10 pm on October 5, 2015 Permalink | Log in to Reply

      The trademark concerns make sense. I’d rather 3rd party Add-Ons be named something along the lines of XXXXX for Gravity Forms rather than Gravity Forms XXXXX Add-On in the repository.

      However, how is this going to be applied in situations where the add-on or extension is an integration with ANOTHER 3rd party service or SaaS? For example PayPal.

      How do you say it’s a PayPal add-on for Gravity Forms without leading with PayPal or Gravity Forms?

      Normally you’d say:

      A) Gravity Forms PayPal Add-On


      B) PayPal for Gravity Forms

      The first wouldn’t be allowed, and while the 2nd follows the guidelines it wouldn’t be allowed either because PayPal is also a trademark name and not just Gravity Forms.

      So how are 3rd party integration plugins supposed to be named in this situation without getting ridiculously verbose for the sake of working around this issue? It could get quite comical. For example if A) and B) in my above examples aren’t allowed would it have to be C) below?

      C) Payments with PayPal for Gravity Forms Add-On

      This isn’t meant to make fun of this change. Gravity Forms is a registered trademark. So i’m definitely sensitive to it’s usage and potential misuse.

      It’s much easier with non-integration situations where you are adding functionality and not integrating with a 3rd party service. But it becomes more complex when talking about plugins who’s primary purpose is integrating one product with another.

      Many many plugins are extensions and add-ons that integrate one product that has a trademarked name with another product that has a trademarked name so how are these to be handled?

      • Pippin Williamson 8:17 pm on October 5, 2015 Permalink | Log in to Reply

        That’s precisely one of the reasons this is not a hard-fast rule. There are certain cases where the reviewer has to use their own judgement.

      • Brad Touesnard 12:15 pm on October 6, 2015 Permalink | Log in to Reply

        Hah, I was going to comment exactly this. I think it would be worth giving some examples of this scenario that would be acceptable. Would A) or B) be accepted? I don’t think they should.

        I would recommend against ever using trademarks in plugin names if there’s even the slightest chance that there will be a paid upgrade at some point as you won’t have anything to trademark yourself. For example, in A) or B) there’s absolutely nothing you could trademark there.

        Maybe developers should be encouraged (I’m not saying it should be required) to add their own brand to these types of plugins. For example, if we released it, we could call it “Delicious Brains PayPal Addon for Gravity Forms”. A developer could use their name, like “Nick’s PayPal Addon for Gravity Forms”. I’ve seen this plenty in the directory, so it’s not a new concept, but might make a nice guideline.

        • Pippin Williamson 1:33 pm on October 6, 2015 Permalink | Log in to Reply

          While it won’t be something we can enforce, I think it’s a great idea.

        • Ipstenu (Mika Epstein) 4:56 am on October 7, 2015 Permalink | Log in to Reply

          That’s what I’ve been suggesting, actually.

          1) You’re not paypal
          2) You’re not gravity forms

          I also like to use the Keurig example. I had one before @getsource converted me to AeroPress. I used refillable pods called EcoBrew pods. They were “EcoBrew Refillable Pods for Keurig ™”

          1) EcoBrew was THEIR product
          2) Keurig was not.

          Put yourself first.

          Now that said, woo-cool-tapdancing-elephants is okay. So is (to use that Keurig example) kcp-ecobrew (kcp = Keurig Coffee Pods). You can’t ‘own’ that short slug.

          If you want to have a cool slug, though, submit the plugin name as the slug name. If I want ‘helf-slug’ I submit as that and make the display name whatever I want :)

          Though really you should always have your product name first :) It’s just good branding.

    • Henry Wright 4:52 pm on October 19, 2015 Permalink | Log in to Reply

      The thought of trademarks didn’t occur to me when I named my plugins (BuddyPress Mute and BuddyPress Identicons). I’d like to respect these trademarks and remove the offending part from the slug. Is there any guidance on how to go about doing that? Who to contact?


      • Pippin Williamson 5:44 pm on October 19, 2015 Permalink | Log in to Reply

        We do not have a way to change plugin slugs. If you want to do that, you have to re-submit your plugins under a different slug. We can then disable the old plugin pages. This is not optimal, however, because you will lose all stats and users will not see automatic updates to the new version.

        • Henry Wright 11:51 pm on October 19, 2015 Permalink | Log in to Reply

          Thanks for the reply. I’ll wait and hopefully a way to change slugs will be made available at a future date for cases such as this.

  • Samuel Sidler 11:08 pm on October 1, 2015 Permalink |
    Tags: glotpress   

    General Recommendations for GlotPress WordPress Plugins 

    At the GlotPress weekly chat last week and this week, a group from the community decided to work on an experimental plugin that moves GlotPress code into a WordPress plugin. In doing so, they expect that there will be future WordPress plugins that are meant solely for integrating with the GlotPress plugin.

    During the chat, a couple of recommendations were proposed:

    1. WordPress plugins built solely for GlotPress should use “gp” at the start of their plugin slug for easier identification.
    2. Similarly, these plugins should add the “glotpress” tag to their Readme file for easier discovery.

    Again, these are just recommendations and not requirements for any plugin in the directory. If you’re a plugin developer that’s interested in GlotPress-the-plugin, read through the summary and get involved!

  • Ipstenu (Mika Epstein) 10:03 pm on October 1, 2015 Permalink |

    Protocol Relative Enqueues 

    With the http/2 and https features of WordPress on the future plan, it’s time for a reminder about how to enqueue things. If you haven’t read John’s post about https configurations, please do. We want to make things work well for everyone and future proof your code :)

    A common method to enqueue fonts is to use the CSS url like this:

    wp_enqueue_style( 'my_awesome_css', 'http://somecoolurl.com/my-awesome.min.css' );

    The problem with this, as we move to more and more of an https world, is that will cause errors with people who want that beautiful green padlock. In order to make their life easier, please use protocol relative URLs in your enqueues:

    wp_enqueue_style( 'my_awesome_css', '//somecoolurl.com/my-awesome.min.css' );

    It’s really that simple. The future will thank you.

    Edit: Yes, if a url has HTTPS and you can use it, use it. Eventually we’ll all be https and none of this will matter, but hard coding in http is making life difficult :)

    • Dominik Schilling (ocean90) 10:06 pm on October 1, 2015 Permalink | Log in to Reply

      Actually this technique is becoming an anti-pattern. If the (external) asset is available on SSL, then always use the https:// asset.

      • Samuel Aguilera 10:20 pm on October 1, 2015 Permalink | Log in to Reply

        If you’re going to enqueue an external asset from a known domain with https support, ok you can do that. But if you’re going to enqueue an asset from a folder of your plugin/theme you don’t know if the user that is using your plugin/theme has a site with https support. So you need to use the protocol relative method or use is_ssl() to dynamically change the protocol prefix.

        Maybe the example in the post is not the best.

    • Jon Brown 10:07 pm on October 1, 2015 Permalink | Log in to Reply

      One note on this example… while nothing terribly wrong with this if you’re enqueuing from a domain that you know _has_ SSL like bootstrapcdn.com, you should generally hard code the scheme as https://

      If you’re enqueing form somewhere like your own domain where maybe SSL could go away, by all means keep it //

    • Bjørn Johansen 10:07 pm on October 1, 2015 Permalink | Log in to Reply

      If you are enqueuing a resource that is available over HTTPS, you should always use HTTPS. More info on that here: http://www.paulirish.com/2010/the-protocol-relative-url/

    • Arnan de Gans 10:45 pm on October 1, 2015 Permalink | Log in to Reply

      Careful with agnostic links, they fail many times or the browser assumes http (Safari atleast).
      If a asset is available on https, there is really no reason to use http. So just hardcode in https and be done with it.

      If the browser has less to figure out on it’s own, pages ultimately render faster, too. I believe.
      Even if it’s <1ms. There is no reason to have the browser consider alternatives 😉

    • webaware 11:06 pm on October 1, 2015 Permalink | Log in to Reply

      +1 use https: if you know it’s available, Paul Irish anti-pattern, yada yada.

      If the asset is only ever going to be loaded on a website, sure, use protocol relative and let the web browser sort it out.

      If the asset can possibly be loaded somewhere else, like an email reader, then you need to specify the protocol. Just use something like this:

      $protocol = is_ssl() ? ‘https’ : ‘http’;
      wp_enqueue_style( ‘my_awesome_css’, “$protocol://somecoolurl.com/my-awesome.min.css” );

    • Todd Lahman 11:11 pm on October 1, 2015 Permalink | Log in to Reply

      Using a relative URL prevents a CDN (content delivery network) from caching and serving static assets, as would be expected on the frontend, whether it is HTTP or HTTPS. As Google has already signaled all URLs should be served using HTTPS, assets will be served using HTTPS from the CDN as well.

      It is best to never use a relative URL. To get the current scheme, whether http or https, using the following example function below.

      function my_plugin_url() {
      	return plugins_url( '/', __FILE__ );


    • Anthony Hortin 4:41 am on October 8, 2015 Permalink | Log in to Reply

      I presume something like the following is still acceptable to use since get_template_directory_uri() checks for SSL?

      wp_register_style( 'gridsystem', trailingslashit( get_template_directory_uri() ) . 'css/grid.css' , array(), '1.0.0', 'all' );

    • chatmandesign 5:59 pm on November 24, 2015 Permalink | Log in to Reply

      Seems to me that for best compatibility, agnostic URLs should always be used in code intended for general distribution, except when loading common third-party assets where HTTPS is known to be reliably available (e.g., loading jQuery from Google). This includes functions like get_template_directory_uri().

      Why? Caching plugins. I’ve run into issues where the same cached pages are being served by a caching plugin over both HTTP and HTTPS. If it was cached over HTTP, the links that were generated by get_template_directory_uri() break when accessed over HTTPS.

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