This is talking about the theme only 🙂 Jump in and leave constructive comments please!
Updates from Ipstenu (Mika Epstein) Toggle Comment Threads | Keyboard Shortcuts
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.
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
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
modlookto the post and walk away. The forum team will delete it. If you think it may not be obvious spam, add the tag
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:
- Someone 5-star spamming their own plugin
- 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
sockpuppetto 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
modlookto 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.
- 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.
- See if you can fix the problem, but give it no more or less priority than you would any other support request.
- 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
modlookand 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
modlookand 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
pluginmodand 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.
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.
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.
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.
tl;dr: if you’re using
*_post_metain 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:
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.
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.
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.
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.
We’re overhauling and upgrading the repo. Interested? You can harass @obenland and team about it:
See you there