WordPress.org

Make WordPress Plugins

Updates from April, 2016 Toggle Comment Threads | Keyboard Shortcuts

  • Ipstenu (Mika Epstein) 3:41 pm on April 13, 2016 Permalink |  

    [Somewhat Resolved] Assets/Readmes not showing properly on Plugin Pages 

    1624 UTC – Tue 19 April

    This is MOSTLY resolved, but basically we’re going to be facing sync issues for a while until someone sorts out why they’re getting so behind. The best thing to do here is to WAIT and not push anything. The more you push, the longer the queue gets and slower it gets :/

    1541 UTC – Wed 13 April

    We are aware of an issue where your assets (banners etc) and readme information isn’t loading properly, and we are looking into it.

    Please DO NOT push your code multiple times! It’s like ringing a doorbell over and over. It doesn’t actually make things work better 😉

    As a general reminder, though, please try to keep your readme to under 10k. You can shuffle your changelog off to a separate file (chaneglog.txt) to keep things smaller. After all, no one really reads the 1.x version of your changelog from 6 years ago.

    In addition, if your plugin is very large, it’s okay to remove old versions from SVN. That will ensure processing and syncing is faster 🙂

    We will update this post with any information as we determine exactly what’s wrong.

    Update 1: One of the servers is running behind again. So please just be patient. Go for a run. Dance. Sing. It’ll catch up 🙂

    Update 2: Still running slow. There are moments where this will work fine, and then it will drag. Sorry.

     
  • Ipstenu (Mika Epstein) 5:58 pm on March 1, 2016 Permalink |
    Tags: , ,   

    Please do not submit frameworks 

    Note: We are aware that some frameworks are current in the repository. We are asking you not submit any NEW at this time.

    This isn’t a new ‘rule.’ It’s not a secret one either. It’s not listed in the guidelines specifically because any attempt to lay down each and every reason a plugin shouldn’t be in the repository just ends in people rule-lawyering. Should we have to tell people “Don’t ask users to write to your plugin files”? No. That should be self-evident. A plugin gets replaced when it’s upgraded, so writing to plugin files means the changes get destroyed. And in many ways, that’s our problem here.

    The issue is as follows: Having a framework as a plugin is a poor experience for the user. Not the developer. The user. The user understands “I have an add-on for WooCommerce, I probably need Woo.” They do not always understand “I have plugin Slider Joe. Why do I need Advanced Custom Fields?” In addition, by having a library as a plugin, the onus of version compatibility is now on the person least likely to understand it: the user.

    The plugin repository is not, currently, a library or framework repository. It’s not meant like the NPM package manager, or even Composer as a way to define what a plugin ‘needs’ in the same ways for a developer to build a project. The plugin repository is, plain and simple, meant for plugins that users will find useful. Plugins that add functionality to WordPress in a directly inter-actable way.

    We don’t allow people to add javascript or fonts on their own to the repository and, I suspect, most of you would nod and say “Well of course not. A font and javascript should be included in the plugin or theme!” We feel the same way about most full blown library and framework plugins too. The user doesn’t need to know or care about the libraries. They shouldn’t be expected to be responsible for it.

    At this time, we are not accepting frameworks as we don’t feel frameworks, boilerplates, and libraries are appropriate for the Plugins Directory. We require that plugins be useful in and of themselves (even if only being a portal to an external service). And while there are many benefits to frameworks and libraries, without plugin dependency support in core or the directory, it becomes another level of hassle for users.

    The parade of likely support issues:

    • Not recognizing the framework plugin, and thus deleting it (causing the plugin(s) to break)
    • Not recognizing the framework plugin and thinking they’ve been hacked
    • Debugging drama, when we tell them to disable all their plugins and they find its a library problem
    • Updating the framework plugin separately from the dependent plugins, possibly leading to breakage
    • Updating a dependent plugin without updating the framework, possibly leading to breakage
    • Plugins not keeping up with library changes to the point that they break
    • Different plugins requiring different versions of the framework

    And bearing in mind that the framework and plugin developers are different people, that’s another level of coordination/compatibility issues. A developer is (in theory) clever enough to write their plugin in a way that it includes the version of the library they need in a way that will not break everyone else. Of course, you developers know that’s a goal and not an absolute.

    Frameworks and libraries should be packaged with each plugin (hopefully in a way that doesn’t conflict with other plugins using the framework or libraries). At least until core supports plugin dependencies.

    Making this messier is the fact that once a library is in the repository, you shouldn’t put it in your plugin anymore. Why not? Well what happens if they install a library as a plugin, while having the library inside a plugin already? Which one takes precedent? What happens when they’re out of sync and so on? See the goal up above that isn’t an absolute. It gets even messier.

    A library is a library, and should be in the plugin, not separate.

    Maybe one day we’ll have proper plugin dependencies, but we simply are not there yet.

     
    • JasWSInc 6:18 pm on March 1, 2016 Permalink | Log in to Reply

      Argh!! We have been working on a framework with the expectation that it would be hosted in the plugins repo in the near future. Shipping it with every small plugin is, shall I say, less than ideal

      Since that is the only solution at this time I guess we will have to work around this limitation. Really wish there was a package manager in WP core.

    • vovafeldman 6:20 pm on March 1, 2016 Permalink | Log in to Reply

      Great explanation! Several devs asked to add Freemius Insights to the repo – as much as I love the idea of automatic updates mechanism, the UX would be terrible. But yeah – a package manager in WP core could be a fantastic addition.

    • NateWr 6:30 pm on March 1, 2016 Permalink | Log in to Reply

      Thanks for spelling this out in more detail, Ipstenu. I wonder if I can poke a little further regarding where you draw the line.

      For instance, Cool Thing for WooCommerce seems like an obvious candidate. But what about plugins that make use of the REST API v2 plugin? We’re being actively encouraged to build such plugins by lead WordPress developers. But the REST API provides no user-facing features and plugin integrations are not necessarily clear to the user (one big reason it hasn’t been taken up more completely).

      There are also a whole host of dev tools which, though they may provide user-facing features, are only meaningful to developers (Query Monitor, Debug Bar, etc).

      Then there are the plugins which can provide a common framework or API for managing a feature, but which are not useful unless specifically activated in code. Jetpack’s Site Logo feature (now considered for core) is a good example.

      These examples may seem like clear yes/no’s to you. But I’m not sure exactly where the line is drawn.

      Here’s an example of something I’ve been working on:

      https://github.com/NateWr/content-layout-control

      I was hoping to turn this into a plugin once it matured and stabilized, but since it is essentially a library which provides an architecture for managing content in the customizer, I suspect it wouldn’t be allowed.

      • Ipstenu (Mika Epstein) 6:51 pm on March 1, 2016 Permalink | Log in to Reply

        The line between a dev plugin and a dev library is tricky. Debug Bar and Query Monitor run, and need you to change nothing in your code for them to work. If you have to edit the code of your plugin or theme for the ‘dev tool’ to work, it shouldn’t be a plugin. Does that make sense?

        The rest v2 api is one of those rare exceptions where the greater good of a feature plugin trumps the absolute letter of the law. It’s adding a feature to core which is usable right away, out of the box, but in a very, very weird way. Which kind of describes the whole API project IMO.

        If you had a plugin that disabled XMLRPC, even without an interface, we’d allow it. Right? It changes a feature of WP. That’s cool. Similarly, plugins that require the JSON API and add features to it are okay because the intent of the API is to be in core. Some of it is already in core to boot.

        Rest v2 plugins are fine right now. I like them best when they’re wrapped into their parent plugins (like Woo adding a whole mess of ‘if the rest API is here, add these features too!’) but the whole featured plugin thing is another discussion.

        Looking at that specific plugin, as it is already, it integrates more features into customizer and is probably just fine. Also pretty cool. I’d have to see the code and use it to know for sure (yes, I test plugins 😉 ) but the intent is a library with some built in functionality for changing the customizer as is, so it looks fine.

        • NateWr 7:44 pm on March 1, 2016 Permalink | Log in to Reply

          Thanks for the clarification!

          • Ahmad Awais 2:01 pm on March 2, 2016 Permalink | Log in to Reply

            Hey, Nate!
            This is really interesting. Let me know how can I start using it? I believe there are no docs about it at the moment. I like the concept very much and was planning on doing something similar.

            • NateWr 9:13 am on March 3, 2016 Permalink

              Hi Ahmad, it’s not really ready for general use yet. Still a few hiccups that need to be solved. But when it is I’ll write some simple docs, tweet about it @NateWr. If you want to know when docs are created, open an issue on the GitHub repo asking for them and I’ll update the issue as I move forward.

    • TIV.NET INC. 6:33 pm on March 1, 2016 Permalink | Log in to Reply

      @Ipstenu,

      > A library is a library, and should be in the plugin, not separate.

      What about conflicting versions? The first who loads the library – wins? Others – suffer. And probably fail to work.

      We had that with Redux Framework embedded in WPGlobus. If a theme has an older (or a newer?) version, there is a conflict. When we both use Redux as a plugin – no conflicts.

      • TIV.NET INC. 6:36 pm on March 1, 2016 Permalink | Log in to Reply

        I see…
        > (hopefully in a way that doesn’t conflict with other plugins using the framework or libraries)
        Well, the keyword is “hopefully”….

        • Ipstenu (Mika Epstein) 6:58 pm on March 1, 2016 Permalink | Log in to Reply

          It can totally be done. CMB2 does it marvelously. It’s up to the developer to add the library in an intelligent way, and keep up with its development.

          And that doesn’t change if it’s a separate plugin, by the way.

          Plugin A uses Redux 1
          Plugin B uses Redux 1.3
          Theme C uses Redux 2
          Redux 1.5 is installed as a plugin

          Assuming Redux won’t break backcompat, what happens when Redux is upgraded to v2? In that perfect world, nothing. Everyone keeps working.

          But… What if Plugin B wasn’t written properly and was taking advantage of an bug in version 1.3? That bug, which no one should have been using, is fixed in V2 and now Plugin B is broken.

          This kind of hassle doesn’t change if you’ve included a library or a separate plugin. It’s no easier one way or the other.

      • vovafeldman 6:51 pm on March 1, 2016 Permalink | Log in to Reply

        We managed to solve it in Freemius by keeping backward compatibility and automatically loading the newest version of an SDK based on the active plugins. So yeah – it’s not trivial, but solvable.

      • NateWr 7:54 pm on March 1, 2016 Permalink | Log in to Reply

        For my own little admin pages library, I actually baked version numbers directly into class names to ensure exact version parity even if multiple plugins are loading different versions.

        It’s a total pain. 🙂

        • Ipstenu (Mika Epstein) 9:10 pm on March 1, 2016 Permalink | Log in to Reply

          Why not do a define for the version number and in the class check, look to see if the plugin is already active with this version or newer? If so, use the more recent version. Else, un-register and take over.

          • NateWr 9:09 am on March 2, 2016 Permalink | Log in to Reply

            Unfortunately there were some big breaking changes that had to happen early in it’s life. 🙁

    • robinwilson 6:37 pm on March 1, 2016 Permalink | Log in to Reply

      wish I knew what a framework was, then I could avoid it !

    • darrinb 8:08 pm on March 1, 2016 Permalink | Log in to Reply

      As someone who literally *just* had a framework plugin submitted and approved last month, I have to say, I totally agree with the premise outlined in this article, but confused on how to handle best practices.

      The initial plugin I submitted, Advanced Term Fields, was designed solely as a framework for other plugins to build on. Out of the box, it doesn’t *do* anything other than provide a structure for child plugins to add custom meta fields for terms. It’s almost an interface. (Almost.) It’s similar to the Fields API currently in development.

      The child plugins; ATF Images, ATF Colors, etc., add the actual functionality. Are you saying the best way to handle this scenario is to include the parent framework in each child plugin, as opposed to alerting the user that “This plugin requires XXX plugin in order to function properly”?

      • modemlooper 8:33 pm on March 1, 2016 Permalink | Log in to Reply

        thats the preposed method

      • Ipstenu (Mika Epstein) 9:09 pm on March 1, 2016 Permalink | Log in to Reply

        Yeah, really this shouldn’t have been approved either :/ We’re having an internal reminder for us to stop and think about this stuff rather than push through approvals.

        . Are you saying the best way to handle this scenario is to include the parent framework in each child plugin, as opposed to alerting the user that “This plugin requires XXX plugin in order to function properly”?

        Currently, yes. That would have been the best way. Since your plugin is approved, though, it’s unfair of us to yank the rug out from under you. While you don’t have a great many users, we recognize when the gaff is us.

        • Scott Kingsley Clark 6:46 am on March 2, 2016 Permalink | Log in to Reply

          Does this mean Fields API shouldn’t / can’t be in the wordpress repo for beta testing? Or other future feature plugins with no UI, such as REST API / Fields API are?

          • Gary Jones 1:33 pm on March 2, 2016 Permalink | Log in to Reply

            We were told that a TGMPA plugin could go into the repo if it was accepted as a featured plugin.

            • Scott Kingsley Clark 3:31 pm on March 2, 2016 Permalink

              Right, but if a feature plugin then stagnates and doesn’t end up going into core, what happens to it under the guidelines, it sort of loses that qualification for being in the repo at that point, I think.

          • Ipstenu (Mika Epstein) 4:57 pm on March 2, 2016 Permalink | Log in to Reply

            Perfect world? Would not be accepted.

            Reality? Feature plugins are currently an exception for practicality.

            It’s not something I personally like, and I think it illustrates many of the issues with the feature plugin project as a whole. But in this case, the goal is to change how WordPress works as a feature.

            Obviously we have to allow for wiggle room, but we see a vast difference between, say, a debugging tool that in order to use, you need to edit your plugin and wrap dd() around everything, and the REST API. That’s a real example, by the way.

        • David Chandra Purnama 12:56 pm on March 2, 2016 Permalink | Log in to Reply

          I don’t think it’s the best way.
          It’s a long post, so I write it in my blog:
          https://shellcreeper.com/i-think-wordpress-plugin-review-team-decision-to-no-longer-accept-framework-is-wrong-and-this-is-why/

          what do you think?

          • Ipstenu (Mika Epstein) 5:00 pm on March 2, 2016 Permalink | Log in to Reply

            I think you actually argued the point for us.

            So, if I install and activate just 1 plugin, it might work. But what if I install and activate all 6 plugins. Which CMB version will load in my site? Will everything work? Is my site secure?

            If you installed and activated 6 plugins, each written for a different version of a library (CMB original in your example), and then upgraded the CMB library plugin to a new version, you have the exact same problem of ‘will my site work?’ and ‘Is my site secure?’

            The only difference you have now is that everyone’s forced to use the same version of CMB.

            • David Chandra Purnama 1:33 am on March 3, 2016 Permalink

              That is not the only difference. If we use framework as plugin:
              1. We definitely get the latest version of the framework.
              2. As framework dev, you can do “backward-compat” but you cannot do “forward-compat” (no time machine). Just like WP maintaining backward compatibility it will give us less problem.
              3. If something goes wrong, it’s easier to debug. to get which one of the dev did it wrong. (not updating/make it compatible to the latest version).
              4. push everything forward.

              And what the benefit of using “framework” as “module” as you suggested?
              1. it’s easier for the user, install one plugin and activate. no additional step.
              2. (kinda) no issue if each plugin use different framework: one plugin use CMB, another use MetaBox by rilwis, another use ACF. (but if 2 or more use the same framework, potential problem).

              In my opinion, this will only give headache in the future. It will seem to reduce support question temporarily. But it’s just dodging the bullet for now (?)

          • Ipstenu (Mika Epstein) 4:36 am on March 3, 2016 Permalink | Log in to Reply

            1. You do not get the latest version of the framework. You get what the END user installs. It’s now totally outside your control. Yay!

            2. Back and forward compat issues are no different between the two. You have to make sure you work with the new version and fail gracefully if someone accidently has the old. Or vice versa.

            3. Debugging is equally as hard. “I upgraded plugin X and now plugin Y broke!” remains true. Really the difference is “Plugin X is framework Foobar” so you can know “Oh I didn’t upgrade MY plugin to work with the new version.” But wait! Now we have another issue! What if plugin Y only works now on the new version of the framework? And we’re right back to conflict hell :/ (Neither method solves this, I feel I should point out.)

            4. I have no idea what ‘push everything forward’ means.

            And what the benefit of using “framework” as “module” as you suggested?
            1. it’s easier for the user, install one plugin and activate. no additional step.
            2. (kinda) no issue if each plugin use different framework: one plugin use CMB, another use MetaBox by rilwis, another use ACF. (but if 2 or more use the same framework, potential problem).

            Issue #2 is the same, regardless of framework as included-library or framework as add-on plugin.

            • David Chandra Purnama 9:00 am on March 3, 2016 Permalink

              What I mean by “push everything forward” was to encourage user to use the latest everything. (if they want less bug).

              I’m sorry, I really want to explain it better, but my lack of skills in english language could be a barrier. I’m sorry if i have to explain it in long sentences.

              If you think about it, it’s similar to “WP – Plugin” relationship.
              WordPress gets updated on regular basis.

              A plugin written 1 year ago (or several months ago) might works/not working with current version of WP.

              WP core make sure it didn’t break by always try to have “backward compatible” update as much as possible. And WP also encourage user to always update to latest version.

              1. You do not get the latest version of the framework. You get what the END user installs. It’s now totally outside your control. Yay!
              If the user didn’t update to the latest version, and their site breaks/have bug. it’s their fault. not the plugin dev.
              and i believe it’s better for WordPress.org to create environment where user can update easier.

              2. Back and forward compat issues are no different between the two. You have to make sure you work with the new version and fail gracefully if someone accidentally has the old. Or vice versa.
              I understand your statement. But a new feature introduces in a plugin update utilizing the latest framework version did not work because another plugin use older feature is “messy” things to explain to user.

              And what’s the point in including the “framework” in a plugin when the plugin don’t even know if it’s loaded from the right version.

              And don’t you think It’s weird to do backward compat to a library included in my own plugin (?) (when it should/expected to be loaded from my plugin).
              I’m think a lot of dev would not want to go extra mile to do that for “included module”. however, if it’s for “external library” (in this case plugin) where the dev also understand that they “should” do version check, etc.

              3. Debugging is equally as hard. “I upgraded plugin X and now plugin Y broke!” remains true. Really the difference is “Plugin X is framework Foobar” so you can know “Oh I didn’t upgrade MY plugin to work with the new version.” But wait! Now we have another issue! What if plugin Y only works now on the new version of the framework? And we’re right back to conflict hell :/ (Neither method solves this, I feel I should point out.)
              But if the user contact the dev for support, it’s a lot easier for the dev to solve the issue.
              “try to swicth to default theme”
              “and deactivate all plugin except this and this framework”.
              “all good?”
              “now activate all plugin one by one until we found the problematic plugin”
              (it’s like the version of “did you turn it on and off again for computer tech)

              And if they found the “problematic plugin” they can contact the dev to update it. or fix it themself, or get proper help, or hire someone (like me, well, it’s my job).

              actually, if less people get less problem with wp. it’s not good for my business 🙂 (j/k)

              4. I have no idea what ‘push everything forward’ means.
              What I mean by “push everything forward” was to encourage user to use the latest everything. (if they want less bug).

              And, actually I don’t have plan to create a “framework” or anything. I did not even use one.

              I did experience issue with CMB in the past because of version issue. And my solution is to fork CMB and prefix everything with my plugin prefix, and also make sure all js scripts don’t explode and play nice with CMB instance (well, basically eat the CMB and make it as part of the plugin).
              It’s not a good experience. not tasty.
              I could just load it earlier than other plugin and solve the issue temporarily, but i also understand that other plugin can “race it” and load even earlier.

          • Ipstenu (Mika Epstein) 2:49 pm on March 3, 2016 Permalink | Log in to Reply

            The thing is, as a dev you still have to concern yourself with backcompat. You still have to make sure your plugin works with old and new versions of a library, and you still have no idea what version of a library is used.

            Literally it’s the same problems.

            It’s actually easier for a user if the dev takes care of all that. No matter what, there will be code conflicts.

            Right now, we ask the developers to ‘push forward’ – we put them in charge of pushing the new libraries and encouraging new versions of code. If they can do it without breaking things, users will want to upgrade.

    • George Notaras 6:36 am on March 2, 2016 Permalink | Log in to Reply

      Hello all,

      Since plugin dependency resolution is not there, this convention makes a lot of sense. But I really think that it should be temporary and the possibility of adding plugin dependency resolution to WP (sooner than later) should be explored. Framework plugins definitely have a place in the repository.

      On the other hand, since this is about a big category of plugins, if dependency resolution isn’t going to be implemented any time soon and this convention is going to be somewhat permanent, I think it’s big enough to have a place in the guidelines, so that any rejections do not look like personal decisions.

      • Samuel Wood (Otto) 6:54 am on March 2, 2016 Permalink | Log in to Reply

        We call them “guidelines” instead of “rules” because we use them as a guide to help us, not as a rule to restrict us. 🙂

        • George Notaras 7:18 am on March 2, 2016 Permalink | Log in to Reply

          Sure, they are there to help, but aren’t they doing so by setting some boundaries? 🙂

          I finally think that making the distinction between a plugin (extensible with action/filter hooks) and a framework is going to be so hard, that dependency resolution will happen sooner than expected! 🙂

      • Ipstenu (Mika Epstein) 5:09 pm on March 2, 2016 Permalink | Log in to Reply

        A rejection is never a personal decision. But it’s always going to feel like one. No matter how we phrase it, people will always see it as personal, and I totally get that. It’s not a good feeling, being told “No.” But what can we do?

        Every single time, we look, read, review, and think about what the plugin is, what it does, and why it does it. We weigh the pros and cons, the goals, the direction, and the ideals.

    • Compute 9:49 am on March 2, 2016 Permalink | Log in to Reply

      So would this be considered a framework plugin that should not be submitted?
      https://wordpress.org/plugins/pco-image-widget-field/

      • Ipstenu (Mika Epstein) 5:11 pm on March 2, 2016 Permalink | Log in to Reply

        Shouldn’t have been approved. Specifically looking at step 3 in your install, yeah.

        Which is not a judgement call on your code quality. I like the code.

        • Compute 11:47 pm on March 17, 2016 Permalink | Log in to Reply

          Meaning that it should be removed from the repository or never have been approved in the first place?

          • Ipstenu (Mika Epstein) 5:10 pm on March 31, 2016 Permalink | Log in to Reply

            Shouldn’t have been approved.

            We should not have approved it.

            We will not remove it because it’s been 5 months, and that would be really mean of us. Five DAYS maybe…

    • Mike 10:15 am on March 2, 2016 Permalink | Log in to Reply

      Searched “framework” in the plugin repository and got almost 1000 hits and 166 in the theme repository.
      So IMO your argument doesn’t stand up to reality.
      Remember the “persuasive” arguments about how safe auto updates were?
      Well they weren’t 100% safe by a long shot.
      Did they stop? NO!
      Every upside no matter how dramatically up it is, has a downside.
      We weigh the positives and the negatives.
      I suggest while the plugin repository UI is upgraded that the plugin repository policies go through a zero-based rewrite as well.

      • Gary Jones 1:35 pm on March 2, 2016 Permalink | Log in to Reply

        > Searched “framework” in the plugin repository and got almost 1000 hits

        Standalone plugins related to Genesis Framework et al would likely have appeared in your search results, so quite a few false positives probably.

      • Ipstenu (Mika Epstein) 5:19 pm on March 2, 2016 Permalink | Log in to Reply

        Just like we didn’t yank everyone with ‘wordpress’ or ‘plugin’ in the URL, we’re trying to be good people and not yank everyone who is a framework and were already let in.

        We’re not actually bad people 🙂

        I suggest while the plugin repository UI is upgraded that the plugin repository policies go through a zero-based rewrite as well.

        Sure, if you’re willing to allow us to remove every single plugin from the repo, review them, and add them back on a case by case basis. Because that would be the only way to ensure fairness.

    • Ahmad Awais 1:49 pm on March 2, 2016 Permalink | Log in to Reply

      Hey, Mika!

      With due respect, last year, I was using Titan Framework in my plugin CF7Customizer (in embedded form) and you disabled the plugin. I told you that a user should not have to care about any dependency issues since that would be a bad user experience but I was forced to require Titan Framework as a separate plugin.

      Which resulted in 177 uninstalls with user responses like “Uninstalled because it needed another plugin” and 82 people has deactivated the plugin because they might have not installed Titan Framework and they didn’t understand how it works.

      Now, you are saying that Frameworks should be added in the embedded form. Which contradicts to why my plugin was disabled two months ago and I had to loose 200+ users coz of that.

      May I ask, which one is it?

      I feel bad about the whole idea.

      • Ahmad Awais 1:54 pm on March 2, 2016 Permalink | Log in to Reply

        We badly need a package manager and control over which package version should be included.

      • Ipstenu (Mika Epstein) 5:13 pm on March 2, 2016 Permalink | Log in to Reply

        Two separate things. And I did try to explain this to you in the emails multiple times.

        1) Once a library is IN THE REPO it’s a plugin and you should not include it in your plugin wholesale. It’s now a dependency to your plugin.

        2) If a library/framework isn’t in the repo then it isn’t a plugin, please do include it in your plugin.

        The reason is that once it’s been approved, well, the genies’s out of the bottle and you will run into conflicts if you try to do both. Also plugins should never include a plugin in a plugin. That defeats the purpose of plugins 🙂

        tl;dr – Don’t include plugins in your plugin. DO include libraries that are not plugins in your plugin.

        • Ahmad Awais 7:36 pm on March 3, 2016 Permalink | Log in to Reply

          Thank You, Mika!

          Now I get that. Anywho, I am trying to get rid of those dependencies and building my own to the point and simple libraries (the only bottleneck is availability of time here).

          Thanks for making it clearer 🙂 Appreciate that.

    • apsolut 6:27 pm on March 2, 2016 Permalink | Log in to Reply

      You did the same thing with WP-API and others – is there something you guys noticed from that experience ?… This will not solve the problems you highlighted “The parade…” in 80% cases.. It look like you guys know something we don’t or you plan something you won’t tell us.

      • There will be no changes (include plugin, don’t include plugin in plugin, its framework but its plugin..) without big changes in WP itself, in the end this will not stop anything, frameworks will be stored in another repo,git,bit – and? we/you fixed 4% of problems?

      For me, care for normal users would feel/be quite different than all this past years:
      customizer fight with others and in the end it still miss 10102 things,logo place in customizer, emoticons ? and yet missing a lot of things in WP itself (did we notice any change in nav-menus..?), its 2016 and normal users get to search repo like its 2001, without filters, lightbox?…

      In the end someone will just add category “frameworks” and all this will be for nothing….

      • Ipstenu (Mika Epstein) 1:15 am on March 3, 2016 Permalink | Log in to Reply

        We know a lot of things you don’t, from experience mostly. You know a lot of things I don’t. That’s … just kinda how life is 🙂

        Here’s our situation.

        Option 1 – Frameworks are plugins and we accept them. All new plugins that include said framework have to remove it and change it to a require. All existing plugins should be contacted and told to change their code. Some users complain about installing ‘extra’ plugins and some devs lose users (see earlier in the comments, it’s already happened). Also note – all devs have to put in this requirement themselves, possibly using … a library like TGM. ALSO all devs have to ensure they, now and forever, keep up with the frameworks and ensure compatibility as well as proper alerts if a user removes the framework by accident.

        Option 2 – Frameworks that are not ‘functional’ frameworks, but really libraries are treated as all libraries are with all projects, and included separately. Developers have to code the calls to the library, making sure that the ‘right’ version is included no matter what someone else includes. Developers also have to update their plugins when a library updates. though if they properly handle the code calls, they don’t HAVE to. They could use namespaces and cleverly call ‘use MYPLUGINAWSSDK as /aws/AWS/foo/bar’ instead, so their version is what’s used. They’ll probably want to code in a failsafe “If a version higher than mine is used, show a warning.”

        Which one’s better?

        Neither.

        And with that in mind, we decided to pick the side of ‘Which option annoys users slightly less?’ and that’s #1. The one where they don’t have to know (or care) about it.

    • x000 10:01 pm on April 4, 2016 Permalink | Log in to Reply

      Can someone please explain why I got a “Please don’t submit other people’s plugins.” denial when I wrote every single line?

      It is not a library or anything like that.

  • Ipstenu (Mika Epstein) 12:44 pm on February 17, 2016 Permalink |
    Tags: ,   

    Reminder: Many Javascript Libraries Are Included in Core 

    WordPress includes jQuery with core. Most everyone knows this. But did you also know WordPress includes a great deal of other libraries for your use.

    You should take the time to check the documentation on wp_enqueue_script().

    But that list actually isn’t complete! For a complete list of registered files inspect `$GLOBALS[‘wp_scripts’]` in the admin UI. Registered scripts might change per requested page. You can also check out the massive amounts of files in wp-includes to see even more.

    My point, though, is that 90% of the time, you don’t need ‘your own’ version of something. We have it.

    Even datepicker folks (jquery-ui-datepicker).

    Check if core works. If you call it right, most of the time it will.

     
    • Arnan de Gans 12:48 pm on February 17, 2016 Permalink | Log in to Reply

      And stop f*cking using googleapi hosted scripts if it’s included in WordPress already… Geez.

      @WordPress devs – You should include/optionalize to include (similar to language packs) a bunch of common fonts too so we can stop using the ridiculous google fonts, too 🙂 That would be a major yay!
      Perhaps a scrape function to pull files from remote to local or whatever.

    • Jacob N. Breetvelt 12:50 pm on February 17, 2016 Permalink | Log in to Reply

      I, as plugin developer, very much agree with this. Especially google api jquery libraries don’t work ( at all ).

    • Marcus 1:37 pm on February 17, 2016 Permalink | Log in to Reply

      moreover, it makes your life easier using the scripts shipped with WP since you don’t need to worry about keeping those updated

    • jeffmcneill 2:31 pm on February 17, 2016 Permalink | Log in to Reply

      What (if any) javascripts are loaded by default? If it is zero then all the loading is done by themes and plugins? Trying to get a plain vanilla theme that isn’t chock-a-block with js is very difficult!

      • Ipstenu (Mika Epstein) 5:25 pm on February 17, 2016 Permalink | Log in to Reply

        You’ll have to check the individual pages. On a naked WP site with a default theme, I have jquery, jquery-core, and jquery-migrate

        But. That’s where the beauty of the enqueues and their dependancies array comes in! If you say “I need jquery” then WP knows to only call it once 🙂 So you can enqueue your script, say it needs jquery core, and boom! Everyone wins.

    • Paul Menard 3:12 pm on February 17, 2016 Permalink | Log in to Reply

      Speaking of the date picker and the jQuery UI suite. When will core include some default styling/theming for jQuery UI functionality for use within the Dashboard? At least for some standardized items like the date picker, accordions, etc. Not asking for the front-end.

    • IntellyWP 4:05 pm on February 17, 2016 Permalink | Log in to Reply

      And also… please load your library only when you are seeing your plugin pages and not always!
      And also… please display your notice only inside your plugin pages!

      For this reason, we introduced in our latest plugin, at the beginning, some code check to remove other unnecessary plugins javascript library or css or displayed notice 🙁

      • Joachim Jensen - Intox Studio 11:00 pm on February 17, 2016 Permalink | Log in to Reply

        I agree with loading scripts only when needed.
        I cannot believe that this is not standard practice by all developers, but everytime I see it (and I mostly see it because of code conflicts) I try to contact the developer. I’d say the response rate is about 50%.

        Also, please register scripts by the actual library name. In the example from @ipstenu, use “jquery-ui-datepicker”, _not_ “mytheme-cool-datepicker”.

        • Ipstenu (Mika Epstein) 11:01 pm on February 17, 2016 Permalink | Log in to Reply

          FWIW: We don’t enforce it with developers since about half the time it would require a lot of deep diving into how a plugin is made and why. I personally recommend only loading what has to be loaded when it must be loaded, but then again I’m also pretty snarky about not including demo folders in plugins.

          • Joachim Jensen - Intox Studio 11:50 pm on February 17, 2016 Permalink | Log in to Reply

            I understand, and enforcing such thing could also lead to false positives, e.g. if a plugin really needed a script on each (admin) page. I think it would be more useful if it was written as a “best practice” somewhere in docs (if it isn’t already).

            By the way, I noticed that if you try to register two different versions of the same script, the first one registered is used, not the latest version.
            I know versioning is there mainly for cache reasons, but if wp_register_script is used correctly, wouldn’t it make sense to take it into consideration and always use latest version registered? Perhaps there already is a discussion for it somewhere?

    • A WP Life 5:35 pm on February 17, 2016 Permalink | Log in to Reply

      Yehh! I found it. It’s very useful for every plugin & theme developers.

  • Ipstenu (Mika Epstein) 9:30 am on February 3, 2016 Permalink |
    Tags:   

    Plugin Review “Inconsistencies” 

    A few people have complained that they feel the review process is inconsistent. I’d like to take a moment to explain exactly why that happens. The tl;dr is, of course, humans make mistakes. But if you really want to understand what’s going on, read on!

    There is no automated review process

    This is the big thing. Every single plugin is opened and read by a human being. We download the plugin, read it, and try to catch the myriad things that are wrong, insecure, not permitted, etc. And we’re humans. We do our best to scan/grep for things we know are easy to find (like I love checking for wp-(con|load|blog) to see if that’s being called). But a lot of times things are buried or hard to catch.

    This means mistakes are made. We don’t claim to be perfect. We claim to try our best to give you the best review we possibly can for your sake, as well as your users.

    Some replies are canned, the process is not

    I’m sure a lot of you have gotten an email starting with this:

    There are issues with your plugin code. Please read this ENTIRE email, address all listed issues, and reply to this email with your corrected code attached. It is required for you to read and reply to these emails, and failure to do so will result in your plugin being rejected.

    Yes, that’s a canned auto-reply. In order to get through reviews faster, we have replies for the common issues. Right now I have 60 in A-Text. That means there are at least 60 problems with plugins I see every single day.

    This makes us able to keep up with reviews. It’s impersonal, we know, but we try to cite examples from your plugin to help you understand what needs your attention.

    We don’t test your plugin on all environments

    Sometimes we do. But really that’s your job, not ours. We do if we notice things that are weird and we think may be problematic. Some days we test on VVV with PHP 5.6, sometimes it’s HHVM, and sometimes its PHP 5.2. Why? It depends on what we have available just then.

    This means sometimes we catch that you coded something for PHP 5.3 and up and sometimes we don’t.

    Every new version is checked top to bottom

    Think about that for a second, please. If you submit a plugin and we pend it for changes, and you send us the new version, we read the whole thing all over again. Every. Single. Time. We check to make sure you did your changes first, yes, but then we go back and re-read everything to make sure we didn’t miss anything, or you didn’t accidentally add in something new.

    This is why, sometimes, you get an email that starts with “We missed this before…” or “This is also not permitted because…” We’re giving you the best review we can.

    No, we don’t list everything wrong

    It’s not what you’re thinking. Every time we do a review, we list everything we see that’s wrong. We do not list out, for example, every instance of a non-sanitized/validated POST call. We do not list out every single usage of script tags instead of enqueues. We will give you an example, especially if you miss some on your first edit, but we expect you to know how to search your own code.

    This helps you learn how to better vet and review your own code. Also it saves us a little time.

    There are multiple people doing reviews

    Some of us are better at some thing than others. When we find a plugin we don’t feel confident in reviewing on our own, we raise a flag and ask our cohorts to spot-check our work.

    This also lets us hand off troublemakers. Let’s be honest here, folks, we don’t all get along with everyone. When it’s clear we’re at an impasse with someone, we ask each other for help.

    Our goal is protecting users first, then you

    The people we care about the most are the users who can’t code or who don’t understand the severity of things like offloading CSS. You may think it’s trivial and makes your plugin smaller. Someone in another country could find them sued for not disclosing it. Or your plugin may not work because Google is blocked where they are.

    We care about protecting the users from XSS and SQL injections. We care about protecting their information. We care about keeping them safe. But we care about you too! We’re so techy about you documenting ‘This plugin calls service XYZ’ because, yes, the users have a right to know where their data is going, but also because you deserve not to have a slew of angry 1-star reviews that you didn’t tell them.

    This is a tricky road to walk. Some people may get exceptions. Some people may teach us more about code! Some people may be told ‘no’ flat out.

    Guidelines evolve over time (so do security best practices)

    We’re constantly looking over the guidelines and evaluating them for clarity, consistency, supportability, and real-world applicability. Have you read our Detailed Plugin Guidelines lately? You should. Similarly, our security checks have gotten better over time. We used to allow you to call wp-config.php directly. We don’t anymore. The more a specific vulnerability is targeted, the harder we are on your code to ensure you are not the weakest link.

    This is for your protection! We’re doing our best to make sure you don’t get dog-shamed for being the reason sites go down.

    Remember: We are mortal

    I said this to start off this post and I’ll say it again. We, your review team, are human beings.

    We make mistakes. We miss things. We read code incorrectly. We don’t test everything as fully as we should. We screw up. We never miss things out of maliciousness or an intent to blacklist you from the repository. We believe you submit your plugins in good faith, and we respect you enough to treat you as adults and point out what you missed or explain how you can do things better.

    This means you should give us the same benefit of doubt we give you.

     
    • Wolly aka Paolo Valenti 9:37 am on February 3, 2016 Permalink | Log in to Reply

      1) Thanx a lot for your job. ( Now I can tell you since I cannot via email 🙂 )

      2) All my plugins have been reviewed and I received information of security problems, or code error.

      My 2 cents, and thanx again for your job.

    • Sami Keijonen 9:56 am on February 3, 2016 Permalink | Log in to Reply

      Are there any others than Pippin and you making great job at plugins review?

      I was also wondering if plugin review is as intense as theme review. I personally think that’s not possible because there are so many new plugins and updates coming in daily.

      • Pippin Williamson 2:47 pm on February 3, 2016 Permalink | Log in to Reply

        It is primarily Mika and I but there are several others who review a few plugins, primarily when we need an extra set of eyes.

        The plugin review process is much simpler and much less strict than themes. Themes have an inherent minimum that they must provide, but there’s no such thing with plugins. A plugin could be one line or 500,000.

    • IntellyWP 11:42 am on February 3, 2016 Permalink | Log in to Reply

      Hi only want to say… Thank you! 😀
      Your review process is amazing and also the information provided are each time very specific.
      Thank you again, Alex (IntellyWP team).

    • Mayeenul Islam 11:50 am on February 3, 2016 Permalink | Log in to Reply

      First of all, thanks a lot for the awesome job.

      I’ve a suggestion for you, as you mentioned:
      “If you submit a plugin and we pend it for changes, and you send us the new version, we read the whole thing all over again. Every. Single. Time.”

      If a version is managed, and all the diffs are visible it’s easy overseeing all the changes. If the changes are right, then you can check the overall thing.

      • Pippin Williamson 2:49 pm on February 3, 2016 Permalink | Log in to Reply

        Plugins do not existing in WordPress.org’s SVN repo until after they are approved, so we cannot automatically generate a diff of the new version.

        Tip: plugin authors can make the review process faster by including a link to a diff when sending a new version for review.

      • Ipstenu (Mika Epstein) 2:50 pm on February 3, 2016 Permalink | Log in to Reply

        Sure, but re-read why I said we do that.

        We know we miss things. That re-review has cought things multiple times. We’re doing this for your benefit. Make sure we get everything right.

        Plus we have to be sure you changed everything we asked and a diff will only show us what you did do, not if you did everything.

        It’s the same if your plugin is closed for security. You get a top-down review to make sure everything is good, even things we didn’t initially flag.

    • OllieJones 12:19 pm on February 3, 2016 Permalink | Log in to Reply

      “we, your review team, are human beings” — Yes, extraordinarily talented and dedicated human beings. Thanks. It’s your work that makes the plugin repo such a useful global asset.

      A suggestion: You said you have sixty or so “canned” reponses. How about posting them, in rough order of how frequently you send them out? That we we plugin noobz can see the kinds of things your code inspection looks for.

    • Chad Butler 1:14 pm on February 3, 2016 Permalink | Log in to Reply

      Thanks for the time and talent that the plugin review team puts into this.

    • Carolina Nymark 2:36 pm on February 3, 2016 Permalink | Log in to Reply

      <3 I just want to copy this over to theme reviews. I love the idea of (nearly) auto-replies.

    • Andy Fragen 3:00 pm on February 3, 2016 Permalink | Log in to Reply

      Thanks Mika, Pippin, and Otto. I appreciate all you time and expertise, and I know my users do. <3

    • Devio Digital 8:19 pm on February 3, 2016 Permalink | Log in to Reply

      I’ve had a few plugins reviewed now, and besides the two getting refused due to names in the slug which I wasn’t Legal owner of, I’ve had nothing but positive results 🙂

      Even with the rejections, I had kind, personal notes, so I don’t have a bad thing to say about the review process. You guys are doing an awesome job!

    • Mark O'Donnell 10:34 pm on February 3, 2016 Permalink | Log in to Reply

      Thanks Mika (Pippin, Otto, and whoever). You guys do an outstanding job. You are extremely knowledgeable, and very responsive. I say that as someone who has had plugin submissions “dinged” for various issues (generally my carelessness). Every time your review has made my plugins better.

    • jeffmcneill 4:24 am on February 4, 2016 Permalink | Log in to Reply

      Just another thank you for taking care of the important but definitely thankless task by whomever is doing all this great work. While still human, the challenge borders on the superhuman.

    • Guido 10:30 am on February 4, 2016 Permalink | Log in to Reply

      I’m just wondering, if a plugin in repository gets updated with for example a depricated function or other bad coding, is this somehow noticed by the review theme? If not, I suggest a report button.

      • Ipstenu (Mika Epstein) 4:14 pm on February 4, 2016 Permalink | Log in to Reply

        We don’t review every single commit to that granular of a level.

        And we’ve talked about a report button, but … well, report to whom? The review team? If it’s not security related, we’re not going to step in, so just leave a support-post for the author or contact them directly 🙂

    • Robin Cornett 5:07 pm on February 5, 2016 Permalink | Log in to Reply

      Just want to chime in and say that y’all are awesome. I’m thinking plugin reviewing is a monumental task. In my experience, y’all have been incredibly fast, courteous, professional, and helpful. Also, the docs for plugin guidelines, and navigating SVN, have been invaluable. Thank you!!!

    • A WP Life 6:03 pm on February 7, 2016 Permalink | Log in to Reply

      In my opinion @Mika you doing great job for all plugin developers.

    • victordemianenko 7:54 pm on February 9, 2016 Permalink | Log in to Reply

      Thanks for your time and talent, guys! It is thanks to your work, I can say this:
      Have you in frustration or may be in stress?
      Helpful for you will be only WordPress! :))

    • pressbro 8:47 pm on February 11, 2016 Permalink | Log in to Reply

      I just today got my first plugin accepted and the help from @ipstenu was more than I expected. Friendly, to the point and helpful. I honestly didn’t expect anything for a week, but everything happened in a mere day and a half or so, and was mostly behind me fixing the issues in my plugin.

  • Ipstenu (Mika Epstein) 4:31 pm on January 11, 2016 Permalink |  

    [RESOLVED] Jan 11 – Issues committing to SVN 

    0100 UTC

    This problem should be fixed now. Let us know if you have any continuing issues. -Otto

    2339 UTC

    We’ve ruled out a couple things. The access table seems okay. But right now we don’t have an ETA 🙁 I’m sorry.

    2141 UTC

    Just an update to let you know we’re still looking into it. You don’t need to tell us your plugin names. Pretty much everyone who was approved this weekend and on has this issue.

    1631 UTC

    We’re aware of this and looking into it. Please keep an eye on this post. We will update as soon as we have any information.

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

    ‘Policy’ on PHP Versions 

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

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

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

    This is not an official requirement post.

    This is a reminder post.

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

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

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

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

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

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

    Practical Examples

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Ratings Rebuilt 

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

    As Otto put it:

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

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

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

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

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

      Awesome! Thanks for the update @ipstenu 🙂

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

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

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

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

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

      Oops, we’ve some weird error on our plugin’s stats page:
      “Cannot read property ‘title’ of undefined×”
      https://wordpress.org/plugins/wpsecureops-easy-firewall/stats/

      Any ideas what can be causing that?

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

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

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

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

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

          Ah!
          At least, i’m happy that I was able to help to report another problem then 🙂

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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

            • pflammer 4:58 pm on June 23, 2015 Permalink

              Hi Mika, if I wanted to make a bridge plugin on WordPress that would download and install a database management system (it has non-GPL components, would not be hosted on wordpress.org, and does not directly interact with WordPress), then from your comment on bridge software, it sounds like this would be acceptible to host the installer on wordpress.org, as long as the installer was GPL. Is that correct or at least the general rule?
              Thanks.

            • Ipstenu (Mika Epstein) 8:15 am on June 24, 2015 Permalink

              @pflammer – No, the plugin would not be permitted because it’s downloading non GPL code. The bridge connector is fine. The part where it downloads and installs is not. That’s not a bridge, that’s an installer.

            • pflammer 1:40 pm on June 24, 2015 Permalink

              @Ipstenu, I think I see. So bridge plugin would only be software that somehow links other apps to WordPress, but the user must install the other software independent of WordPress. Is that correct? Do you know of any example bridge plugins that are acceptible on WordPress.org? That might give me a better idea of what we might do. Thanks!

            • Ipstenu (Mika Epstein) 8:07 am on June 25, 2015 Permalink

              @pflammer I mean like https://wordpress.org/plugins/bridgedd/

              You can google for more examples, but basically it’s a plugin that allows single sign on between the two and/or data to be sent back and first. Pretty much any plugin that has an API to connect to other services is a type of bridge.

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

            Hello Mike,

            Please share that plugin with me.

            Thanks,

            Imran

    • Charleston Software Associates 5:46 pm on December 20, 2012 Permalink | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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:
        https://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 | Log in to 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 | Log in to Reply

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

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

        This plugin clearly cites AGPL version 3.
        https://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 | Log in to 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 | Log in to 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 | Log in to Reply

      Please close the last link. 🙂

    • Fabien 11:44 am on December 21, 2012 Permalink | Log in to 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 | Log in to 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 | Log in to 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)

    • chassett 5:47 pm on October 3, 2013 Permalink | Log in to Reply

      I read all of the existing comments, and want to outline another case and see if it is OK. I am writing a plug-in that will “iframe” content delivered from our web servers. The parent code that hosts the iframe will reside on wordpress.org and all of its code is GPL compatible. However, the iframe it serves up from our web servers contains Highchart charting software. The code served up in the iframe is not included in our plugin and is not hosted at wordpress.org. Is this OK? BTW, thanks for this thread, obviously very important.

      • Ipstenu (Mika Epstein) 8:33 pm on October 3, 2013 Permalink | Log in to Reply

        Yes and no, but it’s less an issue of the GPL and more one of the iframe. If you consider how YouTube is embedded, it’s in a frame, btu it’s called via an api, so there’s not exactly iframe IN the code to be abused (we don’t like iframes much for that reason)

        Please email plugins@wordpress.org if you need more information about that.

        In so far as GPL goes, you SHOULD be okay 🙂

    • paoltaia 2:15 pm on April 17, 2014 Permalink | Log in to Reply

      Quick question, if I release a plugin on wordpress.org 100% GPL and sell extensions for this plugin on my website with a Split GPL (excluding css, js and images) are we infringing wordpress licence?
      If the answer is yes, will the main plugin be taken down from wordpress repository?
      Thanks!

    • gioni 9:32 am on October 12, 2015 Permalink | Log in to Reply

      It would be helpful if you could explicitly clarify something about using assets from sites like Creativemarket or Photodune. Can I bundle assets, which I bought, with my plugin? They does not have GPL-like license: https://creativemarket.com/licenses/simple

      • Ipstenu (Mika Epstein) 4:09 pm on October 13, 2015 Permalink | Log in to Reply

        We can’t give you a one-answer-fits-all because there is no such thing. We can look at each case and try to help you understand if it can be used.

        Looking at the linked license, I would say the added restrictions about how you can’t sell products using their stuff makes it flat out NOT GPL.

        the item cannot be resold or redistributed on its own, or used in a product offered for sale where the item contributes to the core value of the product being sold.

        That would be putting an extra restriction on the usage, which is against the GPL, so no. Can’t use ’em.

        Now they did say this:

        Portions of some products may be covered by an open source software license such as the GPL (GNU General Public License). In these cases, any portions of the product not covered by an open source license will be covered by this license.

        Those portions you can use. But otherwise, unless it explicitly says it’s GPL, you cannot use their stuff in your plugins here.

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
Skip to toolbar