WordPress.org

Make WordPress Plugins

Tagged: repository Toggle Comment Threads | Keyboard Shortcuts

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

    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) 1:41 am on February 26, 2016 Permalink |
    Tags: , notice, repository   

    There’s a Revamp Coming 

    We’re overhauling and upgrading the repo. Interested? You can harass @obenland and team about it:

    Plugin Directory v3

    See you there

     
  • Ipstenu (Mika Epstein) 8:57 am on January 12, 2016 Permalink |
    Tags: , repository,   

    2015 Community Summit And How You Can Help the Plugin Team 

    Sadly, many of the same reasons we could not add new members to the Plugin Team last year are still an issue (see 2014 Community Summit Wrapup). The codebase has been improved, but the process is slow. Just to give you some hope, the work done on the Theme Repo is being used to help us. So. Soon. Soon. We’re restructuring the backend to make it more clear as to who can do what, but most things are waiting on the re-vamp.

    The only real ‘news’ is that we’ve been sneakily moving our documentation over to https://developer.wordpress.org/plugins/wordpress-org/ – Please check it out to keep up with all the information about what makes good plugins in the repo. Oh, and we’ve swapped reps. I’ll be taking over as the plugin team rep and that really changes… nothing at all. @boone did a great job and I thank him for it.

    You Can Help

    While we are still stuck on the old system, you can jump in and help us by emailing plugins@wordpress.org when you find people playing fast and loose with the rules.

    We encourage and welcome updates from everyone, but please don’t be snippy. Be serious. If someone has powered by links, or is phoning home, yes, please let us know. But don’t let your personal feelings get in the way. This is a big deal. A lot of people send us reports from a place of anger. Don’t be that person. That person makes it harder for us to figure out if someone has a personal vendetta against a plugin and/or developer, or a legit concern. We’re all passionate, but remember to channel that passion into something beneficial.

    How to Report Issues

    If you’ve found a plugin _doing_it_wrong(), email plugins@wordpress.org and remember:

    1. Make your subject clear. (“XSS Vulnerability in Hello Derpy” or “Derpack Developer swearing at users in forums” are good)
    2. Always provide an exact link to the plugin.
    3. Report plugins with guideline violations.
    4. Report developers who are behaving badly.
    5. Be detailed. If you know what file and line of code is the problem, tell us.
    6. Provide examples of vulnerabilities. If you already know what’s hackable, show us. It makes it faster for us to verify and reproduce. Link to forum threads etc etc.

    Remember: We don’t retroactively enforce guideline changes unless there is a legal, copyright, or security related reason. For example, we no longer allow new plugins to call wp-load.php directly, however we don’t hunt around for plugins that do so. If a plugin is closed for using a non-GPL library and, in the review, we note other best-practices violations, we will require them all to be fixed before reopening.

    Also, we won’t be following up with you as to what happened most of the time. We’d love to. We can’t and keep up with emails. Please don’t take it personally. As we add more people to the team we may be able to change that, but right now it takes us away from validating security issues.

     

    Tools

    Rami asked “What do you guys even use to check plugins and look for bad things?” and the real answer is “Our eyes.” We don’t have a theme-check type plugin because there are very few ‘standard’ things to look for (possibly it could check for license issues, including jquery files, and calling wp-load directly sort of things).

    Remember: Thou Art Mortal

    And so are we.

    We’re people too. We make mistakes. We miss things. We have bad days. We get sick. We have families. If we don’t reply to you super fast, please sit on your hands and give us five days. Five. You should get some sort of reply from us within five, even if it’s ‘we’re still talking about this, sorry but it’ll take a while.’ Sending us an enough every 12 hours (yes, someone did that) is annoying.

    Hunting us down on Twitter and Slack because we didn’t reply right away is similarly uncool and harassing. We use the email so that everyone on the team can read the conversations. Don’t take it off-line. Keep it in the email and that way, if you’re talking to Otto and he goes to a BBQ fest for two weeks days without access, Pippin can pick up the conversation and help you out.

    Just be patient and calm. Especially if we’ve just closed your plugin. We know that sucks, and we totally get you’re angry sometimes. Just try to remember we’re all humans and treat us with respect like fellow humans.

    Grumpy Otto (is there another kind?) looking at the camera.

    Take the plugin. Leave the cannoli.

     
  • Ipstenu (Mika Epstein) 12:35 pm on January 4, 2016 Permalink |
    Tags: , , repository,   

    Reminder: Your Email Account Must Be Valid 

    Since the only way we have to get in touch with plugin authors is their emails, we’re going to be enforcing that you have a valid email that goes to a human being for you plugins.

    This simple statement covers a multitude of situations but to clarify, we’re talking about the email associated with the user accounts that have commit access to your plugins.

    Go to https://wordpress.org/plugins/YOUR-PLUGIN/admin/ and look at the people listed under Committers. Those accounts are who we email when there’s an issue with a plugin, or when we’re alerting you to new WordPress updates. Those emails must go to real human beings. It can be a shared email box (goodness knows plugins is a shared email box) but real people have to read those emails because without that, we cannot communicate with you.

    We strongly suggest you whitelist plugins@wordpress.org

    The following email situations may result in your plugin being closed if we can’t find a way to communicate with you:

    Invalid Emails

    If your email bounces, your plugin gets closed. We can only assume that a dead email means you’re done with things, and since we have no way to contact you, your plugin can only be considered unsupportable. If you notice your plugin is closed and you didn’t get an email from us, check your account’s email. If that’s not right, that’s probably why.

    Auto-Replies

    If your email has an auto-reply, such as the sort that goes to a support ticket generator, stop it. This makes it nigh impossible for us to communicate with you, we can never tell if a human has read the email, and we get a mail box filled with auto-replies which means you’re the reason plugin reviews are backlogged. We will normally email you one sternly worded warning about this. If it keeps up, your plugin may be closed.

    2-Step Verification

    If your email auto-replies and asks people to click or reply in a special way to ensure our email gets to you, guess what? Half the time that doesn’t work. We often get expired tokens because it takes us more than 24 hours to get through all the emails in our queue, and once that happens we have no way to get our email to you.

    Deceased Authors

    This is a touchy subject so I apologize in advance. If a plugin author has died and we can verify this, we remove their account’s access to their plugins (and usually reset their passwords to something random). This is in the interest of security, as doing so will prevent any possible issues if their account is hacked. We do not close the plugins. If there are co-committers, they will be notified. Otherwise the plugin will simply remain in place. Taking over those plugins is a similarly touchy subject, and priority will be given to their coworkers or close friends/family who are also WordPress developers.

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

    AutoReply Sucks 

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

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

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

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

    THIS IS A GLOBAL REMINDER

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

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

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

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

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

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

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

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

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

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

      (y)

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

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

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

      I love this +1 requirement!

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

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

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

      +1

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

      +1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      What do you recommend for this?

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

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

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

        I appreciate all the good work

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

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

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

      +1 for this!

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

      +1 Absolutely!

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

      +1

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

    Tis the Season for Snow 

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

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

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

    No, we have a blizzard of them.

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

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

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

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

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

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

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

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

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

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

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

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

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

        Not kidding.

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

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

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

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

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

            /offtopic

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

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

              99% accurate 🙂

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Ipstenu (Mika Epstein) 6:00 am on May 4, 2015 Permalink |
    Tags: repository,   

    Reporting Plugin Issues 

    Note: I’ll be using Hello Dolly as my example ‘bad’ plugin for this post. It’s fine and not (to my knowledge) vulnerable.

    There are a few reasons people report plugins but the main two are as follows:

    • Guideline violations
    • Security vulnerabilities

    If you report a plugin, you can make everyone’s life easier if you do the following:

    Verify that it’s still applicable

    Before you do anything, check if the exploit is on the latest version of the code or not. If it’s not, we may not do anything about it, depending on how popular the plugin is.

    Use a good subject line

    “Plugin Vulnerability” is actually not good at all. “Plugin Vulnerability in Hello Dolly – 0 Day” is great.

    Send it in plain text

    SupportPress is a simple creature. It doesn’t like your fancy fonts and inline images. Attachments are fine, but we cannot read your ‘Replies in-line in red’ so just keep it simple.

    Link to the plugin

    https://wordpress.org/plugins/hello-dolly/

    Yes, it’s that easy. Put the URL on it’s own line, no punctuation around it, for maximum compatibility. With over 35k plugins, and a lot with similar names, don’t assume, link.

    If the plugin is not hosted on WordPress.org, I’m sorry, but there’s nothing we can do, so please don’t bother reporting it to us. We have no power there.

    Explain the problem succinctly

    Keep it simple.

    “Hello Dolly has an XSS vulnerability” or “The Author of Hello Dolly is calling people names in the forums” or “Hello Dolly puts a link back to casino sites in your footer.”

    Think of your intro like a tweet. Boil it down to the absolutely basic ‘this is what’s wrong.’

    Keep the details clear

    If someone’s acting up in the forums, link to the forum threads.

    If you know that on line 53, the plugin has a vulnerability (or a link back to that casino site), then you can actually link right to that line: https://plugins.trac.wordpress.org/browser/hello-dolly/tags/1.6/hello.php#L53

    We love that. If you don’t have that line, it’s okay. Tell us exactly what you see. “When I activate the plugin using theme X, I see a link to a casino site by my ‘powered by WordPress’ link.” Perfect. Now we know where to look when we test.

    Show us how to exploit it

    Don’t ask us ‘Can I send you an exploit?’ Just send us all the information. If the exploit’s already up online, like on Secunia, link us to it.

    If you know exactly how to exploit it, tell us with a walk through. If the walkthrough involves a lot of weird code, you may want to consider using a PDF.

    We’re going to take that information and, often, pass it on directly to the developers.

    Tell us if you want them to have your contact info

    We default to not passing it on, out of privacy, so “If the developer needs more help, I can be reached at…” is nice. Even “You can give the developer my information so they can credit me…”

    We’re probably not going to follow up with you

    We love the report, we review them, but we’re not going to loop you back in and tell you everything that’s going on for one very simple reason. We don’t have the time. If you told us to give the dev your contact info, then we did, but we don’t have any way to promise they will, and we don’t have the time to play middle management.

    Emailing us over and over asking for status gets your emails deleted. It’s not personal, it’s seriously a time issue. We’re nothing more than gatekeepers, we are not a security company and we’re not equipped for keeping everyone up to date. We don’t have an administrative assistant to handle that. We work with the developer to fix the issue and we work with the .org team to see if we need to force update the plugin, and that takes a lot of time.

    We don’t do bounties

    This is a little interesting but basically we’re not going to pay you. A lot of people ask for ‘credit’ so they can ‘earn’ a bounty, and that’s cool, but we’re not going to report that for you. Generally if you say you want a bounty, we give your info to the plugin dev, though, so they do know you’re interested.

    How do you report?

    You can report plugins by emailing plugins@wordpress.org

    That’s it 🙂 Thanks!

     
    • J.D. Grimes 1:09 pm on May 4, 2015 Permalink | Log in to Reply

      Thank you for laying this out for everyone, it’s nice to have things clear. Now if we could just get this into the hands of people who are/should be reporting plugin issues… 🙂

      • Chad Butler 3:55 pm on May 4, 2015 Permalink | Log in to Reply

        Awesomely descriptive! Thanks, Mika.

        I want to second J.D.’s comment – how to get this into the hands of the general public who report these things? I’m guessing they don’t follow Make threads.

        • Ipstenu (Mika Epstein) 4:01 pm on May 4, 2015 Permalink | Log in to Reply

          Man, if you guys have an idea I’d love to hear it.

          The idea of ‘Make a button!’ is not a great one since we’d just get a lot of bad reports and spam :/

          • J.D. Grimes 4:09 pm on May 4, 2015 Permalink | Log in to Reply

            What about just a link to this article or similar, “How to report vulnerabilities/violations”? Then people would have to read it to figure out how. But I guess some folks would still just scroll down to get the email address and you’d still get bad reports.

            I’ve been following https://wpvulndb.com/, and I’ve noticed that some of the researches don’t seem to know how to report the vulnerabilities to the plugins team. Maybe the folks at WPScan could help out with educating security researchers by including a note and a link to this article somewhere.

    • M Asif Rahman 4:23 pm on May 4, 2015 Permalink | Log in to Reply

      We already have button to report broken plugins. Maybe add another like “Report a plugin”. the button will lead to this post. And instead of emailing, maybe lets make a mail to form, with captcha.

    • Nile Flores 12:27 am on May 5, 2015 Permalink | Log in to Reply

      I’ll refer to this article, Mika. Thanks for putting this up. My co-mod shared it in All About WordPress on FB. 🙂

    • ethicalhack3r 9:05 pm on May 13, 2015 Permalink | Log in to Reply

      What incentive is there for any one who volunteers their time to email you about a plugin vulnerability to do so again if you’re not even going to acknowledge their email?

      You need to gamify this process, give them an incentive to do it again. After all, they are taking their own time to email you about the issue which helps protect *your* users.

      I’m sorry but ‘we do not have the time’ is not an excuse. If there is not enough time then not enough resources are being used for this.

      • J.D. Grimes 9:15 pm on May 13, 2015 Permalink | Log in to Reply

        Note that the email will be acknowledged in my experience. While the heading says “We’re probably not going to follow up with you”, it clarifies that to actually mean “we’re not going to loop you back in and tell you everything that’s going on.” However, the response is usually from a can (but not automated).

        • ethicalhack3r 9:22 pm on May 13, 2015 Permalink | Log in to Reply

          Maybe I miss interpreted it. I can confirm that, looking back through my emails, I have only ever not received a reply once.

          • J.D. Grimes 9:32 pm on May 13, 2015 Permalink | Log in to Reply

            But of course, it isn’t acknowledged in the sense of giving any kind of recognition to reporters, like rep points or a hall of fame mention. Maybe that was more the gist of what you were trying to get across?

            • ethicalhack3r 9:43 pm on May 13, 2015 Permalink

              Yea, that was part of what I was trying to get across. Even just building up a ‘relationship’ with the reporters by following up and saying ‘hey, thanks, we really appreciate the effort’.

              I think a another commenter touched on a submission form type idea. Most people who contact wordpress won’t have read this post. A submission form with all the necessary fields and explaining what wordpress want. I think this would increase the quality of submissions and thus waste less time.

              Full disclosure: I work on wpvulndb.com

              I think a wordpress supported version of what we are doing would improve plugin/theme security. Shine a light on vulnerabilities and credit researchers/reporters. I would be more than happy to work with WordPress in any way we can if they wanted.

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

            I can promise you we do reply. Always. Even if just to say “Thank you!”

            Normally people get a form email reply, but it’s something a human had to manually do.

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

        We ALWAYS reply to the email. Always. Even yours. I see it in our out boxes. Maybe you need to check you spam filter and make sure pluginsATwordpress.org is on the whitelist? Gmail has been particularly daft about it…

        Nope, not gamifying.

        Incentive? What’s my incentive for doing any of this? I’m not compensated by .org 🙂 I do it because it’s the right thing to do for my community. Do it or don’t do it, we can’t make you, but we can suggest how it would best help US if you choose to. And we do greatly appreciate those who do.

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

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

  • Ipstenu (Mika Epstein) 5:04 am on April 21, 2015 Permalink |
    Tags: repository, testing   

    Reminder: Please Test Your Plugins With 4.2 

    WordPress 4.2 is being released this week. Are your plugins ready?

    After testing your plugins and ensuring compatibility, it only takes a few moments to change the readme “Tested up to:” value to 4.2. This information provides peace of mind to users and helps encourage them to update to the latest version.

    For each plugin that is compatible, you don’t need to release a new version — just change the stable version’s readme value.

    In the same vein, please take the time to make sure the people listed as committers on your plugin are only the people who are actively developing the plugin.

    Finally, if the email associated with your wordpress.org plugin author’s account has an auto-reply, please for the love of peanut butter change that or put plugins@wordpress.org on a magic whitelist that doesn’t get the auto-replies. We very rarely send you out important emails, but when we do, they’re related to security or upgrades. When you give us an auto-reply, it delays things and makes our in-box insanely large.

     
    • Varun Sridharan 5:07 am on April 21, 2015 Permalink | Log in to Reply

      🙂 Thanks For The Info

    • Pär Thernström 6:25 am on April 21, 2015 Permalink | Log in to Reply

      > In the same vein, please take the time to make sure the people listed as committers on your plugin are only the people who are actively developing the plugin.

      Is that the Contributors-field, or is there any other field that I have missed in my plugins? 🙂

    • rahul286 7:03 am on April 21, 2015 Permalink | Log in to Reply

      > When you give us an auto-reply, it delays things and makes our in-box insanely large.

      Just wondering if outgoing emails can have reply-to header set to no-reply@wordpress.org or some mail address which is not monitored. It might save plugins@wordpress.org inbox.

    • Rami Yushuvaev 3:38 pm on May 11, 2015 Permalink | Log in to Reply

      make sure the people listed as committers on your plugin are only the people who are actively developing the plugin.

      Actually, this is not correct. If I develop plugins for brands, and I’m the only committer, I can’t remove the brand username, it’s against your policy.

      • Ipstenu (Mika Epstein) 10:44 pm on May 11, 2015 Permalink | Log in to Reply

        Not our “policy,” but that’s a different thing and it’s actually exactly what I mean.

        What Rami’s talking about is that if you make a plugin for a company (say LiveJournal hires me to make a plugin to autopost), then I really should be using a LiveJournal company account to MAKE the plugin because the company owns the trademark, not you.

        So in that example, there might be two committers.

        1) LiveJournal – The plugin owner who is responsible for all things security, guideline, etc.
        2) My Account – The person who is in charge of writing the code.

        And there, Rami, you may be the only person actively developing the plugin, but the owner is someone else.

        What we meant by that statement is that if you quit development for a plugin, you should have your name removed. Otherwise you get all the emails about all the issues, and you may not want them.

  • Ipstenu (Mika Epstein) 7:25 pm on February 27, 2015 Permalink |
    Tags: , ratings, repository, 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) 4:47 pm on February 26, 2015 Permalink |
    Tags: repository,   

    Getting Support Notifications For Your Plugin 

    When you have a plugin, it’s important that you get notified when people have support questions. We have a way for you to keep up to date on these things and have since the Great Plugin Refresh of 2012. But for those of you who missed the news or need a refresher, here we go.

    All Plugins

    We’ve always had a couple convenience views of plugin-committers and plugin-contributors, and these are still there as well. Committers are managed in on the Admin tab (i.e. people who have access to commit code via SVN), while contributors are taken from readme.txt (which is why it’s important for you to use the proper WPORG forum ID, capitalization and all).

    Example URLS:
    https://wordpress.org/support/view/plugin-committer/Otto42
    https://wordpress.org/support/view/plugin-contributor/Otto42

    Your username is case sensitive. Otto42 will work, otto42 will not. Not sure what yours is? Go to https://wordpress.org/support/profile/ (yes, that works for everyone) and look at the header:

    Example of Otto's profile, his name is capitalized

    The name in the grey header is capitalized, thus he must use a capital_O_dangit.

    Otto fixed this, lowercase works, still, check your login name because I know some of you have weird spaces and stuff

    Since anyone can add you as a plugin contributor, I recommend following plugin-committer.

    The RSS URLs for this look like https://wordpress.org/support/rss/view/plugin-committer/Otto42

    At this time, we don’t have email for this.

    Per Plugin

    Every single plugin allows you to follow it by email. Go to the Support Page for your plugin, scroll down to the bottom, and you’ll see this:

    Example of Email/RSS links

    RSS and email. Done. Even if there are no posts you can register for those emails, so make that a part of your workflow.

     
    • Lester Chan 4:59 pm on February 26, 2015 Permalink | Log in to Reply

      Thanks for this! It is a #TIL for me!

    • Chad Butler 5:16 pm on February 26, 2015 Permalink | Log in to Reply

      Great insight! Thanks for posting it. I was never aware of the “convenience” views before.

    • danieliser 5:36 pm on February 26, 2015 Permalink | Log in to Reply

      The one thing that is missing and I would desperately love to see is a new view for unresolved issues only. Would make sorting through hundreds of tickets much easier.

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

      You know, if you would email me before writing these things, then I could go in and fix the bugs in them before you finish writing them. 😉

      I’ve just made two important corrections to this code:

      1. It no longer uses your login name. It uses your URL slug (aka “nicename” for those who know what that means). This would be the same as in the URL of your profiles page.

      So, my profiles page is https://profiles.wordpress.org/otto42 . This means that my feed would be https://wordpress.org/support/view/plugin-committer/otto42 .

      2. Because of this, the case-sensitivity is now gone. Or rather, it will redirect you to the lowercase URL instead. No more case-sensitive BS for us, not when we can avoid it.

      The associated RSS feed should also no longer be case sensitive.

    • Paul de Wouters 8:20 am on February 27, 2015 Permalink | Log in to Reply

      We have the RSS feed trigger a Slack notification with Zapier or IFTTT, which is handy.

    • Zane Matthew 2:43 am on December 2, 2015 Permalink | Log in to Reply

      Will the support forum ever be updated to something (anything) that resembles a modern day textarea (thinking of GitHub flavored markdown here). Currently its outdated to say the least.

      Also will the UI/UX ever be updated? This also is lacking.

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