WordPress.org

Make WordPress Plugins

Tagged: repository Toggle Comment Threads | Keyboard Shortcuts

  • Ipstenu (Mika Epstein) 8:46 pm on August 3, 2016 Permalink
    Tags: , , repository   

    Plugin Directory Revamp Meeting Today 

    Plugin Directory Chat Agenda

    This is _not_ a meeting about the plugin review process or guidelines. This is only about the revamp.

     
  • Ipstenu (Mika Epstein) 5:52 am on July 29, 2016 Permalink |
    Tags: , , repository   

    Status on the Plugin Repo Revamp, Guidelines, and Handbooks 

    First off, please read Obenland’s post on the repo:

    Plugin Directory v3: Next Steps

    Obviously we have a long way to go.

    As for the Guidelines, I wanted to be done and ready to release them to everyone before 4.6 dropped, but I’ve been using small focus groups at WordCamps first. This resulted in a lot of small changes that I want to take the time to go over with the Plugin Team before I unleash it to the world for nitpicking. A huge amount of thanks goes to @courtneydawn @logankipp and @lunacodes for being my first run of editors!

    As we clean up the aftermath of the 4.6 emails (you have no idea…), I’ll be pinging people whom I know to be good copyeditors and have mentioned wanting to help before. If you think that’s you, please leave a comment here. I won’t be asking everyone as I’ve found that to be overwhelming for me to be able to process, so please don’t take it personally. Once I have it mostly good, I’ll flip it from Google Docs to a Git Repo and people can pull request!

    Also a handbook! Oh me oh my I’ve been writing one! And I’m almost ready to ask Sam to flip the switch for it. It’s sparse and will need lots of attention too.

    Thank you everyone for understanding the crazy that goes on with all this, and for being patient. It’s been a long 7 months for me working on all this.

     
    • Clifford Paulick 6:46 am on July 29, 2016 Permalink | Log in to Reply

      Thanks for all the effort! Feel free to let me know if there’s some way I can help.

    • FolioVision 12:37 pm on July 29, 2016 Permalink | Log in to Reply

      Hi Mika. If you need any help with copyediting, please let me know.

      PS. Freezing the plugins of authors who don’t have working emails seems to be a reasonable step to me. Not sure how you should deal with the autoresponder types who do eventually answer though. You have my compassion (I deal with a lot email too).

      • Ipstenu (Mika Epstein) 3:55 pm on July 29, 2016 Permalink | Log in to Reply

        If someone with an auto-responder fixes the issue, we reopen the plugins. Simple as that 🙂 We’re not terrible people after all, and we strongly believe in second chances.

        Of course, if it happens again…

    • Mark O'Donnell 4:51 pm on July 29, 2016 Permalink | Log in to Reply

      Hi Mika,
      Thanks for all you do. I’ve done a lot of tech writing and editing in a former life, and I’d be happy to help wherever I can.
      -Mark

    • M Asif Rahman 7:54 pm on July 29, 2016 Permalink | Log in to Reply

      I would to love to help out, Mika. Let’s get it going.

    • Raam Dev 10:23 pm on July 29, 2016 Permalink | Log in to Reply

      Thank you, Mika! I’d love to help review and edit.

  • Ipstenu (Mika Epstein) 1:36 am on July 14, 2016 Permalink
    Tags: , repository   

    New Repo Open Beta 

    Please review the proposed new repository and leave some comments so Obenland can make all more awesome.

    Plugin Directory v3 Open Beta

     

     
  • Ipstenu (Mika Epstein) 4:36 pm on July 6, 2016 Permalink |
    Tags: , , repository   

    Repository Guideline Reminder: Do Not Remote Load Content 

    In a very irregular feature, we’re posting about various plugin guidelines and what they really mean to you.

    This week, we want to remind you about a long-standing guideline in the repository, which is covered in item #7 – Don’t phone home without consent.

    No “phoning home” without user’s informed consent. This seemingly simple rule actually covers several different aspects:

    The guideline goes on to break down what we mean in four main points:

    1. No unauthorized collection of user data
    2. All images and scripts shown should be part of the plugin
    3. No 3rd party ad tracking
    4. No ad-spam

    That second item (which I emphasized) is what we want to remind you of today.

    Your images, your scripts, your CSS, etc, should all be included locally. Besides not tracking users, keeping everything locally will make your plugins faster. It obviates the problem of external load. It means when your server is down for maintenance, you didn’t just slow down everyone’s wp-admin. It means you’ll never DDoS yourself on accident.

    Unless you’re a service, your plugin has no business phoning home to your own servers to load data. If you are a service, you must have this clear in your readme as to what the service entails, preferably with a link to your ToS and and explanation as to what is tracked. This is for your protection. By remote loading files, you have the ability to track users. Data tracking is a huge deal, and while we understand you want to do it for metrics, it someone was taking your data without permission or consent and selling it or using it to promote their code, you’d be pretty ticked off.

    You can (and should) re-read all the guidelines on https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/ – we rarely change them though we may reword things for clarity.

    If you have suggestions as to how we can be more clear about #7, please leave a comment and let us know.

    Keep in mind, we’re not going to spell out everything to the letter, as in our experience that leads to people playing nit-picky fake-lawyers about everything, and still violating the ultimate rule of the guidelines which is ‘Don’t be a spammer.’ For example, we’re not going to make a rule for not stealing other people’s plugins. You already know stealing is bad, right? 😈

     
    • vovafeldman 12:58 am on July 7, 2016 Permalink | Log in to Reply

      Hey Mika, I totally understand the not phoning home guideline. What is the reviewers’ view on using JS libraries from popular CDNs like MaxCDN, ClodFlare… It’s beneficial for the site owner because it’s reducing the load to the CDN (efficiency, speed and $$$ wise), it reduces the size of the plugin so it saves storage on the SVN repo, etc.

      Just a thought, maybe you can create a collection of “approved” CDNs, or create a WP.org CDN for the community. What do you think?

      • Ipstenu (Mika Epstein) 5:42 am on July 7, 2016 Permalink | Log in to Reply

        We currently do not recommend cdns for us libraries for a related reason – unnessecary dependencies. If the cdn is blocked, like if you’re on a private network, it causes a terrible experience to the user.

        Fonts are our only exception, and even then I caution developers often, as google fonts are NOT universally accessible.

        Edit: also it’s not as much of a money/speed gain as you’d think :/

    • Joel James 5:19 am on July 7, 2016 Permalink | Log in to Reply

      Hey @ipstenu,

      What if we ask for user permission to place a link, then place a link to the public site when search engines or bots (not real users) visits the site? Is that illegal?

      • Ipstenu (Mika Epstein) 5:46 am on July 7, 2016 Permalink | Log in to Reply

        Please don’t use the term ‘illegal’ – it’s an incorrect term.

        Short answer: don’t do it

        Long answer:

        Strictly speaking, it would be permissible in the guidelines, especially if you make it clear that’s exactly what’s happening.

        Now that said, you’ll screw up your SEO like that, because Google can tell when you’ve made bot/search engine only content. And they consider it a scam.

        So … Y’know, don’t 🙂 it would end badly for you, it would hurt your SEO, it MIGHT hurt that of the sites you’re linked from. It is a terrible idea.

        • Joel James 6:06 am on July 7, 2016 Permalink | Log in to Reply

          Yup 🙂 When we say SEO, it is Google. Lol.

          Thanks @ipstenu

        • chesio 1:41 pm on August 17, 2016 Permalink | Log in to Reply

          @ipstenu, and still he did [link removed]

          I know that you are already aware of this situation. It just irritated me when I found @joelcj91 claiming “he was honestly not aware of this” [link removed]

          I hope he has learned his lesson well.

          • Ipstenu (Mika Epstein) 4:51 pm on August 17, 2016 Permalink | Log in to Reply

            I’m aware of the situation, I’ve spoken directly, privately, respectfully with Joel about the issue and why it was bad and what exactly was bad. It is my belief that this was a monumental screw up, and that he wasn’t aware of ‘this’ meaning he didn’t realize what his partner did.

            There are nuances to the ‘no remote loading’ that people often misunderstand. I don’t expect everyone to read my mind, and I know the quality of the guidelines is pretty bad right now. I am actively working on better ones to make things easier to understand.

            We can move on now and stop dog shaming people.

          • Joel James 5:29 pm on August 17, 2016 Permalink | Log in to Reply

            @chesio,

            Yes, I learned well.

            I never said(or at least I never meant) I was not aware about the remote loading. But I was not aware about the remote content changes he made. That made this serious spam.

            Also I misunderstood this – “Strictly speaking, it would be permissible in the guidelines, especially if you make it clear that’s exactly what’s happening”.

    • Paul de Wouters 8:09 am on July 7, 2016 Permalink | Log in to Reply

      Does this mean a plugin cannot retrieve content from an API then?

      • Ipstenu (Mika Epstein) 2:34 pm on July 7, 2016 Permalink | Log in to Reply

        An API is a service, is it not? Services are noted, in this post and the guidelines, as being an exception.

        Make sure it’s clearly documented in the readme that your plugin uses a service, link to the service, explain how to sign up for it or what the tos are.

        • Paul de Wouters 6:42 am on July 8, 2016 Permalink | Log in to Reply

          thanks for clarifying. I personally didn’t know “service” had that meaning in this context

        • Paul de Wouters 6:44 am on July 8, 2016 Permalink | Log in to Reply

          we’re not a “service” though, we just just retrieve content via a call to the WP API on a remote site.

          • Ipstenu (Mika Epstein) 8:44 pm on July 11, 2016 Permalink | Log in to Reply

            I’m not really psychic 🙂 When you said “an API”I assumed “An external system or service that provides information not otherwise available to a WordPress site.”

            Now turning around and saying “The WP API” doesn’t make the source of your data any more clear to me. If you said “This plugin reaches out to the WordPress.org plugin API to pull in data…” I would still say “Document it as a service.”

            If you’re calling data from outside the user’s site and server, then the user MUST know. Plain and simple 🙂

    • Nathan Johnson 5:03 pm on July 7, 2016 Permalink | Log in to Reply

      FYI, WordFence attempts to load their logoon the dashboard widget from their domain.

      • Ipstenu (Mika Epstein) 8:56 pm on July 7, 2016 Permalink | Log in to Reply

        In general we ask you email `plugins@wordpress.org` with that, so as not to public shame people. I’ll contact them, though. Thank you for letting us know.

    • Chuck Reynolds 2:44 am on July 15, 2016 Permalink | Log in to Reply

      like this one i just found? [redacted]

    • chesio 1:46 pm on August 17, 2016 Permalink | Log in to Reply

      Remote loading of content can also result in security issues when plugin domain expires: https://blog.sucuri.net/2016/08/plugin-expired-domain-security-threat.html

  • Ipstenu (Mika Epstein) 8:44 pm on June 26, 2016 Permalink |
    Tags: repository   

    WCEU Contributor Day 

    I want to thank everyone for coming to the first ever plugin review contributor workshop!

    We did not get half as much covered as I’d like to but I hope that we were able to enlighten some of you as to how the repository and review system works.

    I’m looking forward to the near future when we’ll be able to start adding some of the wonderful people who came to contributor day to the review team! Since that’s still a bit in the future, what we can do right now is welcome everyone to #pluginreview !

    Slack

    That’s right, we have #pluginreview as a channel now. This channel is for us (yes, you and us) to talk about plugins, finding issues like base64 and creative commons code. At this time, in order not to put users at risk, please continue to send security issues to plugins@wordpress.org only.

    I plan on posting some plugins for you to download and look at and discuss, as well as possibly have open hours or a scheduled time every once in a while to talk about reviewing a plugin as a group.

    Also if you have a question about the plugin repository in general, please feel free to ask there. Please remember to be reasonable, though, and try not to ask “When will my plugin be reviewed?” 😁

    Getting Started

    In the mean time, what can you do to get started?

    First, read the guidelines. Read all the guidelines. Memorize them. Be familiar with things like phoning home, and the difference between a serviceware API and a license check that cripples software needlessly. Don’t worry too much about that, but do get familiar with the guidelines.

    Next! Grab the Mark Jaquith Plugin Directory Slurper. The repo is about 25 gigs, more or less, and will take you a few hours to download. By a few what I mean is set your laptop not to sleep, put it in a cool room with a fan, and go to bed. The Slurper doesn’t work well on Windows that I know of (sorry Windows people). Anyone who wants to improve that, pull requests and forks are welcome.

    Now once you have the whole repo, start poking at things. Look for code you know is not allowed in the repository (non-GPL is a great start, pick a popular library you know isn’t GPL and grep or ack for it).

    Talk about what you find in the Slack channel. Remember: Slack is public. Do not post anything rude, insulting, antagonistic, or mean there. Also don’t post security issues there. Please keep that to email.

    Finally, if you’re really super into code ideas, download the (broken) Plugin Check plugin! Have a look at it. Try to figure out how you’d make it work, and maybe fork it onto GitHub and start tinkering. Start with the basics (check for non GPL, calling wp-load directly, including jquery etc) and see how far you can get. More hands make light work, after all.

    When Will We Accept New Members?

    Soon! I’m sorry, but I just don’t have an ETA.

    We need the UX for the repository revamp to be usable and acceptable first. Until then, we’re on that lousy, single-threaded, bbPress setup. Once that changes, the plan is to start letting people apply (and yes, we will post requirements for that) and adding them with access to review privately. Think of it as moderated reviews. But trust me here, we can see the end and we have a plan.

    We’re like Cylons.

     
  • 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: , 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

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