WordPress.org

Make WordPress Plugins

Welcome to the official blog for the WordPress Plugin Review team.

If you have a problem with your hosted plugin, or have found an issue with a plugin hosted here, please read our post on reporting plugin issues first.

We do not provide help with using, debugging, or developing plugins. We act as gate-keepers and fresh eyes on newly submitted plugins, as well as reviewing any reported security or guideline violations.

For documentation on creating a plugin, as well as all guidelines and support information, please visit developer.wordpress.org/plugins/

Currently we have neither meetings nor office hours.

We can be reached by email at plugins AT wordpress.org

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Ipstenu (Mika Epstein) 4:24 pm on May 3, 2016 Permalink |
    Tags: ,   

    Handling Bad Reviews 

    In general, the Plugin Review team is not the go-to recourse for bad reviews.  Instead, we have a totally brilliant forum support team! There’s some overlap of jurisdiction of course, and some of us are on both teams, but the point here is you should go to the right group to get the right help.

    I’m also going to put this out there. You will get a bad review. Most of the time, it will not be deleted. So before you get any further in this post, know that the way you chose to respond, in public, to a 1-star review of your plugin is your own choice.

    Our goal with the WordPress.org repository is to have a good place for users to get plugins that fulfill their needs. The reviews are an extension of that, and should viewed as a way for users to educate other users on their experiences. Also a review is about an experience. If someone’s experience with your product is poor, that doesn’t make their review invalid. And to go back to that previous statement, the way you react to those poor experiences is going to impact your reputation, and that of your plugin, a heck of a lot more than that review.

    Now, that said, we have a few ‘common’ types of problems with reviews. This post is going to help you handle them and explain when you should call for help, as well as from whom. Later on we’ll be adding it to our documentation, once it’s refined as best we can make it. Please remember, we do not want to make a ‘rule’ for everything. That just invites people to play rules-lawyers and tip over everyone’s cornflakes.

    Here’s how you do it and when and why.

    First off… How to add a tag!

    99.999999% of the time, you’re going to be adding ‘tags’ to posts. This is so easy, you may kick yourself for missing it. On a post, look on the right hand side, under About this Topic and you’ll see a section for Tags

    Tags are listed on the right hand side of a post

    This is a free-form field where you can add any tag you want. Anyone can add any tag. The forum moderators have an easy way to know who added what, though, so keep in mind we do monitor that. If you want to add a tag to a post and reply, add the tag, press the Add button, and THEN come back to reply. It works better.

    Tag abuse (that is calling moderators needlessly) is not okay. Be smart. Be thoughtful. Remember that every last member of the forum and plugin teams is a volunteer. We’re not being paid by Automattic to do this.

    The spam review

    This is easy. Don’t reply, just add the tag modlook to the post and walk away. The forum team will delete it. If you think it may not be obvious spam, add the tag spam as well.

    The sockpuppet review

    When a person (or group of persons) makes multiple accounts with the sole intention of leaving reviews on their own plugins (or leaving poor reviews on their competitors), this is called being a Sock Puppet.

    This behavior is expressly NOT welcome on the WordPress Forums as it is spamming. But it comes in two flavors:

    1. Someone 5-star spamming their own plugin
    2. Someone 1-star spamming their competition

    Both are bad behavior. Both will get plugins removed from the repository and a stern email from us. If you’re doing this, stop right away. Contact your team and tell them ‘Don’t do this!’ Also keep in mind, asking everyone in your company to 5-star review your own plugins is gauche. I mean, really. You’re stacking the deck on purpose and that’s not beneficial to anyone.

    Again, do not reply! Add the tag modlook AND sockpuppet to the post and walk away.

    The attack/troll review

    These are the worst. When someone attacks you and the review seems like all it exists for is to make you feel terrible, you’re going to have to take a deep breath and walk away. An attack is a troll, regardless of how the original poster (OP) feels, they’ve basically been a troll. They’re writing something they know will make you mad and hurt and angry, and they’re doing it on purpose. That’s a troll. And you shouldn’t feed the trolls. You won’t win, and you’ll just make yourself look bad.

    Again, do not reply! Add the tag modlook to the post and walk away. These are usually pretty self evident after all.

    The review that should have been a support post

    This includes the sub-genre “People who submit 1-star reviews in order to emotionally blackmail you for support.”

    We all get them.

    1. Reply with a link to the support section of your plugin (or directions on how to get support, or even a note that you don’t provide free support) and remind them that next time, they should ask for help before reviewing.
    2. See if you can fix the problem, but give it no more or less priority than you would any other support request.
    3. If you can solve it, ask them to modify their review. If they go back to https://wordpress.org/support/view/plugin-reviews/PLUGINNAME and scroll to the bottom, they can edit their reviews!

    You’ll notice we’re not telling you to tag the post? Right now we can’t move a review into the support forums and vice versa, so there’s really no point. The forum moderators won’t do anything about it except say “Well, that does suck.” If we could move them, we would, but right now we technically don’t have that ability.

    The review about your premium/pro version

    If you upsell your plugin’s pro version in the free one, and someone leaves a bad review because the pro version they bought, on the basis of your free one, is bad, congratulations. The review stays. You opened the door with your upsell, encouraging them to do this, and that experience reflects on your plugin as a whole.

    If you do not upsell, and there’s no direct link between the free and pro version, or the plugin having the issue is a premium only add-on, tag it modlook and someone will come take a look.

    The review about someone else’s plugin

    This one can be fixed! Reply and let them know it’s not your plugin, it’s the other one, and then tag it modlook and then use the tag wrongplugin (all one word) to let the mods know what’s going on.

    But I really need a plugin moderator!

    Okay. So you think you’re an exception? Use the tag pluginmod and a plugin admin will come take a look. Be prepared, though, as we generally will perform a full review on your plugin and any and all guideline violations will result in your plugin being removed until you fix them. Including using too many tags.

     
    • Austin Passy 4:39 pm on May 3, 2016 Permalink | Log in to Reply

      Thanks Mika!

      It’s good to know that these tags exist.

    • Phil Derksen 4:48 pm on May 3, 2016 Permalink | Log in to Reply

      Very helpful Mika. Thanks.

      I also found it helpful to use the #forums channel on wordpress.slack.com. Great place to discuss how to respond to negative reviews.

    • Syed Balkhi 5:06 pm on May 3, 2016 Permalink | Log in to Reply

      Thanks Mika – this would be very helpful.

    • dudo 5:20 pm on May 3, 2016 Permalink | Log in to Reply

      Hi Mika, thank you for sharing this.

      Some people just rate 1 star because there is not a function that they want/need.

      Does the pluginmod tag can be used in a case this?

      • dudo 5:21 pm on May 3, 2016 Permalink | Log in to Reply

        Sorry for typos

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

        No, do not use pluginmod for that. That would be the “People who submit 1-star reviews in order to emotionally blackmail you for support.” folk. We won’t remove them, but you can learn from them by either improving your documentation to be more clear about what features aren’t included, or maybe add them. Either way, that was someone’s experience. They used your plugin, they wanted it to have more to be truly functional for them.

    • Chad Butler 7:13 pm on May 3, 2016 Permalink | Log in to Reply

      Awesome information as usual Mika!

      I am in general agreeance with the policies, and having been around awhile, I know these have been the general policies for quite some time.

      My personal feeling is that the weakest point of the plugin review system is brought on by misuse by a small number of users in the community (most of whom aren’t really even participants in the community). In general, the community is great – and most people post worthwhile reviews.

      But there is a portion of the community that improperly uses the review system, as you’ve already pointed out – trolls, reviews that should be support questions, etc. And then there’s they guy who I place in a separate category – the useless review: 1 star, invalid complaint, never to be heard from again.

      Would it be possible to consider adding review voting to the system at some point in the future? Something similar to Amazon where people who read reviews can answer whether they found the review helpful or not.

      I think this would allow the community to self police this since the majority of the WP community are reasonable people.

      I was tremendously glad to see the addition of requiring an actual review in addition to just the star rating (that seems so long ago…). Would this be a next logical step?

    • Sakin Shrestha 1:37 am on May 4, 2016 Permalink | Log in to Reply

      Thanks Mika for sharing.

    • dartiss 8:31 am on May 4, 2016 Permalink | Log in to Reply

      That. Is. Brilliant. Never knew these existed but glad they do!

      • dartiss 8:36 am on May 4, 2016 Permalink | Log in to Reply

        One quick question – I have a review that I’d like looking at but it’s old enough that it’s closed so I can’t add tags. Is there a way around this?

    • Brad Touesnard 12:03 pm on May 4, 2016 Permalink | Log in to Reply

      Very helpful, thanks!

  • Ipstenu (Mika Epstein) 8:19 pm on April 27, 2016 Permalink |  

    Rewarding Vulnerability Finders 

    We don’t. We’re 100% volunteer driven, so when you tell us a plugin has a vulnerability, you don’t get anything more than a thank you and our undying affection. Yes, even if you’re that person who sent 45 reports one day.

    But. If you’re a bigger than average plugin (say Derpack size) this isn’t a really great way to find out about vulnerabilities. You’d really like it people could report these securely and in a way that would make them inspired to help more. You know. Money.

    Enter HackerOne – a free service.

    Here’s how it works in a nutshell. You make an account and tell people what you’re looking for. For example, the WP API. Their profile explains the scope (WP 3.9 and up) and they list (with links) everything related.

    If someone finds a security hole in the WP-API, they can log into the site and fill in a form explaining what the hack is, how to exploit it, and so on. The developers will review the report and, if they determines it’s valid, pay for the report.

    Some pages list how much the payout is, some don’t.

    You can search right now for ‘wordpress‘ in the directory and there are a handful of WP companies and individuals listed already. Hi, Automattic! Fancy seeing you here.

    If you’re a WordPress plugin or theme company, this could be a great way to get the community in on helping you plug those security holes.

     
    • Jeff Chandler 9:17 pm on April 27, 2016 Permalink | Log in to Reply

      Do you forward those reports to the plugin authors and let them take it from there?

      • Ipstenu (Mika Epstein) 10:02 pm on April 27, 2016 Permalink | Log in to Reply

        Yes, we forward them to the authors and, depending on the nature of the issue, we may close the plugin to prevent new installs. If it’s incredibly difficult to reproduce and requires a bunch of ‘IF you do X while on Y network…’ we may only inform.

    • J.D. Grimes 9:34 pm on April 27, 2016 Permalink | Log in to Reply

      I’ve been using HackerOne for one of my plugins for a while now, and as a developer who often finds security holes in other plugins, it would be much easier if those plugins were also using a platform like HackerOne so that I could report the vulnerabilities easier.

      The HackerOne platform is great, and the only complaint that I’d have is that sometimes you get a lot of low-quality reports (i.e., false positives). But other than that it is a great way to make it easier both for those reporting and those triaging vulnerabilities. Thanks to the plugins team for suggesting it to plugin authors.

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

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

    1624 UTC – Tue 19 April

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

    1541 UTC – Wed 13 April

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

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

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

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

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

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

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

     
  • Ipstenu (Mika Epstein) 11:47 pm on April 6, 2016 Permalink |  

    4.5 Notice – Breaking changes in REST API due to bug 

    tl;dr: if you’re using wp_insert_* or *_post_meta in your REST API callback, you need to ensure you are calling wp_slash() on data you are passing in, regardless of source.

    Full post below:

    REST API: Slashed Data in WordPress 4.4 and 4.5

     
  • Ipstenu (Mika Epstein) 5:09 pm on March 31, 2016 Permalink |  

    [Resolved] Plugin Updates Currently Slow 

    1930 UTC March 31 – The servers are now back in sync, but please be kind. Rewind. Or at least wait more than normal for updates to packages 🙂 Multiple pushes not necessary today.

    Original Post

    Every time someone submits a change to a plugin via SVN, the plugin zips are rebuilt and the change is sync’d across multiple servers.

    At this moment (1700 UTC March 31) it’s running SLOWLY.

    I know normally when your changes don’t show up in 30 minutes, people will push a small change to the readme to ‘trigger’ a rebuild.

    Please do not do that at this time!

    Literally the server is just running a little slowly and is behind by a few hundred commits. It will catch up in time. Please be patient. It’s currently taking around 3-6 hours to catch up to commits. This will clear up, but adding more commits to the queue won’t help 🙂 Basically in this case, please stop pressing the elevator button.

    Perhaps ironically, we did just send out the email to you all asking you to make changes to update your readme to 4.5 compatibility. This is part of the fallout from that. On the plus side, it looks like record numbers of you are actually doing it so yay!

    We’ll update this post with any new information as it happens. Until then, go out for a walk or make dinner or something away from SVN. Thanks.

     
    • daniyalahmedk 5:13 pm on March 31, 2016 Permalink | Log in to Reply

      May be next time send emails in parts 😀

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

        Normally people don’t do it right away! Or at all … We’re actually tracking how many of you do update the compatibility thing.

      • Samuel Sidler 10:36 pm on April 16, 2016 Permalink | Log in to Reply

        The new plugin directory will give plugin authors the ability to update their compatibility information directly in their plugin author dashboard, removing the need to commit to SVN. 🙂

    • Lee Willis 12:43 pm on April 13, 2016 Permalink | Log in to Reply

      Hi Mika;

      I’m having an issue with a plugin that isn’t updating again today (2hrs and no sign of the new release being picked up), are there issues again today (4.5 release related maybe?)

      • Tom Hemsley 5:17 pm on April 13, 2016 Permalink | Log in to Reply

        There are still some issues, I have been in touch with the plugin team via email earlier today… the advice is sit tight (don’t push code to try and force it to update like I was doing…). My changes came through eventually.

  • Ipstenu (Mika Epstein) 2:26 am on March 25, 2016 Permalink |  

    WordPress 4.5 RC 1 

    WordPress 4.5 Release Candidate

    It bears repeating: Please test your plugins with 4.5.

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

    Please do not submit frameworks 

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

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

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

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

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

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

    The parade of likely support issues:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

          Thanks for the clarification!

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

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

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

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

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

      @Ipstenu,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

        It’s a total pain. 🙂

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

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

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

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

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

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

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

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

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

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

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

        thats the preposed method

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

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

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

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

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

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

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

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

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

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

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

            Perfect world? Would not be accepted.

            Reality? Feature plugins are currently an exception for practicality.

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

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

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

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

          what do you think?

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

            I think you actually argued the point for us.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

            Literally it’s the same problems.

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

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

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

      Hello all,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

            Shouldn’t have been approved.

            We should not have approved it.

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

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

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

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

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

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

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

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

        We’re not actually bad people 🙂

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

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

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

      Hey, Mika!

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

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

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

      May I ask, which one is it?

      I feel bad about the whole idea.

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

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

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

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

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

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

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

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

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

          Thank You, Mika!

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

          Thanks for making it clearer 🙂 Appreciate that.

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

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

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

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

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

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

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

        Here’s our situation.

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

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

        Which one’s better?

        Neither.

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

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

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

      It is not a library or anything like that.

  • Ipstenu (Mika Epstein) 1:41 am on February 26, 2016 Permalink |
    Tags: , notice,   

    There’s a Revamp Coming 

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

    Plugin Directory v3

    See you there

     
  • Samuel Sidler 8:33 pm on February 25, 2016 Permalink |
    Tags:   

    Re-thinking “Tags” in the Plugin Directory 

    Howdy all you wonderful plugin authors!

    As you may have read, the meta team is kicking off a rewrite and redesign of the plugin directory. As part of our work, we’re considering every aspect of the plugin directory, thinking through ways we can improve the experience for WordPress users everywhere. If you’re interested in following our work, follow make/meta.

    In considering tags, we looked at a few things that seem to make the experience less-than-ideal for users.

    1. Tags are freeform with a recommended maximum of 12. This leads to plugins “duplicating” tags in the hopes of moving to the top of search results. For example, “anti-spam” and “antispam” exist for Akismet. Freeform tags also mean that misspellings can occur.
    2. Tags are not localizable. If you’ve used the plugin directory in another language, you’ll note that tags are translated into those language. For example, the Japanese plugin directory has English tags. Users who attempt to find “スパム” instead of “spam” will have a hard time finding relevant plugins.
    3. Tags are inconsistent. Finding the best anti-spam plugins using tags requires looking at the “anti-spam,” “anti spam,” “antispam,” “spam,” “comment spam,” etc tags. This makes it considerably harder for users to find what they’re looking for.

    These issues have built over time. They’re not new, but they weren’t inherent issues when the plugin directory was first developed. Looking at a new plugin directory, we’d like to change things up a bit and do the following:

    1. Create a common set of tags. We’ll create this set by crawling all tags in the plugin directory and finding the most popular ones. From there, we’ll search for duplicates (e.g., spam vs anti-spam) and merge them together too.
    2. Allow plugin authors to set a maximum of three (3) tags for their plugins. While this may seem limiting, because we’re working from a common set, there’s very little reason to have a large amount of tags and no need to worry about duplicating tags.
    3. “Match” tags when importing into the new plugin directory. When we’re ready to launch the new plugin directory, we’ll do a final import from the current bbPress database into WordPress. During this import, we’ll do our best to match tags from one to the other. For example, if we have a “Spam Protection” tag, we’ll match “spam” and “anti-spam” and Akismet the “Spam Protection” tag.
    4. Move tags from the readme into the plugin admin. As part of our work, we’re building an admin interface for plugin authors to manage certain aspects of their plugin. We’ll add tags to this interface so you no longer have to commit to SVN to update your plugin’s tags.
    5. Make these tags available for translation. Just as the rest of the plugin directory interface will be translatable, tags will be fully translatable too.

    If tags now sound a lot like categories, well, that’s intentional. 🙂 At the moment, we’re thinking it makes sense to keep calling them tags, keeping consistent with the previous and current iterations of the plugin directory.

    Requesting new tags would happen on meta trac, working closely with the plugin review team.

    To be clear: This is a proposal and we want your input!

    So, what do you think? Leave your feedback here!

     
    • niknetniko 5:05 pm on February 26, 2016 Permalink | Log in to Reply

      While I applaud this very much, I have one remark/use case you might not have thought of.

      Larger plugins typically provide their own hooks and actions for integration. This means there can be other plugins for those larger plugins.

      An example of this is NextGEN (a gallery plugin) that has a bunch of extensions (other plugins designed to work with it).

      Currently, ‘NextGEN’ is used as tag to indicate support/requirement of NextGEN. It has been a long time so I don’t know if they still do it, but they even used to filter plugins with the NextGEN tag and display them inside NextGEN itself.

      Personally I think this isn’t really what tags are meant for, but then I would request another way to indicate support for other plugins. Or even better, requirements for other plugins, but that’s a new feature, so I don’t know if that is possible with the revamp.

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

        That’s an interesting point. Maybe a ‘requirements’ option would work here?

        This plugin requires [other plugin], [other theme]

        The issue there, of course, is it’d have to be free-form, since people make plugins for premium themes and plugins not hosted here. Or we can just say SOL to them.

        • ccprog 7:49 pm on February 26, 2016 Permalink | Log in to Reply

          A reverse ‘supports’/’implements’ might also be needed.

          As in: if SimpleHistory is installed, this plugin can log its specific events there.

      • Jon Brown 5:56 pm on February 26, 2016 Permalink | Log in to Reply

        Excellent point. I’ll add to that that it’s not just addons for plugins, but also plugins for specific themes, for example Genesis.

        In the former case it would be super awesome if there was a official way to declare associations like that and when viewing a plugin they would show as “related”.

        There does need to be some control though lest everyone start tagging their plugin as being an “add-on” for the most popular plugins to try to gain visibility even when they’re unrelated.

      • Josh Pollock 6:44 pm on February 26, 2016 Permalink | Log in to Reply

        This is a really important point. So many plugins have add-on plugins and there is no good way to find them all and to tell what is official and what is not.

        I would love to have a way for all of the official add-ons for my plugin to be easily found. Right now we use a consistent tag, but that is full of problems and users don’t really know to look for that, and anyone can use that tag.

        There are a few related issues here: official add-on; approved third-party add-on; other add-on, plugin that isn’t really an add-on, but integrates with; plugin that is completely dependent on another plugin to work…

      • jrf 10:28 pm on February 26, 2016 Permalink | Log in to Reply

        What you’re talking about is more a form of inter-plugin/theme dependency management for WordPress, which IMHO is a separate topic from tagging.

        Now there happens to be a feature plugin proposal floating around to get Dependency Management for WP addressed 😉

        There is a survey open about this and your input would be *very* welcome: http://goo.gl/forms/Fq1gbY9vCW

        _Full disclosure: I’m the current lead behind this proposal._

      • Brad Touesnard 1:45 pm on March 8, 2016 Permalink | Log in to Reply

        Plugin dependencies are only tangentially related to tags IMO, but since you brought it up, an experiment in the form of a plugin has been made to accomplish dependencies via an additional plugin header:
        https://wordpress.org/plugins/plugin-dependencies/

        This also reminds me of TGM Plugin Activation. I would love to see a dependency system in core rather than a bunch of themes and plugins including the TGM Plugin Activation library and running a bunch of instances of it in parallel.

    • Remkus de Vries 5:05 pm on February 26, 2016 Permalink | Log in to Reply

      Thank you for all the work that obviously went into this proposal … and I think it’s a very solid plan. The only thing I think that needs tweaking is the three tags. Limiting definitely sounds like a good plan, but if you have a plugin with more than one feature than three tags is just a bit too limited IMO.

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

        The problem is where is a line drawn? You could have 100 features. Picking the top three you feel are most important is a good exercise.

        • Remkus de Vries 7:27 pm on February 26, 2016 Permalink | Log in to Reply

          Let’s say I’ve build a plugin for Genesis on top of WooCommerce that has a couple of features. I’ve already lost two tags then … heck even just for Genesis I would only have two tags … Seems thin to me.

        • Mike Schinkel 7:32 pm on February 26, 2016 Permalink | Log in to Reply

          Sounds like Remkus is identifying that we need a “supports” type of tag that would be orthogonal to categorization type of tags?

    • Jeremy Herve 5:12 pm on February 26, 2016 Permalink | Log in to Reply

      I guess my main question is, what are the tags used for right now, and how will they be used in the next version of the plugin repository?

      • If they’re used to improve search, wouldn’t it be better to use content from the whole readme?
      • If they’re used to create categories of plugins, shouldn’t we try to define those categories first? I guess we can start from the most popular tags in use today, but I’m not sure they’ll match categories that would be useful for someone going to Plugins > Add New for the first time. Maybe we could come up with a list of 10 categories, and ask each plugin author to pick up to 3 categories for each one of their plugins?
      • Ipstenu (Mika Epstein) 5:53 pm on February 26, 2016 Permalink | Log in to Reply

        We have to start somewhere though. And starting from ‘what’s popular’ will give us a much better idea of what people are using. If they turn out to be inutile then we can edit them from there. The problem now is we have no idea what the right categories should be.

        Search actually does use the whole readme 🙂 Always has.

    • Jon Brown 6:13 pm on February 26, 2016 Permalink | Log in to Reply

      While we are thinking about this. Would it be useful to define some tags that were informative to users?

      I’m thinking:

      • admin-only/backend-only – ie. a plugin that doesn’t do anything on the front end. Something for example that would add thumbnails images to the post list.
      • dependency-only – ie. something that doesn’t do anything on it’s own. Something for example like CMB2.
      • has-widget – any plugin that includes a widget

      AND by far what I think is the most important:

      • network-compatible – plugins that affirmatively claim to work on multi-site networks.

      Some of these could even be automated for old plugins. Search for “extends WP_Widget”. Search for is_multisite() perhaps?

      and finally the most controversial:

      • requires-php56

      :ducks-and-hides:

      • Marius (Clorith) 8:37 pm on February 26, 2016 Permalink | Log in to Reply

        I actually think these are completely different kinds of categorizations, think “features” vs “information”

        Remember that to many users such informative tags like “has-widget” means little, any plugin could have a widget, but that doesn’t tell me what the plugin does and helps little in that aspect. A ‘requires-php56’ less so as most users don’t know what PHP is, and definitely not what version they have

        For now this is information best suited for the installation instructions screen, and a sane plugin activation hook that checks dependencies before it decides to go belly up on the user 🙂

        I think that down the line, with filterability on the repository, that such tags might hold value, but they should then be a separate set of tags (in my opinion) from the feature describing tags, and not built around the currently proposed changes and limitations.

      • Ipstenu (Mika Epstein) 9:32 pm on February 26, 2016 Permalink | Log in to Reply

        CMB2 in and of itself isn’t allowed in the repository at this time. We don’t allow Frameworks.

        All of those would be nice, optional, classifications, but not tags. Frankly, I can’t see any end user (a normal user) thinking “I need PHP 5.6 plugins only!”

        Multisite, though, yeah, I can see that as a good tag.

        • Remkus de Vries 11:13 am on February 27, 2016 Permalink | Log in to Reply

          Not sure I follow what you’re saying with CMB2 in and of itself isn’t allowed in the repository at this time … because it is in the repo atm.

          • Ipstenu (Mika Epstein) 9:15 pm on February 28, 2016 Permalink | Log in to Reply

            I meant plugins like… CMB2 and Redux Framework are grandfathered in. We don’t let any more in, since a lot of plugins include them inside AS plugins. It’s a mess.

            Also CMB2 shouldn’t have been approved, which is a different mess all together.

            Frameworks are not supposed to be in the repo at this time. Period.

            • Remkus de Vries 12:15 pm on February 29, 2016 Permalink

              Ah, ok. Did not know that. Is there anywhere I can read up on that decision?

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

            This isn’t anything new. 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.

            Since we don’t, we’re trying NOT to add new framework plugins. I’d rather remove them, but we’re in a bad spot right now with it as a whole. We need a composer type requirement setup for plugins in general, which is beyond the discussion of this post.

    • Mike Schinkel 6:41 pm on February 26, 2016 Permalink | Log in to Reply

      Good to hear you are addressing these issues.

      I’ll give my feedback with the backdrop of my experience in the 90’s running a business that sold software components using a printed mailed catalog where every four months I would personally spend about 2 weeks categorizing the products in the catalog.

      First, a static set of tags is problematic because the software world is constantly evolving and there are new categories that will constantly emerge. Googling for web development trends 2014, 2015 and 2016 I came up with “hamburger menu”, “long scroll”, “card layout”, “hero image”, “material design”, “single page app”, “parallax scrolling”, “retina”, “flat ui”, “microinteraction”, etc. All of those may or may not be applicable to plugins but they pretty much all emerged in recently.

      Then there are the “compatible technologies”, i.e. ‘backbone’, ‘reactjs’, ‘flux’, ‘mongodb’, ‘memcached’, ‘redis’, ‘angularjs’, ’emberjs’, etc.

      And then web services they work with: ‘mailchimp’, ‘salesforce’, ‘slack’, ‘twitter’, ‘facebook’, ‘linkedin’, etc.

      And there are certainly other things to note that people have used tags for before that I am not thinking of.

      Next, and this is something that always bedeviled us back in the 90’s when people submitted categories for their own products was the “IS A” versus “CAN BE USED TO BUILD A” question, i.e “Is your component an accounting system, or can it be used to build an accounting system?” We wanted to present the former to customers but all our vendors wanted to include a lot of the latter because the latter were often infinite.

      Further, from experience, some components really only deserved one (1) category and others rightfully deserved many categories. An arbitrary limit to 3 would not be in the best interest of the end-user.

      We found that we could not let people submit their own unedited, that we needed to review them ourselves. Maybe a review board as part of the submission process?

      That said, if you really want to allow people to manage tags on their own I’d suggest considering a few techniques that I came up with for some recent WordPress projects:

      1. If you want to use tags then create two-part tags, i.e. “works-with:mailchimp”, “supports:reactjs”, “implements:card-layout”, “can-create:pinterest-style” and maybe other prefixes you discover. Then apply different rules to the different prefixes.

      2. Or create many different taxonomies of tags as you see in #1 each with their own rules.

      3. And maybe give people the choice of number of tags and then give each tag a different weight. If they pick one (1) tag for the “implements” taxonomy, maybe the weight is “3.” if they pick ten tags, give each tag a weight of “1” and use the weights to drive search results.

      4. Like #3, maybe allow them primary tags, secondary tags and tertiary tags. Give them 1 primary, 3 secondary and 5 tertiary tags where primary gets weight of “3”, secondary a weight of “2” and tertiary a weight of “1.”

      Using some combination of the above I think you might able to to let them self manage tags AND to propose new tags but the constraints of weighting will keep them honest? (Note: You’ll need to fiddle with the actual weights to see what really works; the weights I listed were just examples to explain the concepts. HTH.)

      • Scott Kingsley Clark 6:46 pm on February 26, 2016 Permalink | Log in to Reply

        I like the idea of adding extra taxonomies when this change is made, to support more contextual tagging, and then eventually dropping tagging altogether after a year or so.

      • Mike Schinkel 7:37 pm on February 26, 2016 Permalink | Log in to Reply

        Another thing to consider is that WordPress itself has Categories (often a small number per blog) and tags (typically a large number.)

        Maybe Categories are needed and limited, and Tags are freeform, w/o limit?

        • Ipstenu (Mika Epstein) 10:07 pm on February 26, 2016 Permalink | Log in to Reply

          Sadly I don’t trust your mates to get it right. They would do exactly what they’ve been doing, keyword stuffing and making it so no one can actually find anything useful.

          The issue is that when it’s your blog, you know “Don’t use spam, anti-spam, spammers, spammarific. Just use ONE tag for spam.” Right? Well multiply that by 5000+ users and now you have a mess of people guessing what keywords should be and we’re back to a hot mess.

          Tags are useless as an organizational tool when they’re unmanaged.

      • Ipstenu (Mika Epstein) 9:43 pm on February 26, 2016 Permalink | Log in to Reply

        Remove the list of ‘integration’ tags you listed for a moment. Don’t get mired (yet) in exactly how we’d list those, but presume we’re going to list them separately. Maybe a second taxonomy JUST for ‘this plugin supports’ and ‘this plugin requires’ and so on.

        Pick the top three terms that define your plugin.

        I’ll take Genericon’d and the only tag I now need is ‘font-icons’

        Akismet: ‘anti-spam’ (or ‘spam’ probably)

        The place you start to run into headaches would be Jetpack, which really does a lot of everything. And that’s where tags have always fallen into broken. If we let it remain free-form, we have the same problem we have today. People will use anything and everything to keyword stuff and then start listing their competition. Which is stupid from a marketing standpoint, but they do it.

        If instead we get a better search going based on your readme content, then the need for tags drops considerably and we have the simple question of “Pick three words to describe your plugin”

        It’s a fun exercise to try, actually.

    • Chris Dillon 6:46 pm on February 26, 2016 Permalink | Log in to Reply

      We may be entering XY Problem territory.

      Improve search and tags become irrelevant. Add “network-compatible” and other verifiable, weightable criteria to the readme.

      Has anyone considered polling users on whether they use or trust tags? Do you have any data on keyword vs. tag searching?

      If tags were removed, would anyone miss them?

      • Scott Kingsley Clark 6:53 pm on February 26, 2016 Permalink | Log in to Reply

        More taxonomies for things we can take out of the readme would be super helpful here, including new things we’d like to see too.

      • Mike Schinkel 7:20 pm on February 26, 2016 Permalink | Log in to Reply

        When I have my user hat on I use tags. Tags allow me to find “all the plugins that fit in the category” (yes, I know this can be imperfect) vs. “all the results that happen to have the is the description somewhere.”

        Search is great if I am looking for the first thing that fits my needs. Categorization is better if I want to see all things that I know will have been human-curated so I can compare and contrast. That is why I often add “alternate” to the name of a solution when I google to find all competitive solutions because there are websites with list of alternate solutions that have been SEO optimized for
        ” alternate.” I would hope WP.org would do the same for plugins.

        JMTCW

    • CodeBard 7:32 pm on February 26, 2016 Permalink | Log in to Reply

      3 tag limit is too narrow. There are larger plugins which server numerous purposes and therefore can only be defined by sufficient number of tags. Some plugin authors are us the freeform tags to duplicate their tags is not a reason to bring such a stringent limit to plugin tagging. A technical support plugin may allow tickets, integrate with woocommerce, easy digital downloads, and also allow users to report posts and comments.

      How are you going to express that with 3 tags?

      support, ticket, woocommerce…

      Two major features of the plugin just went out of the window.

      Tags should be a minimum of 5. Preferably 6-8 is much better. If someone cant find a proper tag, no need to use more. But if one needs a tag, s/he should be able to use that.

      Categories are even further limiting. Even in posting in your own blog you regularly have difficulty in fitting a post in some category if the post is broader than a short, snappy piece. Its even more difficult with plugins.

      Tags remedy that problem by offering varied classification. Gimping them is not a good idea.

      • Ipstenu (Mika Epstein) 10:03 pm on February 26, 2016 Permalink | Log in to Reply

        If it was ‘some’ then you’d be right. When it’s ‘most’ it’s gotten to the point that the tags are useless for categorizing. Not only are people using the ‘same’ tags with multiple variations (spam, anti-spam, anti spam, etc), but they’re intentionally adding in mis-spellings. Your plugin included when I look at it. You have ‘crowd funding’ phrased 4 ways, ‘donation’ 3, and you even have the tag ‘plugins’ which I don’t understand why.

        That’s the problem. As an organizational tool, which is what a tag is, you’ve broken the system of classification.

        Have you ever looked up the Dewey Decimal system? It has its flaws, but it has BIG classifications, and then breakdowns. We’re looking big here 🙂

        • CodeBard 7:17 pm on February 27, 2016 Permalink | Log in to Reply

          > You have ‘crowd funding’ phrased 4 ways, ‘donation’ 3, and you even have the tag ‘plugins’ which I don’t understand why

          This kind of practice is not in the same line with misleading intent. This kind of non-misleading misspellings and repetitions are done for a rather simple, human reasons. And rather important. I shall elaborate:

          For starters, standardized terms for a lot of things dont exist:

          Is it ‘crowdfunding’, is it ‘crowd-funding’ or is it ‘crowd funding’.

          Lets say crowdfunding is a rather new term.

          What about support systems?

          Is it “support tickets”, “support ticket system”, “support system”, “helpdesk”, or “help desk”?!

          Among developers we may reach consensus on some. But on the side of users no such consensus is possible.

          Its possible to remedy this to an extent inside wp repository maybe, but wp repository doesn’t work by itself – it is indexed by search engines, and definitely a decent amount of traffic comes from search engines to wp repo, im sure. People who search for plugins outside WP’s plugin admin page are no small number.

          In that respect, tags are most important for relevance in search results. And the number of people who misspell, dont know or outright use different variations of terms when searching in search engines is massive. If you may have noticed, a lot of respectable organizations, websites account for that with their tags, and there exist repetition especially for non-standard terms. like crowd funding.

          And as for even using tags like plugin – WP repo and the user already in WP repo knows that these are plugins. But search engines and users who may come through any other means directly to the plugin page dont.

          These are important for exposure in search results for not only individual plugins, but also WP ecosystem as a whole. You can even come up with a decent percentage of people who use wordpress but do not actually know worpdress plugin repository at all. They search from their plugin admin page, and add plugins, but where do these come from, may have no idea. And when they search in a search engine for something related to a kind of WP plugin which they couldnt immediately find through there, WP repository results should come up at the top – which is not always the case at this point.

          Well scratch ‘there may’ – there are many people like that, as anyone who delivered WP technical support or worked directly with clients would know.

          Then there are many people dont know the correct spelling for many terms
          People misspell a lot of things. This causes uglier situations of course, misspellings are not so orderly and nice, but they are in astounding percentage. And we cant fix that ourselves, as developers or wordpress community.

          In case of number of tags people use without repetition, it is also a natural result of tech: A support system is qualified as a help desk, support desk, support system, support ticket system, support tickets. Anywhere, anything goes. Moreover there are plugins which offer a wide variety of functions which can be refined to specific and singular tags, but needing many tags. Woocommerce supports digital downloads for example. It also supports paypal. Its also ecommerce. Three tags are already used, what about rest of the important features?

          These are important even to me when searching a plugin in repo, as a plugin author.

          ==============================================

          Surely the problems outlined exist and they need to be solved.

          But solution should not take the form of outright limiting the competitiveness of WP repository or pigeonholing plugins and their authors. A viable way must be found.

          For example tags can be aliased. crowd-funding, crowdfunding and crowd funding can be aliased to one single term, inside database or through other means. Alias/repetitive tags can be forfeited if its too much a thorn, but it will hurt visibility for plugins and WP repo itself. There are private repositories which do not have any problem with repetitive tags, for example, and their search standing benefits from that.

          In case of misspelled tags, well, that’s a major thorn indeed. It wouldnt be neat to keep them in the repo database, for sure. Though leaving them out will affect search traffic and visibility of plugins and WP repo in the ‘outer’ internet, i cant reasonably propose a solution for keeping misspelled tags.

          For the number of tags, however, this is the most important. The number of tags being a mere three doesn’t solve any of the either problems, but instead pigeonholes plugins and authors.

          Using three tags for large plugins or plugins which offer a large array of main functions is not rational.

          “Describe woocommerce in three tags” sounds quite like “Describe this movie in one word” games that go about in social networks.

          There ! should be ! more than just 3 tags to classify plugins, even if we arent able to somehow manifest the solutions for the others. Maybe minimum 5, best, up to 10.

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

            It still doesn’t explain the tag ‘plugin’ unless that’s just an accident.

            What if all those similar ways of spelling/phrasing ‘crowdfunding’ redirected everyone to the same tag? What if the search engine, like Google, was smart enough to understand typos and bad spelling?

            • CodeBard 4:23 pm on March 18, 2016 Permalink

              > It still doesn’t explain the tag ‘plugin’ unless that’s just an accident

              Wow i didnt see the reply.

              That one is intended for search engines like Google. tags have some weight in search, and even if wordpress.org’s plugin repo is known for plugins, something tagged with the word ‘plugin’ is likely to get higher ratings for search ranking.

              > “What if all those similar ways of spelling/phrasing ‘crowdfunding’ redirected everyone to the same tag”

              Something like that could work actually. Actually that may be a good idea. People can make all the mistakes they want, and if common spellings, different termage and missipellings are accounted for by the plugin search engine that could fix it.

              This would mean that the repo would account for different terms used for the same thing, but this would give far better control to repo and also could be far neater than totally leaving it to plugin owners.

              It would still be necessary to display such different spellings and terms in the tag listing under the plugin though, since search engines will take those into account. a plugin which has ‘support tickets’ and ‘help desk’ as tags can have higher ranking for ‘help desk’ keyword in google than a plugin which only has ‘support tickets’.

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

            > That one is intended for search engines like Google. tags have some weight in search, and even if wordpress.org’s plugin repo is known for plugins, something tagged with the word ‘plugin’ is likely to get higher ratings for search ranking.

            That’s actually wrong. Having ‘plugin’ in your tags doesn’t improve your SEO like that.

    • Piet Bos 1:36 am on February 27, 2016 Permalink | Log in to Reply

      I think it is a great idea to overhaul the whole system as the whole tagging indeed is a bit of a problem.

      When you say “If tags now sound a lot like categories, well, that’s intentional.”, then wouldn’t it be an idea to simply let go of tags all-together?

      Google let go its meta-tags a long time ago, why can’t we?

      I think the bigger issue with the current Plugins Directory is that the search functionality simply doesn’t really work. And to be honest I think that changing the tags structure is not going to help one bit.

      If you come up with a set of categories and plugin developers can use up to three of of them, period. Yes, that is going to be difficult, but so is everything else. Change is always difficult 🙂

      Then the search functionality needs an overhaul where – as Mika mentioned: “Well written, contextual, readmes” – can replace the current tagging.

      • CodeBard 7:18 pm on February 27, 2016 Permalink | Log in to Reply

        Google let meta keywords go, but it recognizes and counts tags with which any page/article is tagged with into account – and rather decently. tag listing pages of many websites come up in high ranking in results from web pages. Dor example site.com/tags/ecommerce may appear as high as site’s own ecommerce page at site.com/ecommerce

    • Clifford Paulick 11:36 am on February 27, 2016 Permalink | Log in to Reply

      I love the idea of consolidating tags (eg shortcode, shotcodes, has-shortcode), but I think if you implement that, just leave the unlimited/12 tags limit alone for now.

    • Joost de Valk 2:37 pm on February 27, 2016 Permalink | Log in to Reply

      Categories / Tags whatever you want to call them are going to be important mostly from a findability perspective. So if you’re going to use a search engine based internal search engine for plugins, the categories matter because they’ll help determine the rankings too. I think the idea of a limited set of tags is a good one. Whether you should limit a plugin to a strict number of tags… i don’t think that’s a good idea.

    • Anastis Sourgoutsidis 2:38 pm on February 27, 2016 Permalink | Log in to Reply

      Why not take a hybrid approach?
      Obviously I haven’t think this through, but the general idea is:

      1. A plugin may have an (un)limited number of well-known predefined tags.
      2. A plugin may have an (un)limited number of tags that match the slugs of other themes/plugins in the WP repo.
      3. A list of well-known tag aliases maps to the respective predefined tags (that term_group column has been there forever).
      4. A plugin may have up to 3 freeform tags that doesn’t match any of the above (just to cover cases either not considered before, or references external to the WP repo).
      5. Anything else is ignored.

      Then, perhaps once a year, a tally of the freeform tags could form the list of new, soon to be added, predefined tags. This will give an actual view on tag usage versus a trac ticket requesting a new tag added, followed by the +1’s of a vocal minority.

    • Torsten Landsiedel 11:04 pm on February 27, 2016 Permalink | Log in to Reply

      Nearly all great ideas from this comment thread (theme/plugin dependency, has-widget, multisite-ready, etc.) can be achieved if we use a system like on https://theme.wordpress.com/

      There should be a set of pre-defined tags which you can use to define features(themes/plugins) your plugin supports. So we don’t lose tags to give those informations. The remaining three (or maybe five) tags are now just used to describe the plugin.

      But we need to get rid of things like contact-form-7, cf7, contactform7 – this is bad UX and filtering in the plugin repo is not much fun these days …

      And using tags like “yoast” just to be in the list although your plugin has nothing to do with it, is just … (insert your first thought yourself here)

    • Ste_95 7:32 am on February 28, 2016 Permalink | Log in to Reply

      Couple months ago I developed a plugin that suggests tags from a given tag list, basing on the post text. It basically reads through the text and calculates the relevance of each tag, and then provides the most relevant ones.

      This is the plugin https://wordpress.org/support/plugin/smart-tag-insert and this is the algorithm it’s based upon http://www.thecrowned.org/method-for-pattern-relevance-in-text 🙂 There’s a lot of room for improvement in both, but may be helpful here!

    • NateWr 12:39 pm on February 29, 2016 Permalink | Log in to Reply

      Just throwing my hat in the ring in favor of getting rid of tags. More meaningful taxonomies would be useful, but the open-ness of tags doesn’t work well with plugins because they’re so diverse.

      If categories are chosen, they should remain few and only those that can be very clearly defined. Some plugins fit into broadly recognized purposes (eCommerce, forms, events). But a whole bunch don’t. I’d hate to see them get lumped into poorly defined categories just for the sake of throwing them somewhere. I’d rather see 10 clear, well-defined categories alongside one big completely undefined category (“Uncategorized”) rather than a list of 30 or 40 which I think could discourage searching without really satisfying the user’s need for browsing in a lot of cases.

    • Daniel Llewellyn 1:35 pm on February 29, 2016 Permalink | Log in to Reply

      I concur that the current tagging system is unworkable and admit that I have fallen into the same traps that this post highlights as problems. To improve, I’d like to see the plugin repo to have broad category-style taxonomy instead of tags which could potentially include a hierarchical structure to narrow-down intent. This taxonomy should ideally be configured by the UI rather than via changes in the source-code, i.e. the readme.txt file. I’d preferably like to see the entire readme.txt completely removed from svn and replaced with UI to be included into the downloadable .zip file magically when a user downloads a release. Releases should then be generated whenever a new svn tag is created rather than when the readme gets changed. Changelogs could should remain in a file within the sourcecode tree to maintain changes with their associated log message in unison (CHANGELOG is a standard filename used by other projects).

      The category taxonomy should be utilised for a faceted searching feature where the user can search with free-form text AND filter by category. To plug a colleague’s work which hasn’t been publicly updated in some time, but has had changes privately, an example of my ambition is featured at http://www.justiceinspectorates.gov.uk/hmic/?s=test where you can see there is free-form text and faceted filtering.

      The plugin used in the example above was @marcusdowning‘s “Bang Faceted Search” (https://wordpress.org/plugins/bang-faceted-search) further improved from the public release version by Marcus himself – I’ll try to get him to update the public plugin when he can.

    • yairgelb 3:56 pm on February 29, 2016 Permalink | Log in to Reply

      I think it is great to make these tags more consistent but it might be a good idea to have a couple sets of tags. One describing the data/area of wrodpress the plugin works with. Content, admin, performance, users, e-commerce etc. Then the other set describes the plugin itself. So if a user wants a plugin for category banners they will search under content and look for banners or category. This will allow a plugin to use fewer tags while being placed in the right spot on searches.

    • Syed Balkhi 4:14 pm on March 1, 2016 Permalink | Log in to Reply

      From usability point of view, the plugin repo desperately needs an organization / classification system so I applaud this new initiative as it will be helpful for WordPress beginners.

      However limiting the tags to 3 is not the best idea for variety of reasons that have already been brought up before (i.e plugins like WooCommerce or Envira Gallery or Yoast SEO that offers tons of features).

      From the implementation point of view, I think we should seriously consider using both Categories and Tags – keeping it the WordPress way.

      Categories will be pre-defined by the Plugin Review team and each plugin author can only select 3 categories max (depending on how broad or specific the categories are this limit can be adjusted to 1 or 5).

      These categories can then be used to provide proper browsing / filtering options on the .org repo and perhaps even inside the dashboard for users to find what they’re looking for. By doing this we will solve the usability issue that I believe that we’re trying to solve here.

      This brings me to the Tags. We need to have “unlimited” / 20 – 30 tags limit while allowing plugin authors to choose from popular tags that exist.

      By adding these through the new Admin interface, translators can easily translate them. Use of similar tags allow for translation once — not multiple times. A tag that’s not translated won’t be displayed in the other repo encouraging plugin authors to select from popular tags vs making up their own.

      So what’s the real benefit of the existing tags?

      I always think of categories as the table of content (chapters) and tags as (index) of the book. Organizing it this way, will allow for a more sophisticated search “algorithm” because it’s giving you yet another parameter to add into consideration — this should help improve the search.

      The second and most important benefit is from the business point of view of plugin authors. There are tons of plugins that generate a good chunk of sales through WordPress.org repo. The .org tags rank very well for a lot of keywords in search engines like Google, etc –> i.e type “responsive wordpress gallery” in Google — First 5 results are from .org out of which 3 are tag archives.

      While the .org repo doesn’t give plugin authors any traffic insights, by looking from our own traffic analytics for specific keywords — I can only imagine how much of our sales that’s coming from .org is actually resulting from Google rankings of these .org tag archive pages which then lead the customer to our plugin listing.

      This can have significant ramifications on sales of Pro version of free plugins.

      Right now there are 3.45 million tag pages that are indexed in Google. Properly redirecting them (not sure how that’s even possible) would be a challenging task which is why I suggest the solution of using Categories + Tags.

      This would help us improve the usability overall for the Repo. Strict limit on tags (20 – 30) can be easily enforced from the new admin interface preventing abuse but at the same time ensuring no business is hurt with this change.

      • daverod 4:51 pm on March 2, 2016 Permalink | Log in to Reply

        I think Syed’s take on this very much echoes my own. Restricting to 3 tags would have a massive impact on existing plugins that rely on Google to index that particular aspect and possibly make many plugins unfindable because they must fit into the “3 magic tags” rule. Users don’t think in strict taxonomies (and what’s the chance that your thinking will perfectly match theirs?)–they will use synonyms to discover things and that’s how many authors (myself included) use tags now–to improve discoverability.

        I’m not sure that restricting authors to existing tags will be helpful in the long run. What happens when someone creates a plugin for a feature that no one else thought of before and suddenly needs to tag that? What is the process for adding a new tag?

        Plugin categories would be super-helpful to improve search, but it would be nice to see what proposed list you have to see if something is missing and suggest any additions, of course. 🙂

      • Brad Touesnard 2:08 pm on March 8, 2016 Permalink | Log in to Reply

        ^^^ What Syed said.

        I only disagree with the part about unlimited tags and search using them all as weight for the index. If you do that people will stuff unrelated tags into their readme.txt to broaden their search target. If search does look at tags at all, it should be limited to the first X number of tags.

        I’d personally like the tag archive pages removed from Google’s index. That’s as simple as updating robots.txt on .org. As a user searching for plugins I find those results annoying. The contents of the archive pages are in flux, so sometimes when you click through, the matching keywords aren’t even found on the page anymore. Plus it’s often duplicate results. That is, many of the results shown on the archive page are also shown in the Google search results. If we only saw the plugin pages in the Google search results, I think it would be much tidier and easier to consume.

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

          I only disagree with the part about unlimited tags and search using them all as weight for the index. If you do that people will stuff unrelated tags into their readme.txt to broaden their search target.

          Sadly that is exactly what’s happening now, and part of why we have to start kicking things around to figure out what’s better for people who are looking for, you know, PLUGINS 😉

    • Chris Dillon 5:21 pm on March 1, 2016 Permalink | Log in to Reply

      I love this discussion so far. Can I get down to brass tacks for a moment?

      I have a testimonials plugin that is currently displayed at position 26 in a keyword search for “testimonials” despite having more active installations, more reviews and a better rating, after some plugins that haven’t been updated in months, haven’t been tested up to the current version, with infrequently attended if not abandoned support forums.

      If I adhere to whatever the new best practice becomes, will the new system improve my ranking?

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

    Reminder: Many Javascript Libraries Are Included in Core 

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

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

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

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

    Even datepicker folks (jquery-ui-datepicker).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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