 Thank you very much. How many of you have written a plugin for WordPress? How many of you have sent that in to be hosted on WordPress.org? For those of you who haven't, doing that is often a mystical and bizarre process. In fact, for those of you who have, it still is. When you submit a plugin, it falls into a black box. You go to a website that has a form that says, please submit your plugin, tell us what you want the title to be, tell us what it's about, give us a link to your zip file. If I could tell you how many people put localhost as that zip file URL, by the way. I've had many times where I've emailed somebody back and I said, you know that I can't see your localhost, right? Oh, I thought it uploaded. No, it's actually literally asking you what the URL is. We're working on changing that, but it's a slow process. But you submit your plugin and you get a little note that says, thanks for submitting the plugin. Here's some information about the queue, which now tells you how many plugins are in the queue, how many have been reviewed, how many need a review. And that's kind of all you get. And you wonder, well, what just happened to my plugin? What happens is that you get a BB press site on the back end, and I'll show you what it looks like in a minute. And somebody has to go read your little description of what your plugin is, download it, and test it. And it sounds pretty simple, but it is a very painstaking and time-consuming and many times incredibly annoying process. And I should know I do it every single day for at least two hours a day, except on Saturdays and Sundays when I try to avoid it. And I'm going to help you understand what's going on on the back end, what people are going through when they review your plugins, in parts that you can understand how to submit your plugins and make them better for everyone, but also so that you can see what really goes on behind the scenes on WordPress.org. I want to take away that mystery. So on the screen right now is a little bit of a shot of a BB press site that we have that shows what the plugin queue looks like. And it's basically a list. And it says the name of the plugin, the person who submitted it, and a link to the plugin that you, the URL that you gave us. And we can click on those little lines that we've got, and it'll expand and give us exactly what you wrote in on that box. So that earlier box, when you said what your plugin's about, if you just pasted in your entire 5K, read me, thanks. I really wanted like a little tweet description that this plugin will automatically post your blog post to media. Okay, cool. But instead what I usually get is like, you know, the whole essay of exactly how it works and your fact and everything. And it makes this page get really, really long when I expand things. I see them in two colors. I see them in the gray and white colors, and that tells me this has not yet been reviewed. And I see it in a yellowy-orange color, and that tells me someone has replied to this. There are actually about five of us who go through and read these plugins and test them and reply to them. You mostly will end up talking to me right now. I'm sorry. I can be a little brusque sometimes, especially as I get to the end of my day and I'm thinking, boy, haven't I had this conversation before? It is run by BBPress. Not only is it run by BBPress, it's run by BBPress One, the standalone application that wasn't quite folded into WordPress that Matt wrote on Christmas Eve. Yes, Matt wrote BBPress on Christmas Eve. I guess he was bored. That's when I would do some of my best coding. We are in the middle of revamping this entire process, but it's probably not going to change what we do next. Because the very first thing that we do when we look at the plugins is we look for what we can reject. And that sounds so harsh, but the first thing we're looking at is what can we reject based on its name? 90% of the plugins that are submitted that have the word plug-in in their name are rejected because it's redundant. People will submit. Mike's cool plug-in. I will reject it and I say, it's really cool that it's a cool plug-in. However, can you please resubmit this in the name like Mike's cool Twitter? And don't worry about the word plug-in, because people are going to know that it's a plug-in just based on the fact that it's on WordPress.org slash plug-in slash Mike's cool Twitter. It's pretty self-evident. Now, that's how we do allow some that have the word plug-in in there, of course. Mike's plug-in organizer. Well, that makes perfect sense. We're going to let that in, which is why this isn't automated. It's why somebody has to go through and say, this use of plug-in was incorrect. This use of plug-in was allowed. One thing you cannot do is submit a plug-in with the word WordPress in it. Because come on. We have a lot of things, and this includes older plug-ins, like Yoast SEO's original name was WordPress SEO. We don't allow that anymore because, well, yeah, it's a WordPress plug-in. Where'd you put it? WordPress.org. Okay. We're pretty sure they know it's a WordPress plug-in. Drupal integration? Well, sure, we'd let that in, but WordPress integration plug-in for Drupal. That made your name pretty long. And the thing you got to remember is that these names are going to be what your URLs are. So if you put in, Mike's really... Poor Mike. I don't know if there's a Mike in here, and if it is, I'm not talking about you. Pretend I'm talking about Mike Schroeder, the current 4.5 release lead. He's my co-worker. Mike's really cool Twitter plug-in for WordPress. Will literally be, Mike's hyphen, really hyphen, cool hyphen. And this is how the URL is built. It's BBPress. It's just like WordPress. You put it in, there are no stop words are removed. You kind of want a shorter URL. As the mail poet guys learned over time, and they had a plug-in, where the name is like WYSIWYGIA, and we used to call it the plug-in. We can never remember what the name is, but it's a good email plug-in. Poor mail poet for years was just stuck with the fact that nobody could remember their plug-in name because it was a weird name. Well, that's the name that they typed in. The next thing I look for when I'm going down that wonderful list of about 35 new plug-ins a day is, what trademark violations have I run into today? I can honestly tell you, five years ago, when I started doing this, that I didn't think I'd ever care about a single trademark ever. I'm just working on an open source. What do I care? Did you know that the phrase for dummies is trademarked? I can't allow a plug-in that says, Twitter for dummies, for two reasons. First off, you're not Twitter, and that's trademarked. And secondly, you're not the for dummies group, so you can't use that. Wiley and Zones. Yes. You can't use Google Analytics, so literally you can no longer name a plug-in Google Analytics integration. It gets a little bit weird when you start thinking about it because, well, wait a second, how do you know all the trademarks out there? And I don't, but common sense actually really helps me a lot here because when I see a plug-in that says X for Y, I'm like, okay, let's see. This is Fiat integration for WordPress. I got a picture of a Fiat steering wheel up here. Fiat integration for WooCommerce. Like, well, okay, are these the WooCommerce guys that are submitting it? No. Okay. Are these the Fiat guys that are submitting it? Can I tell? A lot of times, people are actually hired by companies to make a plug-in, but they submit it using their Gmail address. I see your emails. They submit it using a Gmail address from a GitHub account. I can't tell that they're legitimately hired by Fiat, so I will reject the plug-in and say, hey, if Fiat hired you to make this plug-in, they need to make a Fiat account for a couple of reasons. First of all, then we can prove it's Fiat. But secondly, eventually, your contract with Fiat may go away. They may say, well, you know, thanks very much for helping us with this plug-in. We're going to take over development of our own plug-in. If you submit it with your own user ID, you own it. If they submit it with their own user ID, they own it. And that means that three years down the line, when your happy partnership with Fiat has come to a wonderful end, you shake hands, you part your ways, nobody has to care who owns the plug-in because Fiat does. It's theirs, it's their brand name, it's their trademark. Awesome. So don't submit a plug-in that is someone else's name. You can't submit Twitter. There's a funny story with this, too. Facebook has a plug-in, an official plug-in it's called Facebook. I rejected it because they submitted it with a Gmail address using a Dropbox account for the zip file. I said, yeah, you're not Facebook, go away. And then it happened to be that I was at a word camp with Auto. I don't know if you know Sam Wood. He goes by Auto. He's a wonderful guy and he's kind of the behind-the-scenes master of a lot of plug-in stuff. And he says, so those were actually Facebook that you just rejected. Well, how's that supposed to know that? He used Gmail. And they thought it was pretty funny. And I thought it was funny. And about four years later, Microsoft did the same blessed thing. They used an MSN account. Okay, that's a little better, I guess. They submitted a plug-in and at this time I had learned my lesson though and I looked at it and I'm like, this looks like it's official. Out of curiosity, are you actually Microsoft? Okay, we need to clarify a couple of things about your user account to make sure you're you. The next thing I look for in things that I can automatically reject are people that are behavioral based. Serial spammers, people who consistently and constantly submit stolen plug-ins. I use the word stolen. I believe in forking. Forking is a wonderful thing. But when you take somebody else's plug-in and you erase their name and their copyright information and you deny the fact that they ever built it, you have just stolen something, folks. And people who steal plug-ins are not welcome at the .org repository. If you want to take somebody else's plug-in, credit them. Be a good steward to the WordPress community, to the open source community. People who don't do that will start, first we'll tell you, hey, look, can you put the copyright info back? And actually this is a fork, but can you show that you've actually changed the code a little bit to make it something different? And if they don't, we say, well, I'm sorry, we're not going to host the plug-in that's a direct copy of somebody else's. That's just silly, doesn't help anybody, doesn't help the community, and it doesn't help you. We'll start rejecting you also right away if you don't reply to the other emails that we sent you. And not only that, you start getting Taylor Swift songs in your email box, Backstreet Boys. Whatever happened to think is annoying at that moment in time, I've got some nephews and they like to listen to very interesting music. I've done Rafi lyrics a couple of times. Baby Beluga in the Deep White Sea was really fun to send out to everybody for a week. If we have, I can see every single plug-in you've ever submitted, approved, rejected, closed, opened, suspended, whatever. I get a nice big list of them when I expand and looked at your name. If I see that I've been rejecting the exact same plug-in with the exact same name five or six times, I'm not exaggerating. This is a true number, five or six times the guy sent in the same plug-in, not a single change made. And I just started putting in, Papa, can you hear me? I started doing these things. He's the guy that started the song lyrics because I just, I gave up. I couldn't think of how else to reach out to him. And finally, there's a happy ending. He said, why are you sending me song lyrics? I said, have you been getting the other emails? Yeah, why didn't you reply to them? They say, please reply at the top. Oh, I didn't realize you were serious. The other kind of rejections, and these are kind of rare, are subject matter based. And this is a touchy subject. We currently don't permit plugins that exist only to be frameworks in the repository. There are some that have slipped in and previously were approved before we established this guideline. We don't allow store fronts. We don't allow gray hat SEO plugins, you know, the ones that are going to auto-populate all your data and say, oh yeah, this is going to totally help your SEO by filling in the words that you need to have as your keywords for your website and it's going to make Google love you. No, it makes Google hate you we're not going to allow auto-posting plugins and we don't list these out because they keep changing all the time and we're going through and we're always constantly revising are there auto-posting plugins that we should allow? Maybe, but we always talk about it. Still, these are ones that are generally going to be rejected. Now, one thing I didn't say is we don't reject you based on the subject matter if we think it's offensive. We walk a fine line. There's a plugin that does embeds from porn sites. If you want to embed from RedTube and Pornhub and all that, there's a plugin that does that. Someone's complained about it and I said, don't use it. It's okay. It's not doing anything illegal. It's not doing anything immoral. Whether or not you feel using the plugin as immoral is one thing. The plugin itself is not. Now that said, I actually have rejected an anti-abortion plugin because it was written in a way that was intended to be vitriolic. It was intended to enrage people. And I told them, look, I think the code is good. I think the plugin's a fine idea. If this is what you want to write, I think it's going to cause you more trouble than it's worth on the .org repository and people are going to attack you. Are you sure you want to do this? We have plugins that we won't allow because they made themselves a little too offensive. There's an anti-smoking plugin that I could have approved because I personally have lost family members to lung cancer and I don't like smoking and I encourage everyone if you can to please quit. But this one had very graphic photos of what your lungs look like. And I said, you know, this is a great idea, but I think that it's going to cause you more emotional problems than it's worth to have the plugin here. Those can actually be cleared out pretty quickly. You can tell which ones are going to be problematic, which ones are going to be sensitive subject matter. The last reason that I'm going to reject the plugin is that it's been seven days or more since we first reviewed it. This is just for sanity. We go through all the pending emails that we've got about plugins. We check them. We make sure that you're still working with us. And if it's been seven days since the last time we've talked, you're going to get an automated email that says, hey, it's been seven days we're rejecting your plugin. And one of our wonderful volunteers don't panic, just keep working with them. If this is the first you're hearing about your plugin being pended, please email us back and we'll catch you up with what's going on. But at this time, you don't resubmit until we ask you to. This just keeps everything in order. It makes it easier for us to keep track of who's paying attention, who's not, who needs a lot of hand-holding, and who doesn't. Otherwise, that list for pending plugins gets really, really long. When I started working on plugins, they were ages long. And I said, why are we not cancelling these old ones out? They said, well, we don't really have a policy for that. I said, now we do. Let's make it seven days. If we haven't solved all the problems in a plugin in seven days, it's not going to happen anytime soon. Let's stop and keep talking to them. But take it off the queue so we don't feel the pressure and they don't feel the pressure of let's have to get this done right now. Okay, now that I've cleared up the queue with what I can reject, I get to review a plugin. Well, actually, I get to download a plugin. And if the download fails, I have to check the URL. Sometimes people typo. Like they put an HTTP and forget a colon. It happens. I wonder how it happens. Are you not copy pasting? Okay, fine. Sometimes they'll typo their own domain name. That's always fun. And sometimes I can catch those and go, oh, this is what's wrong. Let me fix it for you. But sometimes I can't. If it's local host. If it's .dev. These are all things that happen on a regular basis. We are currently writing the software in a different way so that if the URL does not validate, it does not go through. We haven't gotten there yet. We see no reason to fix the current system when we know we're entirely replacing it. So sadly, I have to make sure that I can download it. Once I've downloaded the plugin, I have to make sure that the plugin has valid headers, copyright, and license information. I actually wrote down copyright twice on my note because I have to check copyrights a lot. I have to make sure that you have not removed the copyright information of a fork. I have to make sure you haven't removed it from the JavaScript. I have to make sure you haven't removed it from a library. Copyright law is completely separate from license structure. Regardless of what you think about the GPL, and to be perfectly honest, I don't care what anyone thinks of the GPL. What I care is that everything on WordPress.org must be GPL v2 compatible. Or later, which means v3 is totally fine. I have to look for Creative Commons though, because only Creative Commons 0 and Creative Commons 4 are acceptable. That's it. If it's one, two, or three, I have to say I'm sorry this is not compatible. The problem with that is a lot of JavaScript libraries were licenses as Creative Commons 3. I don't know why, because Creative Commons even says, don't do this for your code. This is silly. This is for documentation, but they did it anyway. Creative Commons just a global search for that covers most of my problematic ones. Next, I'm going to review every single JavaScript and CSS file. Every single one in your plugin gets opened and read. You'll notice I haven't said I've installed this plugin yet. I haven't. I've downloaded it. I am reviewing every single line in a JavaScript. I suck at JavaScript, and I'm still going to read every single line. I'm going to make sure that everything looks like it's above board. The wonderful thing about being a human being and not a robot is that I can look for what makes me go, that doesn't look right. That feels wrong. At this point, I've looked at so many JavaScript files that I can go, that isn't right. That's being called weirdly. You're calling WP content directly. You're going to have a problem. I don't have to know JavaScript to know when things are going to cause problems anymore. You can't call WP load directly, for example, because you don't know where it's going to be. Somebody could have WordPress in a folder. Somebody could be running it as a headless WordPress state. There is a multi-tenancy. I don't know if you saw that talk earlier today, which is just a brilliant idea of a way to run WordPress without really having WordPress installed in the same folder. Plugins that call folder names directly don't work when you do that. Multi-site. You're going to have problems. I also have to make sure, did you include jQuery? Because you know that WordPress does, right? It's got jQuery. It's got jQuery. Why? It's got a whole mess of other things. Your plugin has it too. I'll send you a little note and say, hey, did you know that WordPress has jQuery? Please delete yours and use ours. But I actually have a list of the most common problem children for JavaScript licenses for things that I know outright. Like FancyBox 2.0 is not licensed GPL compatible. I'm sorry. FancyBox 1 is. You can use it. Zero clipboard. I happen to know that some of the older versions have security issues, so I've got to check and make sure you're on the newer version of that, too. Then I run a grep. And I've written it up on the slide, and it is literally wp-parentheses.con, pipe, blog, pipe, load. Close parentheses. That is literally what I grep for when I look at a plugin. And it goes through every JavaScript file, every CSS file, every PHP file. And the reason that it does that is if I can find any of those, and you've hard-coded wp-con, now that could be content or config, or you've hard-coded wp-blog header or wp-load, you're probably going to have a problem when WordPress is in a non-expected folder. I should never see any plugin except a backup plugin referencing wp-config.php, period. If you're calling it directly, you're doing something dangerously wrong, because that is direct access to things that you don't need unauthenticated users directly accessing. There is always a way around it, and we will send you a list of documents that you can read that will help you on your way to find a better way to code things. Similarly, I should never see wp-load ever. I shouldn't see wp-blog header. The only exception to that, as I said, are going to be backup plugins, but those are actually calling them in a way that we can tell if I can find wp-config, I'm going to back it up, otherwise I'm not. And we read them contextually. I actually go and check each and every match and make sure that I'm reading it properly. Sometimes this means I have to hop backwards six or seven functions to figure out what you're doing. The next thing I look for is I run a grep or dollar underscore post, get, or request, and I check that you're sanitizing them. This takes forever. And by forever, what I mean is, when you've got a big plugin like, oh, I don't know, buddy press, I settle down with a cup of coffee and I say, well, I'm going to turn off chat, I'm going to turn off Twitter, and I will come back in an hour and talk to people, but I need to concentrate and make sure that every single thing is sanitized. And this involves a lot of walking back through functions. How are they being called? Who's calling them? Are they being called securely? Are you using nonces? Why are you setting things? Unsanitized post calls can be easily corrupted. And one of the biggest problems that we're finding these days is that people are passing data and tricking admins into clicking links that are carefully customized to pass unsanitized data to your system. Congratulations, you've got cross-site scripting vulnerabilities, sir. Nobody wants that. My goal is to keep you off of those lists that say this plugin was insecure. So if I can catch these things in advance and say, hey, you need to sanitize these things, I've saved you some time, and I've also helped your reputation in the WordPress community. Next, I'd have to grep for SQL. I haven't quite figured out how to do that in a faster way than basically looking at every single SQL call and making sure that you're using prepare, that only sanitized data is being passed through that you're checking that it's a string and not text or a string that is text or a digit. I got to go through and look at all of that. And a lot of times I see people that are doing direct database queries and I said, did you know about WP query? Oh, I didn't know that. Now you do. This is also incredibly time-consuming. It's a little bit more rare that people are doing these things with SQL that aren't aware of security already because it's fairly advanced stuff. Finally, I'm going to get to read this whole frickin' plug-in because after I do my greps and I search this for the stuff, I go through and look at it line by line. Okay, I skim some of it. I look for things that jump out at me and say, oh, that's wrong. But I do look at every single file of every single plug-in. And that means that the people that leave me little dirty jokes in the plug-ins, I like you. Some people will leave little notes. I can't believe you're actually reading this. And then I'll go back on Twitter and I'll say, no, I actually read it. I scared a couple of people that way. Like, wait, you really do? But I'm doing this to see are your prefixes unique? 1,000 plug-ins in the repository. Actually, 56,000 plug-ins. You only see about 48 or so on the repository because we've closed a lot. We've rejected a lot. I see all of them. I can see every last one that's ever been looked at. Imagine, you can try to figure out how to do the math yourself of how many possible iterations and combinations there might be of these plug-ins. I don't recommend it. I actually tried to write a mathematical proof to do the math with my dad who's a professional mathematician. He's got a PhD in this stuff and we crashed his computer. It's a large number because we try to add in all the themes, by the way. And then we did the number. We said, well, how many plug-ins are on theme for us and in Envato? And we added all that stuff in and my dad's like, we're going to break the computer. It was a few years ago. I'm sure I could do it now but I don't want to because all I have to know is this. Your prefixes should be unique. They should be unique to you, not just internally to your plug-in. This is why namespaces are a really cool idea, by the way. And yes, you can totally use PHP 5.4, PHP 5.5, PHP 7 only code in your plug-in if that's what you want to do. But remember that not every host is up to date. If you choose to use those versions of PHP, please write your plug-ins so that they fail gracefully for the user, that they get a note that says, hey, I'm sorry, I can't activate this plug-in. You're not using a new enough version of PHP. That is all we ask. I also have to check that are you making external calls to services that are well documented? If you're a Twitter plug-in and you're calling Twitter, I'm not really going to sweat it. I'm pretty sure people know that that's what's going to happen. But if you happen to be, let's say, a plug-in that helps me with recipes and you're making GOIP calls, I'm going to call you on it and say, well, out of curiosity, why are you doing this? Why does someone need to know the physical location of the person visiting my site in order to show them a recipe? Oh, well, I wanted to show them regional recipes. Okay, you need to document that. I'm going to push back and make you document all of your external calls in your readme because the people who download your plug-in have a right to know where it's going, what it's connecting to, and where their data is going. On top of that, you have a legal responsibility to do so in some countries. Your plug-in can be used by anyone in any country, the entire planet, and outer space, and who knows where else. You can't be expected to know the law, but what you can do is a CYA maneuver and just say, and this plug-in calls this resource from this other service. And if somebody says, oh, I can't do business with Microsoft for whatever reason, okay, they won't use the plug-in, but they are educated and they know. Basically, I'm going to look at your plug-in and I'm going to try to find what's wrong. This is my micro machine slide, folks. I'm going to look for file paths instead of functions. I'm going to look for collecting user data, debugging errors if debugging is forced on, calling remote data without disclosing, using demo folders, allowing direct file access to plug-in files, a copy of another plug-in, asking users to edit files or edit themes. Saving files in the plug-in folder, not using WPNQ messing with error reporting. Calling external functions using FancyBox2, uncredited forks, using GeoIP data files that happen to not be GPL compatible, using non-GPL code speaking, that hard-coded plug-in folder names, bad headers, making admin and iframe, or moat loading images, installing another plug-in, using isotope pre-version 2.2, using JavaScript files that WordPress already has, hard-coding your private keys, license checks, no line breaks, trying to hide your code, missing files, leaving in your node modules that aren't necessary, not using non-Sys. Offloading JavaScript or CSS out-of-date libraries that are insecure, using JavaScript, Packercode or other obfuscation techniques, non-unique function defined or class names, not sanitizing your data, submitting the same plug-in twice, did you please not read the emails? PHP sessions, PHP short tags, bad SQL calls tracking users, setting default time zones to too many tags, being trialware, not calling uninstall safely using uploadify, including vendor files that you're not using at all, including an entire other plug-in in your plug-in, reinventing something that WordPress already does, including the zip file in your plug-in, having Tim Thumb, having WordPress in your domain name, or forcing credit links to automatically display. And that is a non-exhaustive list. And yes, I am looking for that. Someone once said, you're basically looking for reasons to reject my plug-in. And I said, yeah, yeah, I am. I'm looking for reasons to tell you that your plug-in is doing something wrong so that you have a chance to fix it before the general populace gets to look at it and come back and say, hey, you're doing things wrong. Because I don't hold it against you. It often comes across sounding like I do. I really don't. I expect people to make mistakes, because I do every single day. I miss things. I make a mistake. I make typo. I've forgotten a semicolon and had SVN reject my own plug-in as I'm updating it because I did that. I'm glad it does those checks, by the way. These are not rejection reasons, by the way. These are all, hey, I can't approve your plug-in until you fix this. If I've actually gotten this far, by the way, now I get to install your plug-in on my test box. I've got a vagrant box. I have local.plugins.dev. I also have local.phemes.dev. I test that. I install the plug-in. Can I activate it? Does it show any error? Does it show any warnings? Does it fail on PHP 5.2? If so, I'm just going to let you know that it failed on 5.2 and that you might want to put in a safety check there. You might be surprised how many plug-ins fail to activate properly. They just don't. And I don't always do this. If I look at a plug-in, and I can see everything that it's doing, and it's all above board, and it looks like code that I reliably trust, this plug-in disables the admin toolbar. Yeah, that's the right code for it. Off you go. If a plug-in is sufficiently complex, though, I am going to want to see it in action. And now I'm going to review and break, excuse me, I mean use the plug-in. When your plug-in is sufficiently complex, the state of your read-me matters a great deal. A great... And if I look at your plug-in, and I can't figure out how it works on the read-me and based on the interface that I'm given, you have done something wrong. I'm a reasonably intelligent person with a large amount of experience with using plug-ins. I doubt there are more people on the planet than the handful of us who do plug-in reviews who have actually used as many plug-ins as we have. If we look at it and go, what on earth are you doing and how does this work? Something's bad. And we are going to tell you, hey, your user experience is a little bit confusing. We can't figure out how to do these things and what we need to do in the read-me. What's going on here? I'm going to walk you through, okay, you need to explain this in your read-me. You should have a screenshot of this and you're going to have to expect the people will push back. And we're doing this not because your plug-in isn't fine. We're doing it because we don't want you to have angry users giving you one-star reviews because your plug-in is confusing. Nobody likes those. And if I can save you that headache by giving you 20 minutes of my time, I can save you hours and weeks. Finally, I get to decide whether or not I'm going to approve or append this plug-in. Remember, I've already gone through my base rejections. Sometimes one will slip all the way down to here and I'll read it and I'll go, wait a second. I know this guy. He's made a second account just to submit this plug-in for a 15th time. And then he gets a mail that says, we know who you are, please stop. But if you've made it this far, you basically have two options. I'm either going to approve your plug-in or I'm going to email you detailing out anything I found in those previous steps. And by detailing, I mean you are kind of getting a form letter that says, hey, please check and make sure you're using nonces and user can checks. Because remember, nonces aren't going to check if the user had permission. Nonces are going to check if it was an authenticated access. If you want only administrators to do something, make sure you're checking if an admin can do something. You get seven days from that email, by the way. That's the seven-day marker. To fix everything we've listed. And this is where people start to panic because they get that seven-day rejection. It tells you, don't resubmit, don't panic. If you're working with somebody, just keep working. You can ignore this email. Keep working with us until we tell you to resubmit. And we are trying to be very upfront about it. I've got people who complain that I've written in all caps in those emails because it does say, do not resubmit. You're plugging at this time. That's like the second paragraph. Because I don't know how else to get it across to someone. Don't panic, but don't resubmit. We are still talking to you. And yes, it's all caps. And that is shouting. And it's the only time I ever want to have to shout is to make sure you listen when you get those emails. But a lot of people just don't read these emails. We get 30 new plugin submissions a day, basically. Five are rejected out of hand because they need to fix the plugin. It's just going to be so long that we don't see this happening in seven days. The idea behind the plugin is something that cannot be resolved. Maybe one or two are rejected because we will never accept them for what their content matter is. 24 plugins, 24 brand new plugins a day are physically, painstakingly, personally reviewed by a human being who wants you to succeed every single day. My name is Nika Epstein. I work for DreamHouse as a WordPress developer and I review your plugins. And if you want to ask me any questions at all about the plugin review process, I am more than happy to answer them. In review, you listed all the different things that you checked. Do you always go through all of those steps or do you just reject the first time you fail one of those things? So the question is, when I review and I have a list of my checks, I reject it or actually append it when I find one. No, I actually go through and try to find as many as I possibly can so that you have the opportunity to fix everything. Otherwise, I go back and forth and back and forth. So I'll put in the 20 minutes, 30 minutes it takes to find everything that's wrong with a plugin, which is why you get the form letters a little bit because I'm literally typing into my computer WPP load and it auto fills why you shouldn't be calling WP load. It speeds my time up and it's automatically got the links that you need. In the back first, and then I'll come back. Question on session. When did session, PHP session become a bad thing? Because I had a plugin submitted. I use session all the time. I can't tell you that I used it, but I can't imagine that I didn't and I don't remember getting an email on it. That would have gotten my attention. Is not using session a new thing or did I maybe use it in such a trivial way that it didn't matter? So the question is about PHP sessions and part of this came up because I mentioned to him yesterday that we don't allow people to use PHP sessions. To be specific, we don't allow you to use PHP sessions in your plugin in a way that isn't encapsulated in the function it needs to be in. You were actually using it properly. It was only called in the function that needed it. What we see is people who do sessions start at the top of their plugin file, which means that every single page load wipes out PHP sessions and that messes up caching plugins. It messes up varnish specifically. And because of that, we don't want you to be hated by web hosts, so we warn you, hey, you should only be using sessions for the functions that need sessions to be used. And this is generally good coding practice, by the way. You should only use in queue for the pages that need to have in queue. If you don't need jQuery loaded on every single page, then just concentrate it where you need it. Yes, using jQuery everywhere speeds up your site. So, in one of my plugins, I was actually... You must have not been the person who reviewed this plugin, because I was checking off the things that I went, oh, I did that. Oh, I did that. Why didn't mine get approved? So, like, what's the next step if you're sitting here feeling guilty and going, okay, I obviously need to change something. Can you just... Can you change your slug? Can you re-release a different plugin and duplicate the old one? So, the question is, if you've already submitted some plugins and some of the things I talked about are things you've done wrong, what do you do? If it's the plugin name, which means the plugin slug, don't worry about it. You are what we call grandfathered in. If it is the prefixes in your plugin, you should fix those. If it's something that you can fix in the existing plugin, just go ahead and fix it. We're human beings. I listed a lot of things. You can imagine that some days I missed those. And I do. I am not a robot. I am not perfect, and I never claimed to be. We have a post up on make.wordpress.org slash plugins, which is our public make blog for all the plugin work, that actually reminds folks, look, it's okay to get annoyed with us that we've missed things, but it's not okay to get annoyed with us because we've missed things. That's just unrealistic. And we do our best, and it's entirely possible that I did review your plugin and I missed things. And it happens. When those things happen, we consider it our fault. So, for example, CMB2 accidentally was approved, and it should have gone through a different process. We accidentally approved it. It wasn't me, but it doesn't matter who it was. We told CMB2, please don't worry about it. Your plugin can stay here unless you want it to go anywhere. If it's our mistake, we'll own it and deal with the consequences, not you. Because we try to be good stewards of the WordPress community. Updates to plugins. Let's say maybe you did things right the first time and you got approved, but then you just go and make an update and you start breaking the rules. Because from what I understand, it doesn't approve the same process. You just target it to push updates. So the question is, how do WordPress updates impact things? Because we do not review your plugin updates. Once your plugin's approved, it's off to the races for you. The way that we catch people who break the rules later on is I get an email for every single plugin check-in. I want you to think about that for just a second. It goes to a dedicated email account that I made that's got a bunch of Gmail filters and it looks for these common problems and it goes into a special folder and every morning I go through and I look, what are the false positives? And freemius, for example, is a really popular plugin that has, and I use the term loosely, an auto-updater which we don't permit, but it's not actually active and it doesn't do anything so we allow it to be in there. It's just there for when you hook other things into it. So it's alright. I have to go through and say, auto-update but it's freemius let me make sure that's the only auto-update that they didn't put in another one on their own. We go through them manually and we look for things and we miss things and what will often happen is that someone in the support forums will come around and say, this plugin has credit links that are turned on and I can't turn them off and then you'll get an email from us that says, hi, we've had a closure plugin in the WordPress.org repository because you violated the guidelines. Here's the link to them again in case you missed it. It happens. We do expect you, by the way, to have actually read the plugin guidelines. They are linked off of very many places. We're working hard to make it even more obvious that this is something you should be reading because they do list things like, please don't put auto-credits in your plugin. It's not permitted. Don't phone home. Don't collect user data. It's got a whole list of stuff and people are like, oh, I didn't know I shouldn't have credit links in my plugin. You left them in on themes. True, but you only have one theme that's active at a time. You could have up to 50 plugins. Imagine what your site looks like. It's like a billboard on the I-90. Good God. So it's catch-us-catch-can, rather. So what happens when you have a plugin that you're selling somewhere else and it happens to have the same slug as a plugin on WordPress.org and the WordPress.org plugin has a newer version number. Today, that plugin would get overwritten. There is a patch in core that we're working on right now that will allow you to put in your plugin to say, and this plugin should not get updated by WordPress.org. However, what do you do until we manage to get that into core? Because we do recognize that this is a big problem, especially as the WordPress ecosystem is growing every single day and people are adding in more and more unique plugins. My recommendation is to give them very unique names. I name my personal plugins, the ones that I write and I don't put up on WordPress.org. They start ipsdnew, hyphen, and then the rest of the name. If I've got a company name, I put that one first. We've got a few DreamHouses that actually are internal use only and in order to make sure that nobody else has capital H, dang it. DreamHouse is capital H, you see, and I wanted to make sure people didn't typo it on our company blog, so I wrote that. If I want to make sure people don't install capital H, dang it. I have DreamHouse underscore capital H, dang it, because WordPress plugins on .org don't have underscores. I can be sure that that's not going to be a problem. There are more code things that you can do. You can actually write in, if an update is coming from WordPress.org for my plugin, don't do it. They get really complicated really quickly, so for now I strongly advocate you use very unique names. And it's a horrible thing to say, because it's not a sustainable solution as we start running out of unique names, but it's what we have right now and I'm hoping that this patch gets into core within the next two versions so that we can start solving the problem for companies, because we do recognize this is a big problem. I think we're about out of time. If we have other questions, I'm sure she'll be happy to take them on the slide, but we have another section coming up. Thank you guys very much.