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

  • Samuel Sidler 9:57 pm on May 20, 2016 Permalink
    Tags: , taxonomy   

    More on Taxonomies in the New Plugin Directory 

    Hello again everyone! I posted a proposal for taxonomies in the new plugin directory on the make/meta site. Please leave your questions and comments over there.

    Taxonomies in the Plugin Directory

     
  • Ipstenu (Mika Epstein) 11:55 pm on May 19, 2016 Permalink  

    Please check out the proposed plugin directory redesign 

    Plugin Directory Prototypes

    This is talking about the theme only 🙂 Jump in and leave constructive comments please!

     
    • Varun Sridharan 1:20 am on May 20, 2016 Permalink

      Hi,
      I really like this.. the plugin homepage with a featured slider and also the plugin listing.. 🙂

      any changes on single plugin page too ?
      and i hope you will add sliders for the plugin listing like Beta Plugins in homepage 🙂

  • Ipstenu (Mika Epstein) 10:14 pm on May 12, 2016 Permalink |
    Tags: ,   

    Policy Reminder: Tracking Users 

    Do not, under any circumstances, track usage of your plugin without explicit consent.

    If you want to ask your users if you can track them, by all means ask. But you may not require it, and you shouldn’t make it look like they have to in order to use your plugin. That’s being dishonest.

    This has been a guideline for a very long time, it’s not negotiable. Assume people do not want to be tracked and have it to be an opt-in feature.

    If your plugin uses Google Analytics, emails you on plugin activation, triggers some complex check on your servers when a plugin is updated, or tracks usage in any other way when a user has not clearly said “Yes, I allow you to track me,” your plugin will be removed from the repository and you will have to correct this in order to get it back.

    This extends to ads provided by a third party service. If your plugin includes advertising from a third party service, then it has to default to completely disabled. This is to prevent tracking information from being collected from the user without their consent. Again, this is all about people opting into being tracked.

    (For those thinking about using Adsense, don’t. Re-read their Adsense Display Guidelines and note that they do not want you to put ads on non-content pages … which is what the whole WP Dashboard is.)

    Don’t assume that just because someone said they agreed to have usage tracked by you that they’re okay with usage tracked by someone else. Don’t be shady or vague. Tell people upfront “This is who will get the following data…”

    Remember, user trust is paramount to your plugin’s success. If people find out you’re sneaky tracking them, you will lose that trust in a heartbeat and there’s nothing anyone can do to help you restore it.

     
    • buzztone 10:49 pm on May 12, 2016 Permalink | Log in to Reply

      RE: “you shouldn’t make it look like they have to in order to use your plugin”

      I’ve recently noticed some plugins in the repository that do this. What’s the best way to report of this?

      • Ipstenu (Mika Epstein) 1:18 am on May 13, 2016 Permalink | Log in to Reply

        First be a good person and point it out to them directly 🙂 “Hey, I like your plugin, but you’re making it look like people have to do X… Did you know that was against the rules?”

        Sometimes people simply don’t know. They should, but I can’t make people RTFM 🙂 Link them back here and give them a chance to be good people. If they don’t, then report it to us as a guideline violation (plugins AT wordpress.org) and we’ll be a little firmer.

    • David Anderson 10:07 am on May 13, 2016 Permalink | Log in to Reply

      Hi Mika,

      Thanks for the continual drip-feed of articles reminding plugin authors of best practices. Can I make a suggestion for a future one? One problem that eats up enormous amounts of man hours (for both site owners and plugin developers) is plugin conflicts. Lots could easily be avoided by simply enqueueing your scripts/stylesheets only on relevant pages.

      e.g. In wp-admin, first check it’s your page before your enqueue. That way, all issues of incompatible scripts/CSS would just disappear for a lot of cases.
      Similarly for loading PHP SDKs – only register your auto-loader, or whatever, for an SDK when it’s time to use it, instead of globally every time WP loads (which is also bad for performance).

      If more plugin authors were aware of some of these best practices, and spent a few minutes implementing them, it’d save huge amounts of time for people finding problems on their sites, investigating, forum-posting, etc.

      David

  • 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?

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

        It’s a possibility, but it’s low on the to-do list. It would have to come well after the plugin revamp (in progress) and the forum rebuild (getting started).

        Limited resources.

    • 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!

    • Maruti Mohanty 6:55 am on May 5, 2016 Permalink | Log in to Reply

      Superb. Thanks a ton

    • David Anderson 12:19 pm on May 6, 2016 Permalink | Log in to Reply

      One modest improvement I’d love to see to the review system, is that only reviews from the last 2 years (or some other value) affect a plugin’s rating.

      As it is currently, for mature plugins, there’ll be plenty of reviews which – whether for better or worse – are reviews of a plugin that doesn’t really exist any more. Currently, both good and bad reviews (fair or unfair) are part of a plugin’s rating forever.

      • Max Foundry 3:02 pm on May 6, 2016 Permalink | Log in to Reply

        I agree with this David.

      • Ipstenu (Mika Epstein) 11:13 pm on May 9, 2016 Permalink | Log in to Reply

        The reviews reflect the growth and development of the plugin in both code and attitude. For now, they bear weight as a historical basis.

        Maybe one day we’ll have ‘reviews for this version’ like Apple does. That would be more fair than just age, since not all plugins change that much 🙂

        • David Anderson 10:09 am on May 13, 2016 Permalink | Log in to Reply

          Hi Mika,

          I wasn’t suggesting removing old reviews – I agree that there’s value in seeing the growth/development. The suggestion was that they stop affecting the star rating after a reasonable amount of time. This allows the star rating to better reflect the current plugin, rather than being dragged towards a historical average which doesn’t affect what users can actually download and use.

          David

    • screamingdev 8:13 pm on May 7, 2016 Permalink | Log in to Reply

      Wow Mika Epstein. This phrase really catched me: “and any and all guideline violations will result in your plugin being removed”. Maybe we can get in touch because I am serving codebook.cc which does and will do a lot of checks for your guidelines on many plugins 😉 Please ping me via reply or Twitter @ScreamingDev. Cheers!

  • 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.

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