 All right, welcome everyone. Hopefully you're in the right place after lunch. Going to be talking, I'm Brian Hogg. I'm going to be talking about submitting, maintaining, and growing a plugin on WP.org or WordPress.org. This is the short form. So feel free to ask questions. It is after lunch. If people were enjoying Montreal, you might have been out late last night. I might forget what I said two slides ago. So it would be much better if you asked the question at the time rather than waiting a few slides and then everyone forgets including me. So ask questions as we go along. So I've got some plugins, which you can see there. I've got some courses teaching some of this stuff, learning center blog thing, and I used to be the organizer of War Camp Hamilton for a couple of years, but I'm living in Cambridge. And one of the plugins is the Events Calendar Shortcode, which is an add-on for the Events Calendar by Modern Tribe, which I updated recently. So I know what I'm doing, hopefully. And the slides will be available at this URL, which I'll show at the end as well. So you don't need to furiously take notes. So just a quick thing of who you guys are. So who here has created a plugin at all? Like even if you haven't released it, even a small one for a client or some code and functions.php, that could have been a plugin. Sweet, awesome. And who here has a plugin already on WordPress.org? A few, cool, perfect, sweet. So I'm not going through actually creating a new plugin. So if you haven't already, hopefully you can just keep some of the stuff in mind when either you're writing a bit of code for a client that you're thinking, oh, maybe someone else could benefit from this and I should release it. You can just keep it in mind as you're building plugins to do in client work and refer back to it later when you wanna release it. So the story of the first plugin I created personally, I did one for a client before and just kind of how the first versions of plugins can be created. So this is a bar in Hamilton called the Winking Judge. These grimy-looking chairs seem to be kind of a bit of a startup mecca in Hamilton for some odd reason. So I was sitting on this grimy chair coding the first version with a pint over here of a plugin where someone was sending newsletters to our local software development mailing list and getting the dates wrong of the events I was running because we were flipping between Wednesday in the evening and Saturday in the afternoon. So sometimes they were putting Wednesday in the afternoon and I'm like, no one's gonna show up. Are you doing this manually? And they're like, yeah. I'm like, oh, there must be a plugin for this. There wasn't. So I coded the first version in that chair and at one point there was another startup that was an app that three people sitting on this little couch coding the first version of their app as people drunkenly shot darts up here above their head, which is like extreme programming to the next level and it was a little scary for them but they made it through and they made their plugin. Yeah, that's where the first version of the plugin I released was made and I waited till I sobered up before I actually released it on WordPress.org. Don't drink and release should be a slogan as well as driving. And yeah, there was some hurdles to think about and things had to kinda push through to actually get it released and working the way it should. So that's what I'll be going through today. So the first thing, it's obviously getting the plugin that you have or the code that you have ready to submit to WordPress.org. So how do we do that? So the main thing that differentiates a plugin that you can just have running on your own WordPress site or a client's WordPress site and something that's released on WordPress.org is the readme.txt file. So what does that look like? And it's literally just a readme.txt file that you drop into the folder of your plugin. And this is a sample of it. You can see it online there at WordPress.org slash plugin slash about slash readme.txt or just search WordPress sample readme. And it's got a few sections which we'll go through. So it's got a short and long description of your plugin which you've remembered back in the other slide is what shows up when someone searches for your plugin or finds your plugin on WordPress.org directly. It's got tags or keywords. It's got any installation notes which a lot of times it's just like go to plugins, add new, type the plugin. But if you have any special installation notes then you can put those there. It'll have a list of frequently asked questions or FAQs which are kind of nice in the new design. You like click it, it drops down. It's like accordion style. So that works really well. So reference to screenshots. So if you have screenshots that you upload which we'll go through later you can add just a description or what the caption will be under each screenshot and what the license is. And for WordPress.org it needs to be GPL. And then the change log. So as you release new versions, again we'll go through these sections. You can make notes as to why people should update to the next version and what changes have been happening as you've been going along. So some tips on the readme.txt to avoid any issues and not get into trouble and try and make as findable as possible. So don't spam the tags. You could think, oh I can put in like a hundred different keywords separated by commas. That'll definitely get you dinged in terms of the ranking and can even get you removed. Kind of looks like you're trying to game the system. So 12 is probably the max really that you should use. And you can look at other plugins as well and kind of check out not only for the tags but for other things there are other readme.txt files maybe you have a similar plugin or something in the same domain. See what tags they're using and you can either copy those ones or modify them slightly to fit your own plugin. So validate your readme.txt file before actually submitting it. So there's this validation tool and it's easy to do over on wordpress.org and you just either enter the URL if you've got the readme.txt hosted somewhere or you just copy and paste it into the box at the bottom and it'll tell you if you have any glaring issues. So there are a lot of rules for wp.org versus just again having the plugin on your own site or a client's site they need to keep in mind. So like I said it needs to be 100% GPL compatible. So if you don't know about the GPL license this is a license that allows the freedoms that WordPress has to be able to copy the code, modify it, redistribute it for free if you'd like and without any restriction on that code. So but this isn't just restricted to the PHP code which because a plugin depends on WordPress automatically is GPL. There's some debates on that but really that's how GPL works. But it also includes the images, CSS, JavaScript files, anything that you include in your plugin. So if you have like a JavaScript library that you're including in your plugin and it has a commercial license or it doesn't have a license that's compatible with GPL and I think MIT is even more liberal so that works as well. But everything needs to be GPL. So you need to keep that in mind where it's not just the PHP code it's everything you include and it needs to be readable as well. You can't like obfuscate it and like compress it and make it so that no one can read it and it's all encrypted. It has to be easily changeable and readable. So include any files for your plugin in your plugin. So don't like link to a CSS file or a JavaScript file on your own site or some other sites like just copy it and add it into the plugin. That way if the site that you're linking to goes down it doesn't take down someone else's site or stops your plugin from working or something like that. So you just wanna copy and include them into your plugin. Yes, go for it. Oh, I forgot already what I said. This one? Yep, yep. Oh, absolutely. Yes, yes. Yeah, I mean like Minified isn't too bad because you could like open it up. There's a little button in like Chrome that'll like prettify it's like a minified version like the variable names will be cut to like E instead of whatever your thing is but at least it's readable. It's more so and I've seen plugins that only have the minified version just for space even though it's not that much difference in space. But yeah, it's nice to include both, right? So that it's easily modifiable if someone wants to but it's more like encrypting it. Like there are things to like encrypt JavaScript or encrypt PHP, can't do that at all but it'll still run because it'll like unencrypt runtime and stuff like that, stuff like that you can't do. But yeah, I mean ideally you should have the minified and unminified but that's still readable at least. Yeah, still in text. We're good. So no tracking without explicit consent. So this is tracking even what site the plugin is installed in. You can't do that. And that could be like you're hosting, you know, you have an image file or a JavaScript file on your site that you're linking to from your plugin. So now you can see where the traffic's coming from for that file and see what sites the plugin's installed in. Again, you can do it but you have to explicitly ask them permission so they say like, hey, like, check this box and click save to give permission or a prompt that you can dismiss that says like yes or no to like and you can give incentive even to do it. And there are a couple of plugins like wisdom plugin or freemius insights that give you this ability to get things like the PHP version and that they're installed, the WordPress version, the site it's on, all that stuff and you just have to ask permission but you can still do it. Yep, go for it. Oh, so I'm not super like gonna GPU. So just to repeat the question for the mic. So you're saying that if like you're including an image and you're tracking it because it's hosted somewhere or something, yep. Right, yeah. Yeah, so that stuff, yeah, you're right. But again, you shouldn't be doing that. I think it'll be actually denied if you're like hosting the files. This is really to like have your plugin send data to like an API or a service or something to say like oh, it's on this site, it's got this version of PHP, stuff like that. So yeah, normally you wouldn't ever have a hosted image as part of the plugin because again, if your site goes down, right, then it can take down or affect other sites as well. So yeah, so that's a good point that you could double track the visitors as well. So again, it's another reason not to include those images in your plugin. Yeah, that's part of it. Good, and on that note, so no credits or links back to your site on the front end, again, without permission. So you can't just say like, you know, here's the plugin powered by whatever on the front end of the site. You can on the back end, no problem, because it's not visible to the user. But you can't say like, you know, powered by whatever your plugin name is on the front end, again, without asking explicit permission, otherwise, yeah, it can be removed. So no nags in your plugins or non-dismissable alerts. So if you have like an admin notice or whatever at the top, it just has to be easily dismissable either with a link, dismiss, or an X to very quickly get rid of it. And you just, and you can't nag over and over again, like have the prompt be something that's useful to the user or just ask them once at an opportune time and that's it. And that's gonna include things like, hey, you've been using the plugin for a while, mind leaving a five-star review? You know, that's totally acceptable. It just has to be dismissable easily and quickly. So nothing illegal, so you can't add bitmining code into your plugin, so I mean, you could try. I know I have, but you can't actually do that. And after all these rules, and you read it to the letter, there is still the clause, which is this, that they reserve the right to disable or remove any plugin at any time for reasons not explicitly covered by the guidelines. But you gotta remember, these people are volunteers, they're not out there on this vendetta to the randomly delete your plugin for no good reason. But they just keep that there so that if there is something that maybe they notice, it isn't in the guidelines, but they feel it should be removed, they have the right to do that. And you are playing in their sandbox, so that can happen, but it's rare, not for any bad reason. So now how do you actually release your plugin? So again, ensure that your remi.txt file is valid and validated before you upload. So you package it into a zip file, so you want your plugin to be in a folder. I know you can have a plugin as just a file.php, but you wanna have it in a folder and just zip it. You remove the git, this is kind of a joke for people who've been coding for a while, a CVS folder, hopefully no one's still using CVS. But remove any source control folders that you have before you make a zip file, and submit the plugin for review, which is the easy part, and then push the code up to SVM. So we're gonna go through this so there's no mystery as to how this is done. So before you do it, another tip is you also wanna test with WP underscore debug turned on. So this is in your WP config. As you're testing your plugin or loading on other sites, you wanna make sure that that is true because you really don't want your plugin to emit any warnings or definitely not any errors that are happening as your plugin is being used and the code for your plugin is being run. You wanna also check if you have JavaScript that there's no browser console errors, you're not doing a console log or some console.error or anything else when you go to release your plugin. And just a big note and a common fear that I hear a lot is that oh man, I don't know if I should release it on WordPress.org because then my plugin could be used with like any other of the 50,000 or however many plugins are there now and it's gonna break and this plugin that's poorly written is gonna mess mine up and they'll blame me and pitchforks and you don't need to test with every plugin out there. Obviously you should test with some common ones like big ones like Yoast and Jetpack and whatever just to make sure you're not breaking sites that have these very popular plugins installed but you don't need to support this poorly written plugin that's still on the repo or some bad theme or whatever unless you want to and you have the time. But just don't let it stop you from releasing your plugin because you haven't tested your plugin with every other plugin because that's just not feasible or possible. So it's now the easy part. Once you've got this zip of your plugin, you can just go to WordPress.org slash plugin slash add and you need to have a WordPress.org account which you can get there if you don't have one already, very quick to register one. And one note on that if you either don't have or already have one or don't, you cannot have an auto reply so like you can never set a vacation message or any kind of like, hey, thanks for email auto reply from that email address. Like if you need to set up another email address that'll never have that because it's a big reason why you'll get removed. Imagine when they send out a notice to all the plugin owners, being like, hey, there's this thing coming up or hey, the server's down for maintenance between this hour and then they get back like 500 auto replies and then that creates tickets in their system and then they have to go through them one by one and make sure they're just auto replies. So when that happens, they tend to remove your plugin sometimes without warning because it's so time consuming for them to do that. So just make sure you don't have any auto replies and never set one for your email. But otherwise, super easy. Now that we've done all the hard work, we just enter your plugin name, enter your plugin description, which can just be copied and pasted right from your readme.txt and then the plugin URL. So you can either upload it to the media library on a WordPress site and put the URL there or put it somewhere else. That's publicly accessible and upload and submit that form. Again, yeah, just use your media library to submit that zip. And one note on the plugin name, it will get translated to a slug, similar to a poster page. You can change your plugin name later but you can't change the slug. So just be mindful of that and make sure you're happy with the initial name that you submit and what slug it'll be turned into because you can't change that after the fact. So once you've submitted it, now you wait. Again, they're volunteers so there's no like, it'll be done in two weeks or anything. They're usually pretty quick but just remember they're volunteers and there's no set time as to when your plugin will be approved. But once you are approved, yay. You get a SVN repository which will look like this. So just be plugins.svnrepress.org slash and then your plugin name. And just by running this SVN command, you're able to download that initial repository onto your computer where you can then upload the actual plugin files for it. So they don't actually upload your plugin automatically. They just run it, approve it, make sure it doesn't break all the things or have anything obviously wrong with it in terms of security. And then they just give you access to this repository for you to actually publish it later. So when you download this repository, you'll have this trunk, you have a couple of the folders but the main one is this trunk folder. And within it, you just copy your files. Your plugin file and it includes whatever you need to. You just do SVN add trunk or you could use a SVN client but I tend to use just the command line for the stuff and I've got a blog post on the exact commands plus these slides. And then you use the SVN CI dash M and then whatever message saying, hey, this is the first version of my plugin and away you go. So now after a couple of minutes hopefully unless they're behind it could be a bit longer. You just go to WordPress.org slash plugin slash your slug and it's there. There should be like confetti that comes out of your computer or something when it's released but unfortunately not quite yet. Technology is coming I hope. So now that you've got the initial version released you can add screenshots, icon, header images. I'm sure you've seen this when you're searching for plugins that just make it a lot more visually appealing and more likely that someone would trust it enough to install it on their own site. And the way you do that is there's an assets folder. Can't remember if it's there initially or if you have to create it but there's the assets. You just put these files in the assets folder. Screenshots are named screenshot dash and then one, two, three, four. I can't remember the maximum or if there even is one but you probably don't want to add more than nine or 10. No one will see it just like sliders. No one sees past the first slide. And you can either name it PNG or you could do it JPEG depending on which. I think there's a couple of formats too. And then in your read me you would add the screenshot section and then for the first screenshot you just have a one dot and then whatever description and then two dots, second screenshot and so on for the amount of screenshots that you have. And then very similar process as being add your assets and then do a commit saying you're adding your screenshots and that's it. So now those will again get processed and then show up. And if you search like WordPress or image formats it'll give you all the like sizes and stuff like that as to what ideally they should be to display as well as they can. So now obviously hopefully you're not gonna just have a plugin and then release it and never do another update. So how do we actually release a brand new version? So first thing obviously you wanna make changes to your code and then put it into the trunk folder. You wanna update the version number both in your read me dot txc and in the header for your plugin so they should always match. Yeah it's unfortunate there isn't like a nice way to like have both synced up cause yeah I can't count the number of times I've updated one and forgotten the other. Add a line to your changelog just so people when they say you know what's the details they can actually see what's changed in your plugin. And then again SVN add your files and then SVNCI a message for a new version just a brief description. So you can do this and that will release actually a new version if you just update trunk and nothing else but to make it easier on yourself and also other people if they wanna some for some reason download a previous version of your plugin you can tag it and the way you tag it is just you go back up once you're in trunk you go back up one folder you copy your trunk folder into the tags with the new version number so 1.1 and then you commit that and so you basically just copying trunk into the tags folder with the version number of your plugin and then you commit that and that will then tag your version of your plugin in the repository. And so you end up visually with this you've got your trunk with your plugin stuff and then you just get tags 1.1 you release another version 1.2 and so on so that'll just keep building as you maintain your plugin for however long you wanna maintain your plugin. Make sure to increase the version number for every release so every time you do this process and actually release a new version make sure you don't keep the same version number reason being people who have already downloaded your plugin won't see an update, right? So you just wanna make sure you update even if it's like a minor version so 1.1.1 or they can go up to four just keep increasing the version number so that it looks like a new version. There is a process I don't have time to go through it right now with so who uses Git for a version? Yeah, so that's obviously the preference I think nowadays instead of SVN I definitely don't except for this use SVN so there is a way you can do it where trunk is essentially Git repository. So you just have your clone your Git repository into trunk so you have your Git folder you don't commit that using SVN you can add it to the ignore but I've got the whole process there on the blog on how to set that up and then you just go into trunk and you get pull and it'll get your newer files and then you can just use SVN to update your plugin but one big note is not to use this SVN repository as like your development repository so as you're building your plugin and testing it and making changes but they're not ready for release don't use the SVN repository to update those changes until you're ready to release them reason being every time you do a push it'll actually not only make a zip file of the current version it'll make a zip file of every previous version and just adds a lot more load to their servers so if they see you doing this they'll either tell you to stop or send you a nasty message or something but yep, so just only use SVN when you're ready to release a new version so some tips even though not going through how to create a plugin at least some quick tips on the plugin code itself which you don't necessarily need to think about when you're just doing it for a client site but will happen when you're doing it for the world so don't include like I said before well actually no, sorry, there's a separate from including the CSS and JavaScript in your own plugin you also don't want to enqueue it or have it available everywhere on a site that has your plugin installed I've got this free course that you can watch to just go through like ways that you can oh I only want my CSS to show up on the Sidman page or on pages with that I want to on the front end for example, because otherwise it just really increases the chance that your plugin, CSS or JavaScript is going to conflict with some other plugin, right? So yeah, just try to add your JavaScript and CSS only where you need it for your plugin. Don't include your own version of jQuery I think a lot less people are doing this now which is exciting, but there is a very easy way to rip out the WordPress jQuery, unenqueue it and then add your own because I need this new version number don't do that, the chance that your plugin will conflict and break other people's code is very high so just use the version of jQuery that's included with WordPress and you can do checks on the WordPress version if you need to know what version of jQuery is included in that version. I do include PHP WordPress check so if you're using new PHP 5.6 syntax because WordPress still has the minimum requirement of 5.2 definitely include like a little, there's a little snippet there there's a couple other ones as well if you just search like PHP requirements or PHP version check or WordPress version check and just check to see like oh is the minimum version 5.4 and WordPress I don't know 4.1, yes cool do nothing all good, if not deactivate my plugin and show a little message saying hey you don't have the minimum version please upgrade or something that way your plugin when it's activated doesn't break the site because of a syntax issue so there are a surprisingly large amount of people who are using old versions of WordPress and PHP out there so good to do a quick check. Do use apply filters and do actions where it makes sense I've got a whole talk on WordPress.tv on how to make a plugin your own and the way that other people can extend and modify your code without hacking your code is by using these apply filters and do actions so they can affect how your plugin works without having to hack the code itself. So definitely include that where it makes sense so that other people can extend your plugin and it just makes it a lot more usable for people to use. Do make your plugin translatable with functions like double underscore. I've got another talk on how to make a plugin translatable and different kind of nuances with that but the more after and it's not like you have to translate the plugin like you don't have to do the strings in another language at all it's just the ability for it to be translated because there's a nice little UI for WordPress.org plugins where someone can just go in and translate the plugin without any input from you and then it gets approved and people can use your plugin in their own language so super awesome. Do add a plugin help page so for example with the events calendar short code I added, you know, because WordPress I added it to the sub menu of the events calendar itself with a little link short code then they have this beautifully designed page why are people laughing, I don't understand. Yeah, definitely not the prettiest design but it works and it's got the basic short codes, the options linked to a short walkthrough video and stuff like that so this dramatically decreases support for your plugin by having the help available within WordPress itself. So that's great. So do test, test, test obviously but again, you know, don't stop the fact that you can't test absolutely everything from ever releasing a plugin or a plugin update. Classic example not too long ago like Jetpack was a 4.0 broke like tons of sites like white screened and then 4.0.1 came out that still broke most sites and then 4.0.2 came out and it fixed it. So I mean, this is a plugin with million plus installs that can do this, you know, so it's, I'm not saying break everyone's site because you can but just be available when you release a new version. You know, don't, you know, push, yeah. Don't do something like pushing a release, forgetting to include a required file then going to a concert with bad cell phone resumption. I've totally never done this. Breaking Benjamin is a great band by the way. It was terrible. I had to use like my wife's like Android phone to somehow SSH and then someone had to help me add that file. So yeah, don't do that. So definitely a test, add it to a version, stick around for a while after you push a release and just be helpful. If someone reports an error, just do the best you can, fix it and people will forgive you. So now the last thing that maybe a lot of people with or the few people with the plugins already, so how to get more users for your plugin? Sadly, I don't have any magic formulas. Word of mouth social is definitely a big piece. Yeah, especially the one, the first plugin I released, most of it has been word of mouth, no paid advertising or anything else, but yeah. I mean, it's great that you can literally tell someone, say at this conference, to say, hey, you can go to your site, go to plugins, add new, type the name of my plugin and you can install it with one click, right? That makes it a lot easier for someone to be able to test and try your plugin and see if they can use it. YouTube how to videos has been super helpful for a couple of mine. Just quick, like, hey, I'm gonna just show you how to use it and quickly go through how to add it in case I'm not familiar with the ad process. Again, very easy, plugins add new, type the name, install, and then just show them just the basic functionality and you're just trying to be helpful and that definitely helps people to take the mystery out of how to get your plugin working the way they need. Frequent updates can help and by frequent, I mean every six months, like it's not super frequent. There is an article that Freemius put out on SEO kind of for the plugin repository, it's public, like the way that the rankings of plugins happen. So you can check that out. There are some and they do put notes in there, it's like, hey, this is part of the algorithm, like I think you can create a WordPress username that's like a keyword and that will actually make it rank better but that'll also get you banned. So just because it'll help your ranking doesn't mean you should do it and they do make notes on that. So yeah, read the fine print or the notes on there where they say, hey, this is helps but don't do it because it's not allowed. But it is definitely hard. I mean if a plugin like write Meow, which will take all the instances of Now with Meow, only has fewer than 10 installs, it's a really hard way to get a lot of plugins or a lot of people using your plugins out there but and older plugins are favored a lot more than newer ones, unfortunately. Again, that's how the algorithm works. So yeah, it's hard to get new users but it's definitely worth it, it takes time but again, nothing beats being able to tell someone that you can go to plugins ad new, type name of your plugin and add it. So again, I've got the plugins, courses, the WorkCamp Hamilton has already finished this year but maybe next year and again the slides are here. So happy to answer any questions. Yes. So question is, any recommendations for the support requests that come in and how to handle them? Yeah, it's definitely the most common fear that I hear on either releasing a free or premium plugin but and I'm very surprised that the front end like shortcode plugin that I've got like doesn't have as many or more support requests than it does and I think just adding the documentation like as a question comes in like kind of think about okay, why do they have that question? Like, you know, and is there some way I can either change the plugin itself or add some documentation to like walk them through and then over time that kind of helps where yeah, over time you'll improve the plugin, improve the documentation and get less of those questions and it's also very rare that like day one you're gonna have, you know, 100,000 people using your plugin, right? So it is kind of a slow build. So I have yet to see like a plugin that, you know, you haven't that it isn't an insurmountable amount of support and it's just me who's doing support and I have been for years and even with like almost 30,000 installs it still isn't inundating. So definitely having a system like unfortunately you can't link in like the free support forum like you have to go to it and subscribe to it versus like a premium, you can use some like help scout. But yeah, just staying on top of it like just being helpful, you don't have to like I always recommend as well if you're working full time or whatever like you just, it's okay to especially for a free version to just on Friday afternoons that's when I do support, you know you do not need to answer like that second or something like it's great if you can but you don't need to. So time blocking as well can help just to keep it manageable personally so it's not always distracting you from other stuff. So yeah, hopefully that helps. No problem. Any other questions? Yeah. Yep. So the question, yeah, the credits on the front end. Yep. Yeah, they conclude the power bank. Yep, correct. Yep. Yeah. No, that's not allowed. So the question is like, oh, I've got these plugins that maybe you're questionable in there. You know, they have a freemium model and they have a backlink to their site powered by on the front end, et cetera. No, if you find a plugin that does that and I've done it, you just send an email. I think it was the plugins at WordPress.org. Send an email with the link to the plugin and say, hey, this plugin is not asking my permission and has a link and they'll send an email to the author and if they don't reply they'll get removed. So no, you're not, it's not your fault. It's the plugin author's fault. Sure. No. So the checkbox has to be disabled by default. Again, they can have links to their site and whatnot in the back end of the site without asking permission, because that's fine. That's not publicly shown. But anything on the front end needs to have explicit permission. So yep, yeah, not your fault. Well, there should be nothing hidden about it. It should be very obvious to find. Any other questions? Yeah, every time. Okay, so the question is like when you first submit your plugin, it's reviewed, validated for security and a bunch of other things. But when you make updates, is it validated? And I think you're what, you're trying to sneak in Bitcoin or something? No, okay. No, it's not. So I mean, they obviously can, like if someone reports it like an issue like that or whatever, they can go back and check it out. But no, when you release an update, it's available, it can be available within the minute. Two minutes after you push it. So, no, I think they do spot checks and whatnot to make sure, but there's no full validation and waiting a couple days to release a new version after that initial one. So yep, it's very quick, which is scary when you have like a lot of people using a plugin. You're like, oh man, I hope I don't screw this up. Any other questions? Great, so I'll be around all weekend. And if you have any questions, feel free to come up. Thanks guys, enjoy the rest of the comments.