WordPress.org

Make WordPress Plugins

Tagged: directory Toggle Comment Threads | Keyboard Shortcuts

  • Ipstenu (Mika Epstein) 4:58 pm on August 29, 2016 Permalink |
    Tags: , directory   

    WordPress Plugin Directory 

    The WordPress Plugin Repository is rebranding as the WordPress Plugin _Directory_.

    As “directory” refers to the entire plugin hosting service (the site, VCS, etc) and “repository” conventionally refers more specifically to just a VCS (such as GitHub, SVN, etc), we feel this will be less confusing and more in-line with the other aspects of WordPress.org.

    We’re in the process of updating all our documentation.

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

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

    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: design, directory,   

    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) 5:58 pm on March 1, 2016 Permalink |
    Tags: directory, ,   

    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.

  • Samuel Wood (Otto) 10:26 pm on February 12, 2016 Permalink |
    Tags: active installs, directory, plugins, selling, spam   

    On the Topic of Selling Your Plugins… 

    Unlike the title might suggest, this post is not about buying a plugin from a commercial author, or the viability of “freemium” plugins in the directory, or app stores, or anything of that sort.

    This post is directed squarely at plugin authors.

    Question: Who owns your plugin?

    The answer is simple: You do. You wrote it. You hold the copyrights on it.

    Now hold on a minute (one might say), everything in our directory is GPL or compatible. Isn’t that copyleft? Well, yes, and I’m not going to go into excessive amounts of legalese here (IANAL), but the GPL is built on top of copyright. It actually requires it. So yes, you do own the copyrights to your plugin, even when it’s available for free in the WordPress.org plugin directory.

    And yes, that totally means you can sell those rights to somebody else. We won’t stop you. Heck, if you ask, we’ll even help you perform the transfer correctly.

    Now, while we’ve talked about this before, it’s worth re-iterating because it has come up a lot recently: your name is on that plugin. If you sell it to some scummy spammer, then your name is likely to get dragged through the mud. Not by us, of course, we don’t name names. But other people do notice bad things happening, and they tell other people, and make posts in our forums, and leave bad reviews… and before you know it, you can get a bad rap for something you didn’t even do.

    There have been a lot of reports of various unsolicited emails recently asking plugin authors if they would sell their plugins. Sometimes these are legitimate offers. Not often. Usually it’s from marketing agencies looking to add backlinks.

    In a couple of notable cases, some of those plugin authors asked what the person was planning on doing to change the plugin. Surprisingly they responded and told them. Let’s just say that these plans are very much against our guidelines.

    In at least one case, the plugin author told this prospective purchaser as much, and the person responded by asking how long it would be in the directory before we shut it down, and how many sites could he get the code to before getting this noticed and thus removed from the directory. He even asked whether it was a manual or automatic process (hint: it’s both).

    Yes, this guy was actually that blunt about his plans.

    While my evidence is slim, I believe this particular person is a Russian spammer or hacker looking to add malware into the plugins and get this code onto as many sites as possible before we put a stop to him.

    What can I say? WordPress is a big target. Some are going to try to abuse the system. We’re used to that. Now you plugin authors will need to get used to it too, because you can be a target for this sort of thing as well.

    People offering to buy your plugin are generally spammers. They’re probably using fake email accounts, and offering you false information as well. They may be able to pay you, but understand that what they’re looking for is to buy heaps of unrelated plugins, modify them all with SEO spam like backlinks or potentially even malware, and get our systems to push those things to as many sites as possible before we notice and shut them down hard.

    Do you really want to sell your plugin to somebody like that? Do you want your hard work to be abused and to have your good name tarnished?

    Think twice before selling your plugin. Know the person you’re selling it to very well. Ignore unsolicited emails from people you don’t know. If they are going to pay you based on the number of “Active Installs”, then just don’t even consider it.

    Don’t worry about the plugin review team too much though. We can find and shut these things down very quickly, even in real-time. But it does help us quite a bit if you ignore these types of scammers too. 🙂

    But if you do decide to give your plugin to somebody responsible and real and who actually cares about it, make sure they know about the Plugin Directory Guidelines. Because hosting a plugin in the WordPress.org Plugin Directory is a privilege, not a right. We can and will act to remove and stop plugins in our systems from doing bad things, no matter who “owns” them.

     
    • Eric Amundson 12:17 am on February 13, 2016 Permalink | Log in to Reply

      Great post, Otto!

      I’ve received at least a few unsolicited emails asking to buy plugins and I figured they were up to no good as their company had nothing to do with WP development. Like you said, they were marketing agencies.

      Glad to know there are some automated ways to spot and remove bad, or compromised plugins.

    • FolioVision 12:44 am on February 13, 2016 Permalink | Log in to Reply

      Good post Otto. I’m just curious about why you said the person is a Russian spammer or hacker. Do you have specific grounds or is this just kneejerk MSM “blame the Russians” for everything?

      There are plenty of American spammers and scammers. I in specific had contact from some agency in New York, David something or another (can’t find the email now or I’d name names). They said they just wanted to stick advertising in one of our plugins.

      • Ipstenu (Mika Epstein) 12:55 am on February 13, 2016 Permalink | Log in to Reply

        It’s based on the evidence in the emails (header information, urls provided, etc). He has specific grounds.

        • FolioVision 2:37 am on February 13, 2016 Permalink | Log in to Reply

          Well at least he was honest about his dark plans for world domination via underhanded plugin purchases! Good luck with the automated tools to suss out these issues when they happen. I suppose you are running a filter on outbound links added to plugins when updated, both in documentation and PHP, as well as particular patterns in the PHP (which will catch most of the lightweights). An account used once this way is lost forever. Most such buyers would have plugins arriving on accounts with very limited previous WordPress.org participation.

          Thanks for fighting the good fight!

    • JasWSInc 12:58 am on February 13, 2016 Permalink | Log in to Reply

      > Yes, this guy was actually that blunt about his plans.
      Crazy. Thanks for passing this along 🙂 Appreciated.

    • Maeve Lander 1:10 am on February 13, 2016 Permalink | Log in to Reply

      Good post, thanks Otto. I’ve received emails like this and sent them straight to spam but they can look quite convincing on first read.

      Another disturbing thing I’ve noticed recently is marketing/dev companies going through the wordpress.org plugin support threads collecting URLs and email addresses of users having difficuclties, then contacting those users privately with offers of paid assistance. Poor form. And extremely anoying when the user then contacts me as the plugin dev saying “is this you guys or some other chancer” or “can I get some support for this privately cos I don’t want to post my link in the forum”.

    • Arnan de Gans 3:23 am on February 13, 2016 Permalink | Log in to Reply

      I’ve had people approach me over the last 2 years with stupid offers of buying my AdRotate plugin (https://wordpress.org/plugins/adrotate/) from me.
      Some even had the audacity to offer me as little as $5000 for it. Some were willing to go up to $50-70k.

      All appeared to be from India or had names that suggested they were from India.

      The plugin would be “repurposed for marketing goals” or they wanted it because of the user base and they would take the plugin in a “different direction”. All the while crediting me for the original code. As if that is doing me a favour. Hah.

      But… Another thing I noticed from a few of those dudes. They were just after my financial details.
      Trying to find out how rich I am. Who I used to process money. How much income I generate from plugins.Things like that…
      While not irrelevant when selling a plugin, the way they went about these questions made me wonder if they wanted the plugin at all or were just looking for a “best practise” business model to use for whatever they were up to.

      So also beware of people asking about how you run your business 🙁

      Does WordPress/Moderators have a mechanic to report people like this?
      If not, is it an idea to have this? We authors could send suspicious stuff to plugins@wordpress.org for example and after a quick examination of the email exchange the WP team could build a blacklist or something. Such a list can be simple enough. Something like a list; Name, Company, Category, last received report, how many reports received.

    • Milap 7:18 am on February 13, 2016 Permalink | Log in to Reply

      Very useful post Otto. I have my own plugin with more then 60k+ active installs, and i got 3 offers in last 3 months to sell it. They tried to trap me with their healthy money offer, but i denied them every times as i found something wrong with their offer, and i am happy & proud of that decision. WordPress and all related repositories must be remain clean and we developers will always try our best to achieve that.

    • Rene Hermenau 11:53 am on February 13, 2016 Permalink | Log in to Reply

      I ignore such mails, especially when there is no full contact address in their mails. These guys are using freemail address without any other contact data. In 99% of the inquiries you can be sure they are with a bad taste, especially when these guys are entirely unknown in the developer community.

    • George Notaras 7:06 pm on February 13, 2016 Permalink | Log in to Reply

      Great post! Yet another one in a series of great posts lately in the plugins make site!

      As far as I can remember, I haven’t received any such emails. (Or maybe I sent them to the spam box before reading far enough to know what they were about..)

      Trying to think about this for a while from the user perspective and how users could feel safe about their web site after the change of ownership of one of the plugins they use, I always come to the same conclusion: Currently such a change could go unnoticed by the user, but this would not be ideal for most of them as they would possibly want to re-evaluate this new plugin status and make a decision whether to continue using it or not. An ownership change may mean a lot of things, as it has already been mentioned in the post and the other comments, and I think the burden of a decision about whether the plugin should continue to be used is too big and complicated to be taken by wordpress org alone, but the user should also have to decide.

      An idea about chaining all these events together would be the following:

      1. The plugin guidelines could force the previous owner of the plugin to make one last release after having changed the author field name to that of the new owner. This would be just to trigger a notification in WP.
      2. A mechanism could be implemented in wordpress, which (on every plugin update) could compare the author field of the currently installed version of the plugin to the respective field of the updated version. In case these differed, a pop up could be displayed or a notification could be sent (in case of automatic plugin updates) indicating that extra user action should be taken before the update of the plugin could continue. That extra action could just be the acceptance of a confirmation dialog.

      Of course this is not to exclude all the automated or manual testing that takes place at wordpress org.

      This is too simplistic, but I’m sure you get the idea of what I’m trying to say with this example, which is to transfer the final decision of continuing using the plugin to the end user.

    • Jacob N. Breetvelt 9:10 am on April 18, 2016 Permalink | Log in to Reply

      Hi,
      I am the autor of plugin wp-photo-album-plus https://wordpress.org/plugins/wp-photo-album-plus/ and i received an email from Mohammad Noman who wants to buy all the rights of my plugin.
      Does anyone of you know him and/or how do i have to act upon this? He ‘looks’ to be seriously interested to me, but i do not have experience with this kind of things. Can anybody advise me?

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

    Making Better Banners for your Plugins 

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

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

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

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

    Old:

    ninja-forms-plugin-hebrew-old

    New:

    ninja-forms-plugin-hebrew-new

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

    Old:

    yoast-seo-plugin-hebrew-old

    New:

    yoast-seo-plugin-hebrew-new

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

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

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

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

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

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

    And how it looks on the plugin page:

    https://wordpress.org/plugins/pluginception/

    pluginception-banner-ltr

    https://he.wordpress.org/plugins/pluginception/

    pluginception-banner-rtl

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

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

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

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

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

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

        Joost: Keep reading. 🙂

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

        (Ugh, hit enter too early): so we’ll actually update ours.

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

          If you’re interested, this is entirely implemented with CSS, and the data is available to the core installs via the API, so getting this in core should not be difficult. Might be a bit late for 4.4 though. Oh well, it can wait for 4.4.1 or what have you.

          • Ahmad Awais 6:59 pm on November 12, 2015 Permalink | Log in to Reply

            That’s true! Would be fun, though. I think this is a much better way to deal with this problem. Thanks for implementing it Samuel.

      • FolioVision 1:11 pm on December 3, 2015 Permalink | Log in to Reply

        Two banners is certainly aesthetically offers much more scope for creativity and design. Last time I checked WordPress was not by programmers for programmers product (functionalism only). Design questions matter.

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

      In other words, plugin authors has two options:

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

      2. Create two banners for LTR and RTL views.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    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?

  • Samuel Wood (Otto) 6:12 pm on June 9, 2012 Permalink |
    Tags: directory, plugin, readme, , svn   

    The Plugins directory and readme.txt files 

    Every once in a while, somebody pings me to say that their plugin isn’t showing up properly in the directory. Almost always it’s a problem with the plugin itself having incorrect information somehow. So I thought I’d do a quick post to explain some aspects of the plugin directory, and explain some of the more obvious stuff which a lot of people miss.

    Layout

    First, let’s briefly go over the layout of your plugin in the SVN repository. There’s three directories created by default, and an optional fourth one that you can create yourself.

    Trunk: The /trunk directory is where your plugin code should live. The trunk can be considered to be the latest and greatest code. It’s the development version. Hopefully, the code in trunk should always be working code, but it may be buggy from time to time because it’s not necessarily the “stable” version. For simple plugins, the trunk may be the only version of the code that exists, and that’s fine as well.

    Tags: The /tags directory is where you can put versions of the plugin at some specific point in time. Usually, you’ll use version numbers for the subdirectories here. So version 1.0 of the plugin would be in /tags/1.0, version 1.1 would be in /tags/1.1, and so forth. Again, not every plugin uses tags for versioning.

    Branches: The /branches directory is a place that you can use to store branches of the plugin. Perhaps versions that are in development, or test code, etc. The WordPress.org system does not use the branches directory for anything at all, it’s considered to be strictly for developers to use as they need it.

    Assets: The last optional directory doesn’t exist by default (Edit: It does now, older plugins may be missing it, but all newly added plugins will get it by default.) You can create it yourself though. Just make a directory called “assets” next to those other three directories. Assets currently only has one use, which is to store the banner image to be displayed on your plugin page. We may use it for more things in the future. For now, you can just make an image, name it banner-772x250.png or banner-772x250.jpg, and put it in there. Easy.

    Additional Info: Since creating this post, some new files have been added to the assets folder. You can create a banner-1544x500.png or banner-1544x500.jpg now too. This high-resolution banner will be shown to users with high-resolution displays, such as phones or tablets or certain newer laptops. Additionally, screenshots which once lived in the plugin’s own directory can now be moved from there into the assets directory. This allows the screenshots to be shown on the plugin page, but not included in the download of the plugin, reducing file size. It’s recommended to put screenshot files in /assets.

    Parsing the plugin information

    All plugins contain a main PHP file, and almost all plugins have a readme.txt file as well. The readme.txt file is intended to be written using a subset of markdown.  The example readme.txt explains most everything pretty well, but there’s a few little tidbits that are worth pointing out.

    First is the concept of the “Stable Tag”. When WordPress.org parses the readme.txt, the very first thing it does is to look at the readme.txt in the /trunk directory, and then read that “Stable Tag” line. If the Stable Tag is missing, or is set to “trunk”, then the version of the plugin in /trunk is considered to be the stable version. If the Stable Tag is set to anything else, then it will go and look in /tags/ for the referenced version. So a Stable Tag of “1.2.3” will make it look for /tags/1.2.3/.

    Important bit: Everything else is read from this new location. If the Stable Tag is 1.2.3 and /tags/1.2.3/ exists, then nothing in trunk will be read any further for parsing by any part of the system. If you try to change the description of the plugin in /trunk/readme.txt, and Stable Tag isn’t trunk, then your changes won’t do anything on your plugin page. Everything comes from the readme.txt in the file being pointed to by the Stable Tag.

    Now let’s get to the plugin information itself. The WordPress.org directory reads the main plugin PHP file to get things like the Name of the plugin, the Plugin URI, and most importantly, the version number. On the plugin page, you’ll see the download button which reads “Download Version 1.2.3” or similar. That version number comes from the plugin’s main PHP file.

    Some people get this versoning confused due to the tags system. The Stable Tag points to a subdirectory in the /tags directory. But the version of the plugin is not actually that, it’s the version that is listed in the plugin’s PHP file itself. If you have changed Stable Tag to 1.4 and the plugin still says 1.3 in the PHP file, then the version listed will be 1.3.

    Readme.txt pieces that everybody gets wrong

    Back to the readme.txt. There’s a line called “Contributors”. This line has always been expected to be WordPress.org usernames only. WordPress reads those, gets information about that user, gets their gravatar, name, etc, and makes the authors listing. If you put anything here that’s not a WordPress.org username, then it doesn’t look nearly as good. No picture, no link, just text.

    Other information in the readme.txt is read and used at various points on the Plugin listing. The Donate link makes a “Donate to this plugin” link in the sidebar. The “Requires at least” and “Tested up to” fields are used for compatibility checking, even on the WordPress installation itself. Few people get these wrong.

    One thing a lot of people get wrong is this line:
    “Here is a short description of the plugin.  This should be no more than 150 characters.  No markup here.”

    That bit is serious, and you should read it again. That one line people get wrong more often than anything else. That line of text is the single line description of the plugin which shows up in big letters right under the plugin name, and if it’s longer than 150 characters, it gets cutoff and makes your plugin page look silly.

    Markdown allows for easy linking in your readme.txt as well. Just write like this to link a word to a URL:

    [WordPress](http://wordpress.org)

    Videos can be put into your readme.txt too. A YouTube or Vimeo link on a line by itself will be auto-embedded. It’s also possible to embed videos hosted on VideoPress using the wpvideo shortcode. More on that topic here: http://wpdevel.wordpress.com/2010/02/20/plugins-can-now-include-videos-in-their-readme-txt-files/

    Summary

    I don’t think I covered everything, but hopefully that will explain some of the more obscure features of the directory and how it works. If it reduces the number of times people send me the question “why didn’t my version change show up in the directory”, then I think this post was time well spent. 🙂

     
    • Marcus 7:32 am on June 10, 2012 Permalink | Log in to Reply

      I must admit, I’ve made one or two of these mistakes starting off 🙂

      Useful article, it would go great linked somewhere in the developer center, as I’m sure that’s where people starting would look first.

    • Lance Cleveland 2:37 pm on July 12, 2012 Permalink | Log in to Reply

      Don’t forget about the new “high definition” banners for the header image. If memory serves this is twice the resolution of the standard banner in the assets directory at 1444×500.

    • Mike Schinkel 7:16 pm on August 3, 2012 Permalink | Log in to Reply

      Just replying so I can get subscribed to this blog (might be another way, but can’t figure out how.)

    • Brad Touesnard 3:53 pm on August 17, 2012 Permalink | Log in to Reply

      @Otto Would it be possible to start supporting the filename README.md in addition to readme.txt? A lot of developers host their plugins on GitHub as well but the filename readme.txt isn’t run through the markdown parser at GitHub. It would be nice if .org supported the README.md filename as well.

    • Gwyneth Llewelyn 10:12 pm on November 18, 2012 Permalink | Log in to Reply

      Ok, I’m a bit confused now.

      “If the Stable Tag is 1.2.3 and /tags/1.2.3/ exists, then nothing in trunk will be read any further for parsing by any part of the system. If you try to change the description of the plugin in /trunk/readme.txt, and Stable Tag isn’t trunk, then your changes won’t do anything on your plugin page. Everything comes from the readme.txt in the file being pointed to by the Stable Tag.”

      So if I understand this correctly, the best way to deal with this scheme is simply to have a single file under /trunk/, which is readme.txt, and that needs only to hold 9-10 lines or so with the headers — and just point to the “Stable Tag”? Then the *rest* of the readme.txt *which is under the tag, not trunk* will be read & parsed instead? I don’t need to have a full copy of readme.txt both under /trunk/ *and* /tags/X.Y.Z/ ?

      You see, I hate unnecessary file duplication 🙂 I love the idea of having a super-small, 9-line only, readme.txt file under /trunk/ which just points to the correct place. Also, it makes this far easier to revert to earlier versions in case something goes seriously wrong!

      Sorry if all of this sounds incredible obvious to you seasoned plugin developers 🙂

      • Gwyneth Llewelyn 10:44 pm on November 18, 2012 Permalink | Log in to Reply

        Maybe all that’s needed on trunk/readme.txt is 2 lines after all:

        === Plugin Name ===
        Stable tag: X.Y.Z

        Is that right? The remaining readme.txt will come from tags/X.Y.Z instead? If so, this is just awesome!

      • Samuel Wood (Otto) 4:38 am on November 19, 2012 Permalink | Log in to Reply

        Yes, that works.

        No, you absolutely should not do it that way.

        There is a *convention* in place here. People expect trunk to contain the latest development code of your plugin. In other words, the latest and greatest code, unstable changes and all, belongs in trunk. The latest stable, versioned, tagged code, will be in a tags directory.

        The directory is based around this concept. There are beta-tester plugins which assume this to be true. Forget about “duplicated files”, do it the way everybody else does it so that you don’t mess up the friggin’ system. 🙂

        Put your development code in trunk. Tag the ready-for-release versions of the code in the tags directory. This is the best way to manage things. Even repository systems such as git and github have the concept of a main trunk for development and tags for versioning. The goal isn’t to make things easier for you to manage, the goal is to make the code accessible to everybody else in a sane way.

        • Gwyneth Llewelyn 4:42 pm on November 19, 2012 Permalink | Log in to Reply

          Thanks for the clarification and I do apologise if I have understood you wrongly. Maybe you should clarify that duplication of everything continues to be mandatory, and not optional, to stick to conventions. Your article, read in a certain light, seemed to convey the idea that the convention was changed exactly for the benefit of keeping things simple.

          I’m not here to discuss what is better and what is not — I’ve just asked the question on how to do things from now on because the article lead to believe me that the convention had changed, or, if it hadn’t, that “beginners were always making mistakes and can do things in much simpler ways if they understand the directory structure better”. And I appreciate your answer: no, nothing has changed.

          “The goal isn’t to make things easier for you to manage”. Why not? KISS is always a good philosophy, IMHO.

          • Samuel Wood (Otto) 4:59 pm on November 19, 2012 Permalink | Log in to Reply

            It’s not really duplication though. SVN doesn’t store files that way, it really just stores changesets. The trunk/tags/branches convention is SVN’s, not ours. You can tag things using an svn copy operation, and that’s not making new files in svn, just marking copies of the files at a specific point in time.

            The Stable Tag and readme.txt stuff is indeed ours, simply for the purpose of keeping things in the directory sane.

    • brasofilo 2:08 pm on December 18, 2012 Permalink | Log in to Reply

      Finally I got the /tags/ concept and am correcting a wrongful use of the “Stable Tag” (I had it declared, but the version was not present in the tags folder), although the system was kind enough to make it work.

      Now, I’m looking for articles on how to use the /trunk/ when developing a new version of the plugin.
      I mean, is it possible to install and update from there?

      • Samuel Wood (Otto) 5:56 pm on December 18, 2012 Permalink | Log in to Reply

        Trunk should be the “beta” version, and have its version numbers indicating such. So if my Stable Tag was like 1.0, and I had a /tags/1.0 directory, then I could make trunk’s version into 1.1-beta or something like that, and make all the changes I liked, then when it was ready for release, change it to 1.1 and tag it and update the Stable Tag field in the readme.txt to point to the new one.

        If you use this sort of structure, with trunk containing the latest beta code, then you can easily use a plugin like https://wordpress.org/extend/plugins/plugin-beta-tester/ to update to that beta version on a site.

        • brasofilo 7:29 pm on December 18, 2012 Permalink | Log in to Reply

          Perfecto, Otto, gracias!

        • Hinjiriyo 1:56 pm on January 31, 2014 Permalink | Log in to Reply

          Now I got the concept of the trunk dir! Thank you very much for your explanation.

          There are other informations about the way the readme file and tag files are processed by the WP plugin repo. I wish someone would extend the Plugin Developer FAQ with that article and the role of the trunk.

    • amineoujda 10:09 am on July 16, 2013 Permalink | Log in to Reply

      Hi,
      I want to change the line description that appears below the plugin name

    • bendoh 4:44 pm on January 22, 2014 Permalink | Log in to Reply

      Hey,

      Is there any sort of documentation as to the exact subset of Markdown that’s being used on these readme.txt files, or could you perhaps point me to the code that’s actually producing the rendered markup?

      I just submitted a plugin with standard Markdown list formatting, (e.g., * Item 1\n*Item 1) in the readme.txt, and it was not rendered correctly on the plugin page: it just appeared all together in one paragraph without any markup.

    • duck__boy 9:32 am on April 14, 2014 Permalink | Log in to Reply

      A very will written post, but I must admit, I’m still struggling with the `readme.txt` file. I suspect I’m just missing something, but I’m hoping you are able to help.

      I have both a version of my plugin with the `readme.txt` file, in the `/trunk` and `/tag/1.2.4` folders, but none of the details from `readme.txt` seem to be read, including the Stable Tag. This also means that the `Installation`, `FAQ` and `Changelog` sections are not available on the plugins `Details` page).

      So taking the above in to account, if I change the version number of the main PHP file in `/trunk` to say `1.3-beta`, that version number is shown when you search for my plugin, and my `/tag/1.2.4` file is ignored.

      The plugin in question is https://wordpress.org/plugins/admin-bar-button/

      • duck__boy 3:31 pm on April 22, 2014 Permalink | Log in to Reply

        Just in case anyone ever runs in to this, my issue was that my `readme.txt` file was not encoded as ANSI for some reason. I simply recreated the file using the correct encoding and all is now good with the world (well, my plugin anyway…).

    • Chip Bennett 5:02 pm on April 22, 2014 Permalink | Log in to Reply

      @Otto42 is there any chance that the readme parser could be changed so that it reads “Tested up to” and “Requires” from the trunk copy of readme.txt? It would sure make it a lot easier for Plugin developers to update this information in the Plugin directory. As it is right now, we either have to update the readme.txt in the stable tag readme.txt, or else bump the version number just to indicate that the Plugin has been tested and works with the latest WordPress version.

      • Samuel Wood (Otto) 5:03 pm on April 22, 2014 Permalink | Log in to Reply

        You can edit the readme.txt file in a tagged version. SVN isn’t like Git, it doesn’t have a restriction preventing you from editing tagged versions.

        I’ll think about using the trunk readme for other things though, some of this seems like it might be a candidate for a refactoring.

    • Raghunath Gurjar 1:37 pm on June 17, 2014 Permalink | Log in to Reply

      Hi,
      I have released my plugin two version but still on plugin download page its show first release version 1.0 while when you will download my plugin , you will get all latest code.

      https://wordpress.org/plugins/simple-testimonial-rutator/
      You can also find developer log from here https://wordpress.org/plugins/simple-testimonial-rutator/developers/

      Can you someone help me please?
      I don’t know why this happening , i have updated the Stable tag in readme.txt file to 1.2

      • Samuel Wood (Otto) 5:25 pm on June 17, 2014 Permalink | Log in to Reply

        All information in the system is gathered directly from your plugin. If the displayed information is wrong, then your plugin is wrong.

        In this case, notice that the version number in the plugin itself is 1.0:
        https://plugins.svn.wordpress.org/simple-testimonial-rutator/tags/1.2/simple-testimonial-rotator.php

        Fix the plugin to have the correct information.

        • Natallya 7:21 pm on August 22, 2014 Permalink | Log in to Reply

          Hi, does anyone know how to get feedback for a plugin published?
          It’s more then month we sent it for review but no information at all. How can I know if it was declined ?

          Thank you!

          • Samuel Wood (Otto) 7:24 pm on August 22, 2014 Permalink | Log in to Reply

            We don’t have any plugins in the queue that have been there for more than a month. You would have received an email about it, and if we got no answer for 7 days, then it would be automatically rejected and you would receive an email about that too.

            Make sure that your email system is set up to never spam any emails coming from WordPress.org. We send emails for lots of things, but we cannot control what your end does with them.

          • Samuel Wood (Otto) 7:26 pm on August 22, 2014 Permalink | Log in to Reply

            Looking closer, it appears that your plugin was approved and you never continued on and did anything with it. Again, check your emails, your plugin was approved on the 11th of last month.

    • Natallya 5:46 pm on September 4, 2014 Permalink | Log in to Reply

      Thanks a lot, email had gone to junk… Setting up all further things. Thank you again for a good news! 🙂

    • JayDeep Nimavat 12:34 pm on October 4, 2014 Permalink | Log in to Reply

      Hello wordpress friend,

      I have created new version of “JDs Portfolio” plugin,

      I have done change,

      • deleted all folder and files from Repository trunk directory and uploaded new files and folder of new plugin version.
      • Created new directory 1.1 in Tags directory where 1.0 is already available and I uploaded all new files and folder of new plugin version in 1.1.

      The duration of uploaded new version plugin is more than one day.

      The problem is that it still give old version of plugin when anyone download it, and shows in Developer option as other version, as current version it display me old version 1.0.1 of JDs Portfolio plugin.

      Please help me to solve :
      How can I apply new version of plugin as current version?

      your good suggestion most appreciate,
      Thanks a Lot’s,
      JD.

    • salescart 4:45 pm on October 8, 2015 Permalink | Log in to Reply

      Ok, I’m sorry but I’ve read this and I’m still confused. We tried to make our first revision at https://plugins.svn.wordpress.org/e-commerce-by-salescart/tags/1.1.0/

      1.) So are you saying it still looks at the readme.txt file in the /trunk folder to find the stable tag, and based on that that, it then goes to that /tags folder for the plugin content and will ignore the rest of the content in the /trunk folder?

      2.) Or, are you saying the only released version is ALWAYS the version at the trunk? (This would be despite the readme.txt file’s stable tag saying 1.1.0 instead of trunk and that the tags folders is just for historical reference). Therefore, the /trunk version must be the most up-to-date version… ?

    • webbistro 9:29 am on January 10, 2016 Permalink | Log in to Reply

      Hello,

      I’ve read this carefully, and I uploaded new versions many times, but I am afraid I need help now. I am sure that all data is correct in my tag and trunk readme-s and in the main php, but I still see the old description, changelog, everything below readme’s header. The significant differences from the previous updates is that I am not receiving email notifications any more.
      Please help https://wordpress.org/plugins/enhanced-media-library/ (I know, too many actions… but I hoped I just did something wrong).

      Thanks!
      -Nadia

  • Andrew Nacin 8:51 pm on May 19, 2012 Permalink |
    Tags: directory, favorites,   

    Plugin Directory Refreshed — What It Means for Developers 

    Matt just announced on the WordPress Blog — and many of you have already noticed — a number of recent changes to the plugin directory, profiles, and the support forums. Now let’s go into detail all of the individual changes, and what it means for plugin developers.

    Design refresh for plugin pages.

    We’re glad to see so many of you use the plugin headers we launched in December. Now, we’ve provided a further refresh. We’ve made authors much more prominent and with bigger Gravatars and better placement, and cleaned up the styles for the ratings, support, and compatibility sections. There’s a great before-after shot in the announcement post.

    Support is now integrated into your plugin page.

    In the past, creating new support topics for plugins has been special, and not in a particularly good way. It had this specialness by overloading the tags in the support forums to indicate that a thread was about a particular plugin. No longer. We’ve promoted plugins up a notch and given them their own area.

    So now, on your plugin pages, you’ll see a “Support” menu in the header, and you’ll see the topics for that plugin in that tab. You’ll also find a submission form at the bottom of that tab, to add new support topics specifically for your plugin. Topics about plugins made from here get a special sidebar with links to the plugin, to the plugin’s FAQ page, and to the list of Support Threads for that plugin.

    While this section looks like it’s on the Plugin’s page, it’s not really. These support threads are actually in the same place they’ve always been, in the Support forums. What you’re seeing as far as the look and feel of that view of the support forums is just some clever trickery on our part. 🙂

    Akismet, for example, will have it’s “support forums” at this URL: https://wordpress.org/support/plugin/akismet.

    How to follow support threads for your plugins.

    You may want to take advantage of this by subscribing to the RSS feed for your plugin: https://wordpress.org/support/rss/plugin/akismet. Email subscriptions are not available for these yet, but we will be adding them this week.

    For plugin authors who have been using them, the old convenience views of plugin-committers and plugin-contributors are still there as well. (Committers are managed in on the Admin tab, while contributors are taken from readme.txt.) We’ll be exposing these links in more places, but you can use them with URLs similar to the following: https://wordpress.org/support/view/plugin-committer/Otto42 https://wordpress.org/support/view/plugin-contributor/Otto42. (RSS feeds exist for these as well.)

    Support statistics are now shown to users.

    You’ll notice a new area on the plugin page sidebar showing information about how many topics there are for your plugin, and how many of them have been marked as resolved. These are handy for users to see if questions are likely to get a response.

    You have had the ability to mark plugin support threads as resolved for some time now. It’s now really easy — you can mark a thread as resolved while making a post with a simple checkbox. Note that the user who opened the thread can also mark threads as resolved and unresolved. Threads that are marked “Not a support question,” such as suggestions or feedback, are not counted toward these stats and do not need to be marked resolved.

    Statistics will be based on a rolling two-month period, based on when the thread was opened. Currently, the statistics cover threads opened in the last two weeks, and will continue to increase until it reaches two months, to allow you some time to resolve existing threads.

    Managing your forum with sticky topics.

    You can now make threads “sticky”  threads to the top of your plugin’s support forum, just like the other forums on WordPress.org. (You’ll find a link “Stick topic to this plugin’s support forum” in the sidebar.) Threads marked as sticky will show at the top of your plugin’s Support tab. (They won’t be sticky on the regular forums.) We hope you find this handy for posting FAQs or other important information about your plugin.

    A new section for developers.

    Every plugin now has a Developers tab where you can find links for browsing the code in Subversion, the development log, and development versions. Here, you can now subscribe to get an email whenever a commit is made to a plugin repository, even if it isn’t yours. (You will of course continue to receive commits for your own plugins.)

    Favoriting plugins.

    As I’m sure you’ve now seen, plugins can now be favorited by logged-in users — and have been more than 2,000 times since we soft-launched this feature earlier in the week! When you favorite a plugin, it gets added to your profile. And if you’ve also rated that plugin, your rating gets shown.

    We expect to do a lot more with all of this in the future — favorites, plugins, support, and profiles. Until next time, we hope you enjoy these changes as much as we do!

    — written by Nacin, Otto, and Scott

     
    • Arnan de Gans 5:15 pm on May 21, 2012 Permalink | Log in to Reply

      Seriously?
      So i guess you’ve just rendered my own forum useless? Because i don’t want to give my users the impression i ignore support. Which your support stats will suggest if i keep ignoring the WP forums and use my own setup…
      And what’s up with this whole overhaul anyway, pulling visitors away from my plugin page by adding all these features. 🙁
      *sigh*

      • Andrew Nacin 10:02 pm on May 21, 2012 Permalink | Log in to Reply

        The plugins directory is a hosting site, not a listing site. Your “plugin page” is https://wordpress.org/extend/plugins/your-plugin/ — while it may provide you traffic to your own site, it’s designed to be a dedicated and trusted area for users. If plugin authors don’t keep up with support topics on WordPress.org, we can no longer glean any statistics, and it is more difficult for users to identify which plugins are supported. I have been really happy to see so many users already benefit from the new tools we are giving developers. That’s a win-win to me.

        We think — and I think you probably agree — that these changes provide a far better experience for individuals looking for help. By choosing to have two support forums, you’ve already fragmented the experience for your users. (I imagine they even need to create a second account to simply provide feedback or ask a question.) Now you are experiencing this same thing for yourself.

        We may consider the ability to specify a location for support in the future, but we’d like to try this out for a while. And at least on WordPress.org, we can also guarantee your users will be greeted with the proper spelling of WordPress. 😉

        • Jon Brown 4:20 am on May 22, 2012 Permalink | Log in to Reply

          Nacin – While that seems sensible on the surface, many plugins don’t lend themselves to a single forum for support and plugin author’s who’ve built forums with multiple topics…

          For example I note that both BuddyPress and bbPress link out to their own forums…. as they should since trying to answer the myriad of support requests under a single tag would be a nightmare. I am not a plugin author (yet), but I feel all plugin authors ought to have this same option available to them to link to their own support location.

          Further there is still no good easy way (that I know of) to search a single plugin’s forum to see if a topic has been mentioned and resolved previously which is what has always rendered the forums on WordPress.org minimally useful to me.

      • Marcus 12:24 pm on May 22, 2012 Permalink | Log in to Reply

        would definitely like this. tried resolving topics myself yesterday, not really up for it 🙂

        Touching on Arnan’s comment above, I must admit I do feel the same way somewhat. Whilst I do value being able to support on WP and agree that ideally (but may not be realistic) support should be on wp.org, I don’t think statistics is a productive feature, at least as it stands right now.

        Constructive criticism below:

        Take my (the author’s) point of view and my plugin – https://wordpress.org/extend/plugins/events-manager/

        The wp support forum is usually visited at least once a day during the week. I myself go through this plugin support forum every weekday when possible, yet as it stands right now the stats are:

        15 of 84 support threads in the last three weeks have been resolved.

        However, look at the forum, and you’ll see they’ve pretty much all been answered by me or angelonwl.

        There’s a few issues here right off the bat:

        • Various questions get resolved by the opener somehow, but the topic never gets updated.
        • Some things are just unreasonable to ask from the author (i.e. how do I completely change this plugin to do what I want?), yet they count as an unresolved question.
        • Various questions aren’t support questions.

        I’m sure there’s more, but the above is already enough to, in my opinion, make this a misleading bit of information.

        As an author, I’m now expected to keep track of 3 weeks of questions, and resolve them proactively, since <50% (way less) of users will update tickets when they resolve things themselves. What's worse, contributors can't help out. I think this is unreasonable, and whilst I don't mind making do, I think this will decrease the overall experience in WP, with some immediate downfalls:

        • Good plugins will likely get misleading support stats.
        • This will likely dishearten many authors, meaning less quality plugins being made for WP.
        • I’m sure you’ll see on the forum a “hey my issue isnt’ resolved!” because it’ll become tempted to resolve every topic one answers.

        I think the most important thing for you to implement to make this work would be some sort of auto-approve or nullify tickets that the creator doesn’t keep on top of (e.g. it becomes not a support question if the author doesn’t reply to our reply in say a week). Or maybe a response rate?

        Don’t even get me started on the works/doesn’t work stats too! 😉

        • Marcus 12:30 pm on May 22, 2012 Permalink | Log in to Reply

          by “would definitely like THIS”, i meant letting contributors be able to resolve tickets

        • Marcel 9:00 am on January 12, 2013 Permalink | Log in to Reply

          +1 for including response rate statistic. Many support requests cannot be resolved because users ask for functionality that the plugin does not, or never will, offer. A state like ’10 of 12 support threads answered by plugin contributor’ would give users a better insight in plugin contributors involvement.

    • Marcus 5:30 pm on May 21, 2012 Permalink | Log in to Reply

      Great work guys! The plugin page keeps looking better and better.

      Who can ‘resolve’ topics, by that I mean committers, contributors etc. of a plugin?

      Is there a way to add users that aren’t committers/contributors so topics can be resolved?

      • Andrew Nacin 6:41 pm on May 21, 2012 Permalink | Log in to Reply

        Committers can resolve topics. At the moment, there isn’t a way to grant someone permission to resolve topics without making them a committer. It might be something we add in the future.

    • Joost de Valk 6:37 pm on May 21, 2012 Permalink | Log in to Reply

      Awesome guys, thanks for all the hard work!

    • ray 8:57 pm on May 21, 2012 Permalink | Log in to Reply

      I’m looking for a like button on this page… thanks

    • Jason Caldwell 12:51 am on May 22, 2012 Permalink | Log in to Reply

      Just wanted to say thanks for the recent changes to the plugin directory, profiles, and the support forums. Great work over there!

      I do want to make a request though. PLEASE give plugin developers the ability to use their own external support forums. That is, please make it possible (perhaps through a readme.txt file), for developers to use an external support forum system of their own.

      Many of the best plugins thrive on support, and you can’t expect us to operate our support departments within an outline set forth by WordPress.org. That is, we can’t be expected to use the support system that WordPress.org uses (we need to use what works for us).

      I, like many other plugin developers, have my own administrative system, support forum system, along with employees to assist me. As the plugin directory exists now, all support is expected to take place at WordPress.org, which is just not realistic. This is only going to result in people getting the wrong impression about plugins in your directory, because they’re looking for (and expecting) support from the forums at WordPress.org. When, in reality, the support for many plugins occurs offsite. Let’s give plugin developers the ability to direct WordPress site owners to the proper location.

    • Myatu 6:40 am on May 22, 2012 Permalink | Log in to Reply

      Couple things…

      Is there a way to see how many people have actually marked a plugin as their favorite, and optionally, who?

      Also, I’d really like to see the email subscriptions for support threads back again, the sooner the better.

      As for support itself goes, that needs some work with respect to what the plugin developer wants (better said, can do). I can understand your point about the consistency in user experience across WordPress plugins and an ability to measure plugin quality, but at the same time, what if a plugin developer would like – or already uses – a ticket system, provides phone support, use their own forum or simply use good ‘ol email, then what? There’s currently no method to integrate that with WordPress.org’s plugin listings, nor do they count toward the quality measurements.

      Something to consider perhaps, is improve the way users can vote on a plugin. More often than not, people do not vote. They install, and use it. Don’t like it, uninstall. That’s it. So, if a user uninstalls, why not ask them “Why are you uninstalling this plugin?” – plugin developers and the community could do with that sort of feedback. And voting from within the WordPress plugins page would be another option, though some care has to be taken to avoid someone using a “bot” on that (which is detectable, and could perhaps be reason for removal).

    • Mike Challis 6:14 pm on May 25, 2012 Permalink | Log in to Reply

      As a plugin author, I now have the ability to make a sticky post. Thanks.
      But after 10 minutes(or 20 or whatever) I have no ability to edit any of my posts. A sticky post is not very useful if I will not be able to edit it later if needed. Please give plugin authors the ability to edit their own posts.

    • Ipstenu 8:16 pm on May 25, 2012 Permalink | Log in to Reply

      Forum mod hat 😉

      The support forums have always been there for plugins, whether or not you used them. So this does make them more prominent, but for now if you don’t want to use them (and you certainly dont have to) I would do this:

      1) Put a link to your support location in your readme. No support at all? Just say that too 🙂
      2) Make a sticky ‘This plugin not supported on these forums.’ And inside, a link to where it is.

      No, it’s not perfect, but when the mods come through and clean up snark like ‘Bob’s a bad dev! He doesn’t help me!’ we can say ‘Well, actually, RTFM. Bob said to go to bobplugins.com instead.’

    • zorro1965 4:32 am on December 14, 2012 Permalink | Log in to Reply

      I have been so waiting for this to become a feature. So much easier then trying to keep a place where you have all these plugin details archived.

      Being able to access these in the backend after you have them marked is HUGE…!

      Now I only have a few suggestions for future.

      1. Allow the member to have ability to create their own categories for favorites to help quickly sort through what you need for a kind of site you are working on or group them for other reasons.

      2. Have a different view choices to see excerpt of description, last updated, ratings, # downloads

      Thanks very much,

      Zorro………

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