Make WordPress Plugins

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 7:48 pm on April 23, 2013 Permalink | Reply  

    Plugins SVN Repository DNS Change Today 

    In a short while (next 30 minutes or so), plugins.svn.wordpress.org will undergo a DNS change as part of a datacenter migration. The TTLs are low, so this should only take a few minutes.

    Nothing will go down, but the SVN repository will become temporarily read-only. If you try to commit code during this time, you’ll receive an maintenance message pointing you here. Plugin pages and downloads will not be affected.

    Also, the associated Trac at plugins.trac.wordpress.org will be taken offline (for up to an hour) while it is migrated and re-synced.

     

    • Sam 8:15 pm on April 23, 2013 Permalink | Reply

      ok good luck andrew ^-^

      • javornh 2:59 am on May 19, 2013 Permalink | Reply

        i am look for eCommerce plugin the allow people to upload documents to be printed and deliver to them from my online store.
        these are the step i want costumer to take.
        1 select if document is black and white or colour the number of pages and number of copy.
        2 the total amount on money they will pay will display with a containue botton.
        3 they pay
        4 the plugin will the send the document to an email address along with a invoice with the costumer name address and the they way the want the document to print.
        can anyone tell me if the could build this for me

        • javornh 3:01 am on May 19, 2013 Permalink | Reply

          sorry i forget to add ,they will have to upload the document before the pay

    • Andrew Nacin 8:17 pm on April 23, 2013 Permalink | Reply

      Plugins SVN is online again. If your commits are not working, flush your DNS cache. Here’s the proper IP address for plugins.svn.wordpress.org:

      $ dig plugins.svn.wordpress.org +short
66.155.40.242

      Trac remains down while it re-syncs.

    • Andrew Nacin 8:37 pm on April 23, 2013 Permalink | Reply

      Everything is back online.

    • jquindlen 11:54 pm on April 23, 2013 Permalink | Reply

      If you don’t know how to flush your DNS on Windows, open up cmd and type:
      ipconfig /flushdns

    • jquindlen 11:55 pm on April 23, 2013 Permalink | Reply

      To flush your DNS on Windows, open a command prompt (run > cmd) and type: ipconfig /flushdns

    • JAkzam 7:11 pm on May 15, 2013 Permalink | Reply

      Hey could someone maybe help me out…I’m a long time WP Developer, but just release our first public Plugin that has been accepted and approved for the WP directory and the SVN.

      I received the email to wait about an hour (it’s been many) and login with this account information.

      But I think I may have screwed up, as I think I have a previous registration on the SVN Repository using this same username. When I log in to the already created account, it says I am not involved in any projects, but the link to the SVN Repository shows my files…

      So what do ya think…should I just be a little more patient?

      Thanks…

      Johnny

      p.s. Sorry if this isn’t a good place to ask this question. But I’m a quick learner.

    • Rufus Fortier 11:33 am on May 16, 2013 Permalink | Reply

      I loved this interview so much. I once read in another interview you did, you said, Every color matches. That has always stuck with me and have since sort of adopted it.

    • Roderick Leighty 7:59 am on May 17, 2013 Permalink | Reply

      Such a beautiful post! I get told frequently the same thing and you put into words my thoughts :) I will be “following” you and look forward to reading more!

  • Ipstenu (Mika Epstein) 10:18 pm on May 1, 2013 Permalink | Reply
    Tags: ,   

    Font Awesome is permitted in the Plugin Repository 

    This took longer than we would have liked to say, but there were communication issues on multiple fronts.

    You can use the Font Awesome font files and CSS in your code, per the current Font Awesome License:

    As far as crediting is concerned, we feel attribution is always good. You should always put that in your source code, but your readme is optional. Credit links must be opt-in if they show on the front facing part of your site (this includes the login page), but that’s nothing new.

    So with that said, we’re going through the plugins that had been closed for Font Awesome usage and opening them. If we missed yours, please email us at plugins at wordpress.org, with a link to the plugin (like http://wordpress.org/extend/plugins/font-awesome/ which is open) and we’ll check right away.

     

  • Ipstenu (Mika Epstein) 6:45 pm on April 22, 2013 Permalink | Reply  

    Plugins to embed audio/video or use HTML, please read 

    If you have a plugin with the sole purpose of embedding video into WP posts, or one that makes HTML5 work in WP, you need to know that there is HTML5 support for Audio and Video coming in WordPress 3.6, so please test ASAP.

    Read Audio/Video Support in Core

     

  • Samuel Wood (Otto) 4:14 pm on April 16, 2013 Permalink | Reply
    Tags: author, google, markup, schema   

    Be the Author… 

    So, I’ve had this working for a while, but not a lot of people noticed, so I figured I’d spell it out explicitly.

    WordPress.org plugin pages have special magic Google markup. This is what allows many of the Google tricks we do for plugin pages to work. If you’ve ever searched for one of our plugins on Google, you may have noticed that it says it’s “free” as well as showed the rating as stars and such. This is all using Google’s Rich Snippets functionality with markup from the schema.org specifications.

    One of the magic tricks we do is to point to your WordPress.org Profiles page as the “author” of the plugin. It’s your plugin, after all, and you deserve the credit. But promoting the authorship is only half the picture, it helps if Google also knows who you are as an author. Then they can do something clever too:

    googleauthor

    This is a sample entry for one of my plugins from the Rich Snippets Testing tool. The photo and authorship info may not show up on every search result that gets my plugin up on Google’s search results, but it certainly doesn’t hurt. But to get this information to be capable of showing, Google needs to connect your profile and user information on WordPress.org with a profile and user information from Google+. To do this, there’s two steps:

    Step 1: Edit your WordPress.org profile to include a link to your Google+ account. You can do this yourself, and you can see how I did it on my Profiles page. I included this link in my “About Me” section: https://plus.google.com/100201852715113506716?rel=author

    Note that the ?rel=author bit is important, that’s what tells Google that you are the author here and links your G+ account to this page.

    Step 2: Tell Google that you contribute to WordPress.org. To do this, go to your Google+ Profile. In the “Links” section you will find a “Contributor To” area. You need to add two links to this area:

    • The first link will be a link to your own profile page, on http://profiles.wordpress.org. This completes the connection and tells Google that you and the profile are the same person. Because your plugin page automatically links to your profile with the author information, making this connection creates an indirect authorship connection to all your plugins.
    • The second link you need to make is a link to http://wordpress.org itself. This is because Google wants there to be an explicit connection on the same domain name (not a subdomain), and so this link is required. And hey, you’re contributing to WordPress.org every time you update your plugin or theme, so well done there! :)

    After doing both these steps, you can try your plugin’s URL in the Rich Snippets tool yourself, and voila, you’ll see the magic. Note that you may not see it in the actual Google search results for weeks, and it may never appear. Google shows snippets like these on terms of their own choosing. All you’re doing here is to give them the data that lets their engine do the magic, if it can.

     

    • Gabriel Reguly 4:24 pm on April 16, 2013 Permalink | Reply

      Wonderful Otto! Thanks for sharing this.

    • Charleston Software Associates 4:28 pm on April 16, 2013 Permalink | Reply

      Coolness! Thanks for the step-by-step guide, Otto. Works great!

    • myatu 5:39 pm on April 16, 2013 Permalink | Reply

      I didn’t even know you could use HTML in the “About Me” section. Learn something new everyday! :)

    • Peter 6:14 pm on April 16, 2013 Permalink | Reply

      +1 for Otto!

    • Chuck Reynolds 6:26 pm on April 16, 2013 Permalink | Reply

      never had my about section filled out. html ftw. thx – good setup.

    • realloc 7:50 pm on April 16, 2013 Permalink | Reply

      +1 Excellent!!

    • Syed Balkhi 8:43 pm on April 16, 2013 Permalink | Reply

      Sweet. I just added authorship on my profile :)

    • Crunchify 8:52 pm on April 16, 2013 Permalink | Reply

      Great Tips. I’ve just updated my profiles..

    • Andrey "Rarst" Savchenko 9:13 pm on April 16, 2013 Permalink | Reply

      Had you considered implementing `link rel=”author” url=”[g+ profile]“` in plugin pages header? It will simplify setup and won’t need that “indirect” connection through profile page.

      • Samuel Wood (Otto) 9:17 pm on April 16, 2013 Permalink | Reply

        That would require us to set up a special field somewhere for a G+ account, and if that social-network, then why not add others too, and yadda-yadda..

        This was a freebie, basically. I didn’t have to make any code changes to do it. We’ve had rel=author in there pointing to profiles forever, and the schema.org markup has been there for at least a year or more.

        I just noticed that I seemed to have been the only one to have done this already when I was looking through some search results today, so I felt like a post to show people how was in order. I did fiddle with the markup a bit today for other reasons, but not for this post.

    • Marcel Brinkkemper 9:14 pm on April 16, 2013 Permalink | Reply

      This is great stuff. +1 for @rarst suggestion

    • Jon Brown 1:32 am on April 17, 2013 Permalink | Reply

      This is fantastic Otto, Thanks for the detailed write up. Would have taken way longer than I have patience to figure it all out on my own.

    • takien 2:45 am on April 17, 2013 Permalink | Reply

      Done, thank you :)

    • toddhalfpenny 9:35 am on April 17, 2013 Permalink | Reply

      Absolutely brilliant… lovely work… thanks.

    • Eric Amundson 2:26 pm on April 17, 2013 Permalink | Reply

      Thanks for the write-up, Otto.

      Looks like the WP.org plugin repo alphabetizes plugin contributors, correct?

      In trying to connect my profile, I found that the Rich Snippet Testing Tool, I get an error saying:

      “Note: The testing tool currently only checks the first rel=author link listed on a webpage for a link to a Google+ profile”

      Issue is that a former contributor has a name that starts earlier in the alphabet, so it’s always finding his author link first, but since he’s not linking to Google +, his avatar isn’t showing in results.

      Any ideas on how to force Google to see the profile of the correct user?

      • Samuel Wood (Otto) 2:36 pm on April 17, 2013 Permalink | Reply

        I don’t think it is sorted, actually. I think it shows up in the order in the Contributors line in the readme.txt file. But if you have an example I can see, I can track the code down.

        • Aaron D. Campbell 8:10 pm on April 17, 2013 Permalink | Reply

          Google “WordPress Twitter Widget” and you’ll see Sara’s pretty face, and she’s the last contrib in the list. However, check the Rich Snippet Tool and it shows me. I’m the first contrib in the list. I’d prefer it to show Range, but that one’s in the middle.

          I’m not certain this is the pattern, but that seems to be what’s happening now. I’ll try to tweak the contrib list on a few plugins and see what happens.

          • Samuel Wood (Otto) 8:17 pm on April 17, 2013 Permalink | Reply

            The readme.txt for that plugin has the people in the same order as the author listing on the sidebar does:

            http://plugins.svn.wordpress.org/twitter-widget-pro/tags/2.5.3/readme.txt

            I have no idea how/why Google shows faces or chooses between them. The rich snippets tool says first one wins, but this is neither the first nor the last time that Google has given me false or contradictory information.

            • Aaron D. Campbell 8:22 pm on April 17, 2013 Permalink

              Yeah, the rich snippets tool says the first wins (and displays the first person), but actual Google searches seem to be showing the last. Since you’re right about the order of contribs matching the readme, I’m going to try reording some to see what happens.

            • Aaron D. Campbell 6:33 pm on April 18, 2013 Permalink

              I gave it a little over 24 hours after the change, and as best as I can tell, Google just likes Sara better. She seems to be listed no matter the order. It may still be cached, but either way it’s still really cool.

              https://www.google.com/search?q=WordPress+Youtube+Upload+Widget
              https://www.google.com/search?q=WordPress+WP+Google+Analytics
              https://www.google.com/search?q=WordPress+Twitter+Widget

            • Samuel Wood (Otto) 6:37 pm on April 18, 2013 Permalink

              24 hours isn’t enough time. Those things likely won’t alter for weeks or more. I know WordPress.org is well-indexed by Google, but seriously, their snippets logic is confounding sometimes. Best to just set it the way you want and let it do its own thing. You can’t force it.

              Mine didn’t start showing up until I changed my G+ pic to be a “recognizable headshot”. Guess they don’t like my scuba avatar. It’s a shame too, I like the blue one.

            • Samuel Wood (Otto) 6:20 pm on April 20, 2013 Permalink

              After screwing around with this for a while, and reading up on the topic, Google seems to get very, very confused with multiple rel=authors. So I just now changed it to only have one rel=author on the plugin page, and that will be the first person listed.

              Hopefully, this should eliminate the ambiguity and cause more predictable results.

    • Brad Dalton 8:56 pm on April 17, 2013 Permalink | Reply

      Been using this link on my profile for a while already but didn’t add the ?rel=author to the end of the Google url which does make a difference.

    • Mert Yazicioglu 9:31 am on April 20, 2013 Permalink | Reply

      Before doing this, my plugin WordPress Move was the second result in Google when you searched for “wordpress move”. Now, however, it’s on the third page.

      Not sure if it’s a coincidence.

  • Ipstenu (Mika Epstein) 1:51 am on April 11, 2013 Permalink | Reply
    Tags: , api   

    Google Maps JavaScript v2 API To Be Removed 

    If you’re using the Google Maps JavaScript API v2 (and 78 of you are), your plugins will break on May 19th. This means we’ll not be accepting any plugins that use the old code (and probably will close your plugins that do if you don’t fix ‘em).

    From Google, Google Maps JavaScript v2 (Deprecated)

    The Google Maps JavaScript API Version 2 has been officially deprecated as of May 19, 2010. The V2 API will continue to work until May 19, 2013. We encourage you to migrate your code to version 3 of the Maps JavaScript API.

    The Google Maps API lets you embed Google Maps in your own web pages with JavaScript. The API provides a number of utilities for manipulating maps (just like on the http://maps.google.com web page) and adding content to the map through a variety of services, allowing you to create robust maps applications on your website.

    The Maps API is a free service, available for any web site that is free to consumers. Please see the terms of use for more information.

    To use the Maps API on an intranet or in a non-publicly accessible application, please check out Google Maps API for Business.

    So please update your plugins.

    (Props to Kailey Lampert for this post)

     

  • Jon Cave 7:38 pm on April 9, 2013 Permalink | Reply
    Tags: security   

    Review an intentionally vulnerable plugin 

    Imagine that another plugin author has asked you to look at a plugin that is currently in development to check for security flaws and help them fix any that are present. Would you know what to look for and how to fix the problems? Well, a fun challenge has arrived that will test, and hopefully improve, your knowledge in this crucial area of plugin development. I have developed a small, bug ridden plugin that requires a rigorous security review and suggestions for fixes.

    The code is available from https://gist.github.com/joncave/5348689.

    This is an incomplete plugin that aims to log any failed login attempts. Unfortunately, it actually harms the security of a site rather than enhancing it. All of the interesting parts are in vulnerable.php, so you should focus your review there. Please remember not to run this plugin on any server that is accessible to the internet!

    If you spot a vulnerability whilst reviewing the code then make a note of the problem, where it’s located and what the problem is. Then come up with a patch that would solve the problem. It might also be beneficial to create a request that would demonstrate the vulnerability which can then be used to test your fix. I hope that this process will help you understand more about vulnerabilities, what sorts of things to look for when reviewing your own code, how to go about coding securely, and how to fix any problems in your own plugins if a flaw is found.

    If you would like individual feedback on your finding and solutions, and to provide me with some information on which bugs people found and fixed, you can submit them via this survey. Please refrain from posting any spoilers in the comments for now.

    In a week or so I will write another post detailing each of the vulnerabilities present in the code and how to fix them.

    Bonus challenge: with access to a subscriber level account can you find any ways of extracting the data from an option named secret_option?

     

  • Ipstenu (Mika Epstein) 4:17 am on February 7, 2013 Permalink | Reply
    Tags: twitter   

    Do You Write Twitter Plugins? 

    Version 1.0 of their API is going away very soon, so if you happen to be using that, your plugin will break.

    You should keep up with Twitter’s Calendar and update your plugins to the latest versions of the API as soon as possible to prevent angry users and broken plugins.

     

    • Ben Lobaugh 4:20 am on February 7, 2013 Permalink | Reply

      Thanks for the updates Ipstenu! Blasting out to my followers and the WordPress Seattle community!

    • whiletrue 11:13 am on February 19, 2013 Permalink | Reply

      Hi all, we released today a quick update for the “Really Simple Twitter Feed Widget”, requiring users to create their own Twitter Application. It’s online and working with full 1.1 API support. Our two other Twitter based plugins will be updated soon.

      We’re also working on a simpler way for authenticate users, providing a custom Twitter Application and the 3-legged authorization method. What are you doing about it?

    • Workshopshed 3:17 pm on February 20, 2013 Permalink | Reply

      I abandoned development on my twitter badge plugin because of these changes, it used client side javascript and hence can’t be made to work without significant changes. I’m currently using Twitter’s own widget but I’m not entirely happy with it. The Really Simple Twitter Feed Widget, seems like it should work for me.

    • Aaron D. Campbell 4:52 pm on March 4, 2013 Permalink | Reply

      Just under the wire, but I did get the release out! The new Twitter Widget Pro (2.5.0+) uses the new API – http://wordpress.org/extend/plugins/twitter-widget-pro/

    • JumboClicks 6:26 am on April 13, 2013 Permalink | Reply

      Don’t you love chasing API changes .. if its not twitter its amazon .. oh its just working perfectly now and it almost looks nice too… wait api change .. OH JUST COME ON .. heh

  • Jen Mylo 11:36 am on December 28, 2012 Permalink | Reply
    Tags: stats   

    Plugin/Plugin Team Stats 

    We don’t track our progress as a project very well. We have relatively few stats that we look at over time to see how we’re growing/changing, and those we do have are largely cobbled together with various combinations of manual labor and scripting. One of the things I want to do this year is get us going in the direction of collecting stats on our work and participation levels, and to make as much of it as possible an automated process. I recognize that this stuff is non-trivial. That said, I can’t create an overall wishlist for Otto to shoot down until we figure out what stats would be good to have.

    What stats would be useful/helpful/just plain cool to know around your team? This is brainstorming… don’t think about APIs or if/how it could be collected, just throw out ideas in the comments of what information you think it would great to start seeing, say on a monthly basis. List any and all ideas, including stats you are already collecting. I’ll collate all the teams’ ideas and see what the Meta team says we can do.

    @coffee2code: As team rep, can you try to rally your group to make suggestions over the coming week? Thanks!

     

    • Jane Wells 11:40 am on December 28, 2012 Permalink | Reply

      I’ll start off by listing stats similar to the ones suggested for themes:

      • Number of plugins in the directory (total, updated within past year, within past x months, etc)
      • Number of plugin developers in directory, high/low/average number of plugins per developer
      • Number of active plugin reviewers, high/low/average number of themes reviewed per person
      • High/low/average frequency of plugin updates/commits
      • Length of time from plugin submission to approval
      • Number of plugins per month accepted as is, rejected flat out, or given instruction on what to do to get accepted
      • Number of plugins closed at author request, and high/low/average amount of time since those plugins were last updated
      • Number of plugins closed for spam
      • Number of plugins closed for security issue
      • Number of plugins closed for breaking a directory rule

      • Ipstenu (Mika Epstein) 3:41 pm on December 28, 2012 Permalink | Reply

        Length of time from plugin submission to approval is averaging just around 48 hours, for a complete, fully working, plugin with a readme and no guideline violations (which is what ‘directory rules’ are). Once we get into people whom we push back, it’s as much up to their ability to reply to emails within 7 days as our ability to sort through the email ;) (holidays and weekends and ZOMG! busy! change that, ut we’re pretty good).

        We’d need a way better way to track why a plugin was closed for the last four. Right now we have to document manually.

        • Jane Wells 4:44 pm on December 28, 2012 Permalink | Reply

          “This is brainstorming… don’t think about APIs or if/how it could be collected, just throw out ideas in the comments of what information you think it would great to start seeing”

          In other words, don’t worry about how it could or couldn’t be done, that’s a different conversation.

    • Marcus 1:57 pm on December 28, 2012 Permalink | Reply

      Number of plugins “compatible” with latest version(s) of WP

      • Ipstenu (Mika Epstein) 3:42 pm on December 28, 2012 Permalink | Reply

        Marcus – the problem there is we don’t test them after submission, so it’s up to the developer to remember to update their readmes. And the lack of an update doesn’t mean the plugin isn’t compatible. That distinctions way too wibbly-wobbley to rely on.

        • Jane Wells 4:44 pm on December 28, 2012 Permalink | Reply

          I think Marcus’s suggestion is a good one. At the very least, gathering the stats on which ones say they’re compatible to which version will be useful.

        • Marcus 1:12 pm on December 29, 2012 Permalink | Reply

          True, but that’s why I used quotes when saying “compatible” :D

          Agreed it’s not perfect, in my case for example I do have some plugins that aren’t marked as compatible for the latest version (haven’t had time to update readmes), yet they are.

          I think it’d still be nice to know because it is still somewhat of an indicator of what plugins are getting updated for latest WP updates.

          I’d say another bit of data that could be use is the Works/Doesn’t work, but then this info isn’t that reliable either I’ve found.

    • Charleston Software Associates 3:37 pm on December 28, 2012 Permalink | Reply

      Plugin aging report = number of plugins in these groups: updated 0-30 days ago, 30-90 days, 90-180, 180-365, 1y+. Provides a general “age” of the plugin repository at several strata.

      Is the plan to publish this for the general public somewhere near the plugins home page? Some of these metrics would be nice to know for site developers & plugin authors.

      • Jane Wells 4:46 pm on December 28, 2012 Permalink | Reply

        There’s no plan yet, since none of these stats are being collected yet. Eventually I’d like to be able to post nice monthly stats reports on the wordpress.org blog, and team-specific stats could also live in the team site and the public sections of wordpress.org. First we need to decide what information is worth having, then figure out how/if we can gather it, THEN decide where it gets published.

    • Pippin (mordauk) 11:32 pm on December 28, 2012 Permalink | Reply

      Number of abandoned plugins (ones without updates for 2 years).
      Number of plugins with over xxx downloads.

      • TCR 1:01 pm on January 22, 2013 Permalink | Reply

        Agree with these. would be useful to have a filter on the plugin searches to exclude plugins that haven’t been updated for 2 years. etc.

        • jquindlen 5:35 am on April 12, 2013 Permalink | Reply

          I love this idea, it would save me so much time, and I think many other users would agree.

    • circlecube 6:26 pm on January 8, 2013 Permalink | Reply

      What about plugin ratings? Across all the teams plugins it could average the ratings or show the best rated plugin. Most reviews.

      Number of updates would be useful too (and/or frequency of updates), then you know if the plugin is tried and true or just went from 1.0 to 3.0.

    • rielf 7:07 pm on January 20, 2013 Permalink | Reply

      Where i can denounce a SCAM Pluguin?

      “Google adsense plugin” is scam….

      1: His donation system don t respect the google adsense terms and conditions and any google adsense account can be baned

      2: I insert my PUB correctly and all adds are from the pluguins programers.

      3: I setup de donation sistem in 0% and they are stealing my adds space whitout pay me.

      __________________________________________________________________
      And i want to say that this pluguin is the worst adsense pluguin i never sawed, his configuration are simply ridicolous and you only can put the adds in the post….

      • Scott Reilly 5:03 pm on January 21, 2013 Permalink | Reply

        You should email plugins@wordpress.org to report abuse or spams/scams by plugins. Please include a direct link to the plugin’s page in the Plugin Directory so we know precisely which plugin you’re referring to.

    • Mark 10:45 am on January 29, 2013 Permalink | Reply

      Plugins, that are already outdated or haven’t used in years, can clearly be seen. Moreover, before updating the version, make sure it is compatible and last but not the least, don’t keep those plugins for too long that appears to be Spam/abuse and report them at your earliest!

    • zoranc 1:28 am on February 7, 2013 Permalink | Reply

      polling systems on the main plugin page(+api so it can be included in the plugin settings pages). This way users would be able to vote on features and overall plugin direction

    • David Lingren 8:53 pm on April 23, 2013 Permalink | Reply

      How about more information on the Support topics, e.g., average response time, time to resolve, number of unresolved topics? As a plugin author, one of my most frustrating tasks is looking back over all the topics and trying to find the items marked “Not Resolved”. I keep tripping over the “Not a support issue” topics.

    • Dorie Fenimore 11:20 am on May 15, 2013 Permalink | Reply

      skincare rejuvenation botox training course in sheffield

  • Jen Mylo 1:28 pm on December 24, 2012 Permalink | Reply
    Tags:   

    Team Rep Results 

    9 people voted. Results: Scott Reilly as first lead, Pippin Williamson as second lead. New team rep terms starts with the new year, so I’ll get in touch with you guys to make sure everyone is on the same page re expectations. Congratulations, and thanks for your willingness to serve!

     

  • Ipstenu (Mika Epstein) 5:31 pm on December 20, 2012 Permalink | Reply
    Tags: gpl,   

    GPL and the Repository 

    All plugins hosted in the WordPress.org repository must be compatible with GPLv2 or later. That means all code that is on our servers, from images to CSS to JS to the PHP code, has to meet that requirement. This is an extra requirement than just the standard one of derivative code, but we strongly feel that proprietary content has no need to be in our repository. If your code needs to be split licensed, or you have to included proprietary code for any reason, we can’t host you on .org, but that has no bearing on how neat and cool your code might be.

    For a list of various licenses, and their compatibility with GPLv2 please read this: http://www.gnu.org/licenses/license-list.html – We know not all of you are lawyers, and thankfully that list makes it easy to check what licenses do and don’t mesh. If something doesn’t have a license, ask the author please, and don’t assume.

    The following code bases are popular (which is to say we see submissions with them pretty regularly), but at the time of this post, are not licensed GPL-compatible. None of this means you can’t or shouldn’t use this code on your sites or plugins, just that we can’t host it here if you do.

    If there are plugins you find using these (or any non-GPL-Compatible) code bases in their plugin, please email plugins AT wordpress.org and we’ll get in touch with the developer. If you’re the author of one of those code bases, please consider re-releasing your code under a GPLv2 Compatible license! We’d love to be able to host your work here.

     

    • Mike Schinkel 5:44 pm on December 20, 2012 Permalink | Reply

      Great points @ipstenu.

      It would be helpful if you could explicitly clarify something though. In some cases the required functionality is really only available via commercially licensed software; I’m working on just such a plugin right now. I assume that it’s acceptable to publish a GPLv2+ licensed plugin that requires the commercially licensed software as a library but that puts the onus on the user to acquire a copy of said commercially licensed software? Thanks in advance.

      -Mike

      • Ipstenu (Mika Epstein) 6:17 pm on December 20, 2012 Permalink | Reply

        Mike – That’s a real sticky situation, and we try to judge each one individually. If the entire purpose of the plugin requires you to download non GPL software, we probably won’t approve it. But if some additional functionality requires it (like Viper’s Video Quicktags says you have to download FLV if you want to use that), it’s okay.

        • Mike Schinkel 8:04 pm on December 20, 2012 Permalink | Reply

          Really? Not what I expected to hear.

          I have an Export Post Content to MS Word plugin I’m working on for a client and it requires PHPDOCX and I have been thinking it would be nice to package it up and put in the plugin repository for those who need MS Word export.

          P.S. Of course I guess I could limit the functionality significantly and bundle their LGPLversion but that’s take recoding work and I might not get to it anytime soon.

          • Ipstenu (Mika Epstein) 8:20 pm on December 20, 2012 Permalink | Reply

            I did say probably. It’s a lot of case-by-case, but we’re trying to avoid situations where you download plugins that outright don’t work, because you have to install other stuff. (Obvious exceptions would be bridge software, that connects WP to other apps.)

            • Jane Wells 1:27 pm on December 24, 2012 Permalink

              we’re trying to avoid situations where you download plugins that outright don’t work

              +1

          • imranpak 1:50 pm on March 6, 2013 Permalink | Reply

            Hello Mike,

            Please share that plugin with me.

            Thanks,

            Imran

    • Charleston Software Associates 5:46 pm on December 20, 2012 Permalink | Reply

      jQuery Lightbox? There are a ton of plugins I’ve used for client sites that include that script.

      Does this mean if a plugin sources the script from another source, like Google Code for example, it still is not GPL compliant? For example, the files bundled with the plugin do not contain the actual jQuery Lightbox code but simply a for example?

      I don’t think any of my plugins are doing this but good to know what the nuances are. Especially since I’m planning a WordPress driven streaming radio plugin + companion client plugin and considered some of the very items you have on this list!

      • Charleston Software Associates 5:48 pm on December 20, 2012 Permalink | Reply

        Keep forgetting my code block on comments!

        • but simply use an a href = “..otherURL/jqlightbox.js” for example

      • Ipstenu (Mika Epstein) 6:19 pm on December 20, 2012 Permalink | Reply

        Read the URL we linked to. Says pretty clearly

        “This work is licensed under a Creative Commons Attribution-Share Alike 2.5 Brazil License.”

        That’s not compatible. However remember this rule is only to be hosted on .org. We’re not talking about using for clients, just in plugins we host for you :) Does that make sense?

        Edit: As long as the code ins’t included in the plugin we have on .org, it’s okay. We do discourage telling people to download it from external sources (see Mike’s comment above you), but we take them case-by-case.

        • Charleston Software Associates 7:11 pm on December 20, 2012 Permalink | Reply

          @Ipsentnu – Thanks Mika, I get it. I meant that I’m using plugins found on the .org directory that contain jQuery Lightbox scripts IN the trunk svn repo hosted on the .org site. Many of those (see related comments) are carrying along scripts that specifically cite licenses that are NOT GPLv2 compatible, like the jQuery Lightbox script you reference in the original post.

          Now that those client sites are deployed I’m not so interested in that SPECIFIC issue. However my media streaming system will require pieces that are not readily available in GPLv2 format. I guess, based on your response to Mike, that I’ll have to find a way to marginalize those pieces and keep them out of the repo.

          Is it OK to say “if you want to use feature X” you will need to download “Y”? In my case I’d need a creative way to get the FLV player installed for the client listener. Thinking out loud here… Maybe hooks + filters that look for a “ride along” plugin that simply extends the feature set with “FLV fallback for non-HTML5 browsers”.

          Sorry for all the posts. I’m working on a big project and was planning on using WordPress as a key piece for the backend & front-end UI elements. Fully understanding this is kind of important before development starts in earnest next month.

          • Lance

          • Ipstenu (Mika Epstein) 7:41 pm on December 20, 2012 Permalink | Reply

            The answer is ‘maybe.’

            If the entire use of your plugin hinges on non GPL code, then probably not. If it’s just an extra feature, then probably yes.

            And like I said, if you see plugins in the .org repo that are using those specific versions of the code (check the links, lots of people use the same names), then please email us :)

      • Charleston Software Associates 6:53 pm on December 20, 2012 Permalink | Reply

        Lets try some examples just so I am really clear on this. I’d hate to put a lot of time into a plugin and have it not listed here after months of work because of a license conflict.

        This plugin (a fairly popular one) has a modified port of jQuery Lightbox:
        http://wordpress.org/extend/plugins/wp-jquery-lightbox/

        The modified port is itself questionable because it does not retain the original license but instead says “BSD license for details refer to license.txt” (license.txt is missing, BTW which is ANOTHER subtle but important point about software licenses, I’ll leave that discussion for later). The Gnu link provided makes it sound like Original BSD is NOT compatible with GPL only “Modified BSD” or “3-Clause BSD” is compatible.

        This can/will get confusing in a hurry. Maybe WordPress should host a list of known licenses that will not be accepted and post it somewhere near the plugin authors/submission page. The Gnu list is a great start but could be made easier to follow for non-legalish people like myself.

        • Lance

        • Samuel Wood (Otto) 7:11 pm on December 20, 2012 Permalink | Reply

          There is more than one project named “jQuery Lightbox”, because “Lightbox” itself was quite popular and spawned more than one imitator. Some of these imitators are compatible, some are not. The one you linked to is compatible. The one Mika linked to is not.

          Regarding “BSD”: nobody uses the “original BSD” license, pretty much ever. When somebody says “BSD-licensed”, it’s an almost 100% certain bet that they are referring to the modified BSD license. I have *never* seen a use of the original BSD license, ever.

          WordPress has no plans to make any sort of list of which licenses are acceptable or not, because we don’t have to. That list on gnu.org is fairly extensive and covers the vast majority of licenses out there. Any others we can evaluate on a case by case basis.

      • Charleston Software Associates 7:00 pm on December 20, 2012 Permalink | Reply

        Here is another one… as noted, this gets confusing in a hurry…

        http://wordpress.org/extend/plugins/jquery-lightbox-balupton-edition/

        This plugin clearly cites AGPL version 3.
        http://plugins.trac.wordpress.org/browser/jquery-lightbox-balupton-edition/trunk/scripts/jquery.lightbox.js#L28

        AGPL v3 *is* GPL compatible, but here is the catch, it is specifically NOT GPLv2 compatible, thus the entire plugin is considering “not GPLv2″ compatible.
        http://www.gnu.org/licenses/license-list.html#AGPLv3.0

        Am I understanding this correctly?

        • Ipstenu (Mika Epstein) 7:45 pm on December 20, 2012 Permalink | Reply

          Do me a huge favor. Take a deep breath :) You sound like you’re panicking here, and there’s no need to. We’re not making cancer fighting tools here, just code. All this can be fixed and sorted out, if we all stay calm and take our time.

          AGPL is messy. We’ll have to look into that one closely. I don’t have an answer for you right now.

          And note: GPLv2 or later. GPLv3 is okay.

          Edit: Actually he can just upgrade to the MIT version of the code – https://github.com/balupton/jquery-lightbox – I’ll email him.

          • Charleston Software Associates 8:36 pm on December 20, 2012 Permalink | Reply

            Thanks Mika. Not panicked, just trying to get clarification with some examples for reference.

            Another company I worked with had plugin listings pulled from .org for non-compliance. Related premium add-on sales went from $250/day to $0 instantaneously. Before I put months of effort into my new project I want to make sure I do all I can to maintain a good relationship with .org.

            It is 100% clear now. There may be some gray area that will be evaluated on a case-by-case basis. In over-simplified terms, don’t use the directory as a “free advert” for non-GPLv2 stuff.

    • toscho 2:47 am on December 21, 2012 Permalink | Reply

      Please close the last link. :)

    • Fabien 11:44 am on December 21, 2012 Permalink | Reply

      Many thanks to you for what you are doing for the free software community ! Long live the GPL !

    • takien 4:02 pm on February 8, 2013 Permalink | Reply

      Hello, I’m writing ClipArt plugin (submitted to .org and currently being reviewed).

      What plugin does:

      • Search clipart images from openclipart.org, (Images is licensed as Creative Common).
      • Save image into user’s WordPress, and insert into post if they wish.

      Will this cause a problem? While images are not hosted here (wordpress.org).

      Thank you.

      • Ipstenu (Mika Epstein) 7:56 pm on February 8, 2013 Permalink | Reply

        The images are different.

        We care if the code and images in the plugin itself are GPL compatible. If the stuff you install to your site later via image uploads isn’t, well that’s on you :) That should be fine. (FYI, we’re backlogged on reviews by a couple days)

← Older posts

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel