 So, for those of you who were in track A this morning, you might have seen a session on publishing a theme on WordPress.org, and some tips related to that, and so this is like a great sister talk to that talk, because you've kind of learnt what they're looking for in themes. Now Mark's going to tell us what WordPress.org looked for in plugins and how you can get your plugins on WordPress.org amongst the 30 plus thousand plugins that are up there already. So I'll hand it over to Mark. He'll take it away. Thanks very much. Yes, so I'm Mark. I'm going to talk to you obviously about publishing a plugin on WordPress.org and how you might go about doing that. So things we're going to look through today. We're going to look at why you may want to take that decision to push your plugin to the repository. What are the reasons for doing that? We're going to look at how you might prepare your plugins or some of the specific things that are important to do with your plugin that will make it work on WordPress.org. We're going to look at the actual submission process. So how do you actually submit your plugin? What happens when you do that? And hopefully how does it end up getting onto the repository? And we're going to touch briefly on what happens then. So what about aftercare, your plugins in the repository? Is there anything that you need to do to sort of look after it? So those are the things. So I've got some plugins in the repository. This is the screenshot, if you like, from my profile of the plugins that I've got in there. Not massive plugins, not massive amounts of downloads. So I know he's an expert here, but I've got a few on there. So I have been through the process a few times. Probably the most popular one is a user switching one, which is actually an add-on for another plugin. And that's got quite a few users. This is quite an old screenshot, actually. But there's a few ones that do different sort of functionality for different things in WordPress. And usually they come about where I've been asked to build something and therefore I've built it and then might want to use it on other site. I might want to push it back to the community to let them use it. So I'm going to make some assumptions in this talk. So it's not a technical talk, really. There's a few bits of code in it, but there's not really a technical talk. So I'm going to assume that you know what a plugin is and basically how to build a plugin. And maybe you've already got a plugin that you've built and you're thinking about pushing it onto the repository. So I'm not going to talk you through how to make one. I'm not going to talk about how plugins are constructed or anything like that. It's going to assume that you obviously know that. So hopefully that will be the case for you. So why on Earth would you want to put your plugin in the WordPress repository with the, I think it's 40,000 actually that there is now at the moment, along with all those other ones so that the world can have a look and see what you've done? And that's a really good question, actually. And something that I actually tweeted out and I asked the community what they thought anyone who was a plugin developer. And I got some responses which I thought I'd share with you. So this one's make it available to a larger audience. So it's easy to find and to gain some reputation from Mike Ross, who spoke earlier today, said he's got some limited experience of doing it. But to share it and give back to the community to experience the process of how it's done, I guess it means like to understand how other people would go through that process and again to gain some reputation. Ian said to share, help, and get a little bit of marketing for property itself. And John, who's one of the core developers, just said it's for distribution. So that's a great way of getting your plugin out to lots of people so that they can obviously use it and see your plugin in multiple ways. So I had a few reasons as to why I wanted to sort of put some plugins in there. And this was a really big one for me. So developer development is what I've sort of called it. And what I mean by that is that when you build something for someone else, you're always conscious or you're doing it like the right way. And it actually makes you a better developer thinking about other people are going to use this thing, not just for me. So I need to be thinking about what other people might want to do with it. And in terms of the code that you write, you're obviously consciously in the back of your mind trying to make it the best possible you can. So it kind of makes you a better developer because of those sorts of reasons. And then the other reason which is nice and handy is if you've got it in the repository, obviously you can get the automatic updates feature. So you don't have to sort of do FTPs if you've got your own personal plugin and you make some changes to that plugin, it'll come up in the admin and say, when you've pushed a revision, it'll say this has been updated, and then you can just click and it'll update. So there's a number of reasons as to why you might want to add them. Those are just some. I often get told this. So it's like, wow, Mark, you're brave. You're putting your code out there into the repository for everyone else to criticize and look at. And I suppose the right, in a way, you've got to be a brave person. You're going to get people that are going to say, oh, you've done this wrong, and this is not the right way to do it. But actually, I think that's a positive thing because the more people look at your code, the more feedback you'll get about it. And even if they tell you that it's wrong, at least you now know, and you didn't know before. So it can be a good thing, even though it can be a bit, like I said, you've got to be a bit brave and you've got to force yourself to sort of go for it. So something to think about. So let's think about sort of like the process of getting our plugin in there and what we have to go through. So the first thing that you're really going to have to decide on is, where are you going to actually develop this plugin? Where are you going to build it? Now, you could obviously just keep it on your machine until it's ready. But I think a really good idea is to obviously use one of these sort of social code insights. So we've got Bitbucket, we've got GitHub. I've put WordPress on there because obviously WordPress is kind of like that, but I'll come to that later on. So if you're not sure, Bitbucket and GitHub are like cloud-hosted version control systems so that you can develop your plugin. You can get other people to give feedback for it and you can do lots of things like that. And so choosing one of these to use for where you want to develop your plugin, I think is a good example. There are other ones that do these sorts of things as well. These are perhaps the most popular. And as your plugin is going to be open source because it's hopefully going to get into the WordPress.org repository, the development of it can also be out there in the wild. There's no need to make it private at all because obviously it's going to be public anyway. So there's no real need to hide it. And both of these services offer free hosting for public repositories. So I use GitHub to do all my plugin work on. And it means that other people can comment and report issues and things. And then they can collaborate if they want to help me make the plugins better. And then obviously WordPress comes in. We need to use the WordPress repository to actually push our plugin to that and get it into the system. But I'll talk about that later. So some things you need to be thinking about when you write in plugins. And I guess these are just good comments for plugin authors anyway, whether you're going to put them into the WordPress repository at all. The prop's just good advice anyway. But WordPress does have some coding standards that it's a good idea to follow. And I've given you the URL where it's on the make.wordpress.org site, which is in the handbook. And there's some really good coding standards that it talks you through. And they talk you through CSS, HTML, JavaScript, and obviously PHP. And it goes through a lot of things. Some of it's like how to indent your code and where you should put your spaces and your commas and so forth. And obviously all that's so that we can sort of standardize things. So someone else picks up your code. They can easily read it. They can easily understand it, et cetera. I'm sure we've all picked up some code from someone. And we've looked at it and we think we just cannot understand what this is doing. It's perhaps not commented very well. It's all in one line. It's just hard to read. And these standards will really help you sort of make your code a bit more readable, a bit more easy to understand so people can sort of work out what's actually happening and how it's working. So do go and look at that. It's a really good resource. I was also picked up a link a few days ago now from the team at TenUp, who are sort of a big WordPress agency. And they have open sourced all of their sort of development practices and rules. I'll probably tweet out the link later. I haven't put it on the slides, unfortunately. And that's a really good read as well. And it goes through what you should and shouldn't do with what we're using PHP and CSS and all those things. So again, some other good advice for when you're developing, not just for plugins at all actually, but good solid advice for most sort of development. So yeah, get your code and standards right. Get that right from the start and you'll make people happy when they're using your plugin. So the next thing that I think is important when you're building a plugin, particularly if you release for the public, other people are going to use it, is to try and make it as extensible as possible. Now what I mean by extensibility is that it's great if someone can modify your plugin without modifying your plugin. So what that means is they can make some changes without changing the actual files of your plugin. And core does this all the time and it uses actions and filters, the hooks that we can hook into to make those changes. And that's essentially how plugins work and modify what core does. So if you can think about where users might want to make some changes and provide them with the tools to do so using these two functions mainly, there are other things you can do, then it's gonna make for happy users. So for example, things that you might want to do, so if you've got your plugin that outputs some display on the front end maybe, maybe it's a short code or something that outputs something, you could provide some actions that go up the starting at the end so that other users can put things before the outputs and after the outputs. You can also filter the outputs so that they can change perhaps the markup that you've used in your plugin so that they can put their own in as well. And you can also filter things like arrays of data. So if you've got a query taking place, you can pass that through a filter so that other developers can alter those query variables. By default, you might show 10 posts on a page. They might want to show 20 and they can easily filter that and make that change and that's gonna be good for you. I've also spoken about how to do extensibility and there's a link there to a video on WordPress.tv which was in WordCamp Manchester, I think, which was obviously a couple of years ago. So if you're interested in extensibility and how to make plugins, themes and other things extensible then do go and take a look at it. But essentially those are the two functions that you're probably gonna need to include in your plugin to make an easy change and make other people allow you to do changes. So, code it right with your coding standards. Try and make it as extensible as possible. And then, this is also important. So, obviously your code's being viewed by lots of people. It's gonna be used hopefully by lots of people if they download and install your plugin. So we need to make sure that things are nice and safe and secure. So we need to be sanitizing and validating our data. So that means data is untrusted, just don't trust anything. So when someone is entering into a form, let's assume that they're entering malicious data. So we've got to clean that data up first and then we've got to make sure it's in the right format before we're obviously either saving it or outputting it. So WordPress provides lots of functions for you to do this really easily. Here's some on the screen. So for example, there's a number of functions, the WB cases functions, and they basically allow you to sort of clear up a string of text and it strips out things like HTML and things like that so that it's nice and safe. We've also got a lot of functions that begin with escape underscore ESC underscore. Escape HTML does, like it says in the tin, if you pass it a string, it'll strip out all of the HTML and change all the markup so it's safe. Escape URL, so if you're echoing out a URL and you're plugging somewhere, make sure you run it through escape URL and it'll make sure it's a safe URL so it's not gonna cause any issues and similarly, escape attribute. So if you're putting in a style or something or a class on something, you wanna run it through escape attribute. And then there's also some series of functions that you can use for inserting things into the database rather than just using the raw MySQL stuff, you can use this class and it'll make sure it's all safe before it's saved into the database. So sanitizing and validating data, crucial anyway, but if other people are gonna use your stuff, they're not gonna be very happy if there's a bit of a vulnerability for something simple. So a quick example of that, and this is really a simple example, let's say we have a form on our website and it's got this input, so it's text input and we're asking the user for a title. So they're gonna type in a title into the input box and then they're gonna post that form, for example. So when they've posted that form, we're going to want to obviously do something with that data. And this is how you would sanitize that properly. So we're gonna save the title that they've entered into this variable called title and you can see that the posted data comes in over here, that's here, and we've run it through this function called sanitize text field. So that's gonna strip out any dodgy things that they might have entered into that field that might cause problems with your site. And then perhaps, we might not, but in this instance, we perhaps want to update some post meta on a post using that title. So we can now do that with the update post meta function and obviously we're using the title over here, but we know it's been safe, so it's been run through this function. Otherwise, there could be a bit of a problem. So that's a really simple example. And then obviously on the front end, so when we actually use that field, we want to do something like this. So we're gonna get the post meta, in this case our title. So this is the key of the meta here, my title. We're gonna get it for the current post that we're in. I'm gonna save it a story in our variable title. And then when we echo it out onto the screen, we're gonna run it through this function escape HTML just to make sure that it's got nothing dodging it and it's not gonna cause any issues. So that's just a really simple example of how you would sanitize and validate perhaps our form input. But there's lots of ways you should be doing that. I like it all over. So next thing is, and I would urge you to be doing this anyway. So when you're developing things in a development environment, have this defined in your WP config file. It's just one line and it's a constant called WP debug. And it essentially turns on debugging in WordPress. And it means that it'll cause like all PHP errors, warnings, things to be printed to the screen. There's also a really good plugin you can use called the debug bar, which will sort of like catch all those errors and put them in the admin bar at the top, which is quite nice. It does a lot of other things as well, but that's quite nice. And obviously it also does things like it informs you if you're using a function that is no longer used in WordPress, it's deprecated. It will tell you that and say like, don't use this. And it sometimes even says use this one instead. So although that won't like kill your site obviously, but it's best practice to obviously be using the most up-to-date functions. So it does quite a lot of handy little things. I wouldn't have it turned on obviously in production because obviously it's gonna throw those warnings all over the place. But certainly when you're on your local machine and you're building your plugin, it's really good to have it switched on so you can develop with that on. So that's WP debug. So we've used coding standards, we've sanitized our data, we've kind of built our plugin now. It's all safe and everything. So we're kind of getting ready to get it prepared for going into WordPress.org. So we need to get some assets together for our plugin. So WordPress lets you save a lot of assets with your plugin to make the experience of viewing a plugin on WordPress.org and finding a plugin a bit better. So let's have a look at what these assets actually are going to be. So I'm using this plugin called WP Broadbean, which is one that I built. And this is the screen whereby if you're on WordPress.org and you've searched for a plugin or if you're in your WordPress admin and you've searched to add a plugin to your site, then you get sort of this result. So you can see that we get this asset here, which is the icon. So we get a nice little icon. If you don't have one of these, it just shows you a fully gray box, which is like a mosaic pattern on it. So it's nice to have an icon. It makes your plugins stand out a little bit better as well. So the name of that is up at the top there and it should go in the assets folder which I'll touch on in a second. So it's just called icon-128 times 128. And I think you can have a 256 by 256 for like Retina as well, I think. But I have to check that. So that's the icon, which is nice. There's also the plugin banner. So when you're on the plugins page in WordPress.org, you get the plugin name and then you get the details and above there's a nice banner area where you can put a nice picture. So here I've included this sort of picture and then again the name is banner dash and then it has a size. So that's the actual size that the banner should be as well, so 772 by 250. And either of these can be a PNG or a JPEG that you can choose which one that you wanna use. And finally, screenshots. Now I don't know about you, but when I'm finding a plugin, that's kind of like the first tab I click on. I wanna see this plugin, what does it do? What are the settings? What does it output on the front end? So you can have screenshots. So you can include as many screenshots as you want and you can see the names of them again at the top. So screenshot dash one, screenshot dash two, screenshot dash three, you can have as many as you want and you put those in the assets folder as well. So it's just really to show your users what the plugin actually does, a visual display. And I think that's perhaps the most important because that's what people kind of wanna see or certainly for me anyway, that's the first thing I tend to go and look at when I'm viewing a new plugin. So those are your plugin's assets. So get together some nice little assets, make your plugin stand out so that people are gonna find it and perhaps trust it a bit more. So every plugin in WordPress.org needs to have a file in the roots folder called readme.txt. And this forms the presence of your plugin on the WordPress.org site. So the data that you put in here is going to be turned into the data you see on the screen when you view the plugin on WordPress.org. So at the top of this page, you need this section. So the contributors, that's a list, a comma separated list of the WordPress.org's usernames who have contributed to the plugin. So here we've got my WordPress.org username and a high-rise digital company. You can have a donate link if you want to put a donate link in. So that will show on the right hand side of the screen in WordPress.org so that people can donate if they want to. You can give it some tags. So that's gonna be help users find your plugin in when they're searching so they can search by tags. The requires at least is basically saying that you need to be running this version of WordPress at least for this plugin to work. So obviously this is set to 3.1. So if you're running 3.1, it should work. And obviously that's for you to test and decide. Tested up to is just to indicate to users, well, you know, I've tested this up to WordPress 4.4 and it works. So kind of if you're running between 3.1 and 4.4, you should be fine with this plugin. Although if you're running 3.1, I think the first thing you should do is perhaps go on update. The stable tag is like the latest stable version of your plugin. So when users click download on WordPress.org page, that's the tag that they're actually gonna download. That's the version of the plugin that they're gonna get. So that's the current sort of stable version. And then you need the license information at the bottom, which is obviously the GPL license. The two links at the top are the first one allows you to go and download and get a sample readme.txt file. And it is all set out for you with the right headings in the right places. And obviously all you need to do is go and change the different sections and the different pieces of this so to make it all work. And then the bottom one is once you've built your readme.txt, you can actually go and validate it to check that you've done it correctly. So you just paste it into a form on that page and then press validate and then WordPress will tell you whether it's right or not. If it's not right, then obviously you need to fix it because it's not gonna display on the repository. Now the rest of that readme file basically builds out all of the plugin page from here on downwards. So it builds out the description, the installation, the FAQ, the change log, et cetera. So all these headings basically come from headings in your readme.txt file. So you have to put those headings in and then obviously anything you write in there will be displayed under that tab. So description's fairly obvious, that's where you're just telling people what your plugin is, what about it. Installation is obviously how to install it, usually the same for most plugins. There might be some specific instructions once they've obviously activated it that you want to tell them. FAQs is obviously good. I use FAQs, so if I get a common question on the support forums, stick it in the FAQs and hopefully that might help people. Change log, really important, particularly for security releases, because a lot of people, before updating a plugin, they might click the button to say what's happened, what's changed, and then if it says like this is a security release you need to update, then put it in your change log, that's really important. And other thing with change log, please put the latest change at the top because you don't want to scroll right to the bottom of the page to see what's new. And then stats, support, reviews, and developers, that's all done for you, the WordPress site handles that for you, that's not part of your readme. So, we've got everything ready, we've done the readme, we now need to submit it to the WordPress.org repository, so how do we do that? Well, relatively simple, we go to this form, which is at that URL, so WordPress.org.plugin.ad, and what we're asked to do is to put the plugin name in the top. Now, the name will be sort of sanitized, so if you had a plugin called MySpacePlugin, then it would be sanitized to My-Plugin, obviously unless that's already taken. And then it would probably, I don't know what that is, would it get a number on the end, I don't know. So, make sure that you, if you want your plugin not to have a dash in, then you don't put space in here and so on, so that's the name of the plugin in there. And then the plugin description, you need to tell the person or tell WordPress what does this plugin do, and that's quite important, because the first check that is done is does your plugin actually do what you said it was going to do? So, when you submit this, it gets reviewed by someone, which I'll come to in a second. And then you need to tell them where the plugin is, so where is the zip file that they can download this plugin to check it? So, I usually just put the GitHub zip URL of where it is, and then you can go and grab it from GitHub, which is where I develop it. But please do make sure that that is a publicly accessible URL, because sometimes people put in local hosting there, and it's like, it won't work, or a private repository, and it won't work, so please make sure that's a public URL. And then once that basically gets submitted, there's a team of, I think, about 10 people, and one of those, or more of those, will actually review every line of code in your plugin. So, if yours is a big plugin, it might take quite a while for them to actually look at it and check whether it's okay. If it's a small plugin, then it's going to take them a lot quicker. And they're going to go through and look for, if you've done everything right, is the read me file right? Are there any security problems with the plugin? Is it written correctly, et cetera, et cetera? And there's lots of plugins to do. There's a really good talk on WordPress.gov TV, and I can't remember who it was, but they were saying how the plugin team does this job, so it's a really good watch if you're into that sort of wanting to do a plugin. So, once that's happened, probably two or three days later, or maybe a bit longer if it's a bigger plugin, you're going to get an email. You're going to get either this email on the left, or with a bit of luck, you're not going to get this email on the right. So, the one on the left is the success. It says, yes, excellent. Your plugin has been accepted. Here you go. And it gives you the link for the plugin's repository. That's its folder on WordPress.org, if you like, and then some other information which you'll come to in a second. The one on the right, this was actually my plugin. So, I was being a naughty boy, I wasn't doing something right, and I got told about it. So, all I was doing here, I was not sanitising what my post calls, which was essentially what the exam course showed you. I wasn't doing that. So, it come back and says, no, you can't have this in. Here's what's wrong, go and fix it, and then come back to us. If you get an email like that, don't ignore it, because if you ignore it, you'll just get, you won't get accepted, basically. So, you must reply to it within seven days, or else you'll not get your plugin accepted. So, I just replied and said, yeah, sorry about that, I'll fix those. And I did, resubmitted it, and it was fine. Fingers crossed. So, next thing is, you need to use SVN, which is what the WordPress repository runs on. It doesn't run git, it runs on SVN. So, you need to actually add your plugin to WordPress using SVN. I know nothing about SVN, but I can put a plugin up just by following some instructions in the command line. And I'm gonna talk to you about what they are now. So, here we go. In that email, that success email, you'll be given a link to where your plugin is. So, you can see here plugins.svn.wordpress.org, and then it'll have your plugin name on the end. So, in your terminal, what you need to do is, you need to grab a copy of that repository, that folder, if you like, to put it on your machine. And what you're gonna do is run this command. So, SVN, C-O means check out. So, you're gonna check out that folder. It's an empty folder, essentially, with a few folders inside it, and it's gonna put it on your machine. And when you do that, it'll drop these into wherever you, whichever folder you've copied that into. So, you get an asset. That's where your images, screenshots, icons, banners go. Branches. So, if you've got multiple development branches, you can use branches to do that. I'm not gonna go into version control, but you could use those. Tags. So, every time you release a version of your plugin, all you do is put the tag in there in a folder. So, you create 1.0.6, in my example. And then, when someone presses download, it'll go there for the stable tag to download the file. And then, trunk is like your working copy. So, if your working copy of your plugin would go in the trunk folder. So, what you do is you put your plugin into these folders. And then, what you need to do is, you need to actually add it to SVN. It's a bit different than Git. So, you run this command. So, it's like SVN add trunk. And the star basically is add everything in the trunk folder. Obviously, if you've put stuff in the assets and the tags and the branches, you need to do the same thing. And then, once you've done that, you can obviously commit it. And that pushes it back up to WordPress.org and then, hallelujah, your plugin is there, running on WordPress.org. So, SVNCI is to commit, don't know what the dash M does, and commit message here, basically where you can write a message about what's happened in that commit or what's changed or whatever. So, that's how to sort of push it up on there. When you do run these SQL, SVN commands, you will be asked for username and password, which will obviously be your WordPress.org username and password. And you only kind of have to run that one to link and then it doesn't ask you again for it. Because that's to authenticate you with the repository on that they've created for you. So, final few things then. So, once you've got your plugin on there, just a bit about support. So, you create a support forum automatically. So, your plugin will have its own support forum. And there's one really top tip I've got for you here. There's a tiny little button at the top here. And it says, subscribe to emails for this plugin. If you don't do that, then every time someone submits a support request, you won't get an email. And I didn't do this. And I looked at the forum like three weeks later and there's like one, two, three, four people telling me about the plugin. It's like, I didn't even know they were there. So, for all your plugins, because I assumed that as the author you would get an email, that was wrong. So, click that button and it will subscribe you to get email alerts when someone submits a topic or whatever on the forums for some help or something. So, that's top advice there to do that. So, let's just sum up then. So, making sure that you're following the rules. So, your plugin, if it's going on WordPress.org you must be compatible with the GPL license, just like WordPress. That has to be the case. Obviously, don't do anything illegal or offensive, goes without saying. You have to use SVN to get your plugin. There's no other way of getting it on WordPress.org. So, you have to get over that hurdle of doing those commands. That's it. Your plugin is not allowed to embed external links into the site. So, for example, putting a link in the footer or something, say, you know, this site is powered by such a thing. You can do that, but you must ask permission from the user. So, you can't do it by default. So, in your settings screen, you could have a box that says, you know, credit me for this plugin and then they could tick it and then it will show on the front of the site. That's fine. But by default, it must not show any external links on the front end. And these things, as I said, these work what they're checking for in your plugin when it's been reviewed. If you don't supply a license, obviously it will be assumed that it is GPL. And there is a large list of guidelines about what you should and shouldn't do with plugin. Most of them involves just being a nice person and not a spammer, basically. So, you know, make sure that it's not doing anything that shouldn't be, and you'll be fine. Yep, so I'm Mark Wilkinson. I'm a WordPress developer, co-founder of a new agency called High Rise Digital. And thanks, many questions. Great, thanks, Mark. They review your plugin when you submit it, but you've got SVN access at that point. So, do they review subsequent releases and fixes? Yes and no. I think they have some, and I'm not sure on this, I'm kind of guessing, but I partly know. So, I think they have some automated things that check for things when you commit. Well, actually, I know they do, so some things they will automatically not allow you to push up because you get scanned before it does. And I think from what I know is someone gets an email every time someone commits a thing, and obviously they're just gonna check that email. But I think that you're probably writing that it's perhaps less scrutinized than it is at the start. Maybe that's something that they need to press up on a bit. And can you include links to external systems? Not sure. You mean like pulling in from another site, pulling data in? Yes, you can, I think, if it's essential for that plugin to work, obviously. But I don't think you can sort of like pull in your Twitter feeds to show like your tweets in the settings page. But as long as you're sort of transparent and it's part of the service. If it's crucial to the functionality of the plugin, then obviously, yeah. Brilliant, thank you. I would be interested in what's your workflow with GitHub and SVN. How do you deploy from your Git repo to SVN? Manually at the moment, yeah. So basically what I do is I use Gitflow in Git. So I'd have a developed branch and then do feature branches, merge those back in when I want to do release. And then I use like an app called Tower, which basically allows me to just do release and then everything happens on GitHub. And I'd love something to be able to say, whatever I do on there, just do it on the WordPress, but it doesn't. So I end up just doing it manually. So I'll just download the release from GitHub and then basically copy those files into the trunk folder, into the tag folder, and then commit them basically. So I've nothing automated, unfortunately, on that aspect. But I'd love something to be, but I'd love to just be able to put like the URL of the GitHub repository in somewhere on WordPress.org and it automatically syncs it all together, but maybe that's something they can do for the future. I have a question. In the theme repository talk that Dimitri did this morning, he was talking about there were some kind of useful tools that you could use. Tom. Is this on? Yeah. To automatically check your code for some of the same things that the theme reviewers are then looking at for. And one of the examples was there's like an export of example content that you can load into your theme that tries every variation of the WordPress content. So I wondered are there similar tools that you were using on your plugins that helped you kind of preempt some of the problems that you might get rejected for? No, essentially. I've not come across any. I know there is a plugin called Theme Checker, isn't there? Which I think runs through some things on that. I guess with the plugin it's perhaps harder because people don't know what you're building. Whereas a theme is a theme, it's going to do the theme things. But no, not something I've come across and that would be really good actually, just to check a scanner almost. Maybe there is, perhaps I've searched, but yeah, because I'm sure that the review team have some automated tools that they use probably to help them do that. But yeah, good to find. Yeah, maybe as a follow-up to that question, we had two lightning talks about the WordPress coding standards. And I think especially for plugin developers, that's a very good way to like checking things like you forgot to use a sanitization functions or things like that or an escape function. They check those things and many more things. So when you have no errors anymore with the WordPress coding standards, it would be perfectly fine to commit. Yeah, yeah, good. Regarding the standards thing, there is a GitHub repository of the WordPress coding standards that you can run through Code Sniffer, which will highlight all things. And if you use PHPStorm, that will underscore everything and you can set the standards in that overly formatted. All right, cool. The other thing, dash M is message. Message, thank you. So when you submit it, it's the message. Like I said, I just sort of copy and paste them and change bits that I need to. Mark, thanks. Cheers, Mark, thanks very much. I was just wondering if you had any kind of approaches to testing that you'd kind of refined through your plugins? I've no automated testing or anything like that. So, I mean, obviously like 4.5 is imminent. It's going to come out next week, is it, or something? So what I will do is check my plugins on that. So I'll pull that down the beta or the release candidate and I will check that they run. I mean, I'm not gonna lie. I'm not gonna do like massive checks. I'm gonna check nothing breaks, no errors come out. It kind of does what it's supposed to do. But that's kind of as far as I go, yeah. I suppose if you're running a bigger plugin, then yeah, you want to be doing that sort of thing. But I suppose I'm partly right, I'm gonna use this to say, it's broken. But yeah, perhaps I should do. How do you prepare for support? So I mean, following on from testing, do you have to do a certain minimum amount? Do you ever feel swamped by it? Is there a way of managing it? It's a bit of a sort of open-ended question. If something breaks, you've got to support it. But it strikes me something that could be quite terrifying if something did break and you suddenly got hundreds of queries. Yeah, it can be, and it can be difficult. I think you've got to be transparent with your support. So are you gonna support it? Yes, and if you're not gonna support it, then just say so on the support forum. You know, I'm not gonna, I'll fix bugs maybe, but I'm not gonna help, you know, how do I do this and how do I do that? I mean, I just try and help everyone I can. But like you say, you can get quite a lot of requests sometimes. Some things that I've done to sort of speed up that, and I mentioned in the talk is like, if you get a common question being asked all the time, instead of answering it like 14 times, write a blog post on it, put it in your FAQs, pin it on the support forum to the top as a sticky, sticky, not a post, whatever it's called. So it's always there so people can see it, those sorts of things. But yeah, I suppose I've not really run into massive issues with like lots of support requests because I simply don't have the user base in the plugins that I've got. Maybe I need to come up with some more techniques if I suddenly got a big purge of lots of users, but yeah. Maybe another thing for the support topic. You mentioned the subscription of emails to a plugin. There's also a feed for each plugin and there's also feed for all your plugins. So if you use a feed reader or something like this and that, you can just like subscribe to the feed of all of your plugins and on any plugin, there's a support question you will get a new message. It's quite handy when you have lots of plugins. Yeah, good. I think there's another question just behind you, actually. Hi, is there any tips on SEO or is it just tags in description and title or what do you find is the best way to distribute the plugin? WordPress is pretty good for SEO anyway. If I think it's in the WordPress repository, you've got a pretty good chance of it showing up because WordPress ranks pretty well, I think. I'm not an SEO person at all, but blog about it, tweet about it, you know, all the usual sorts of things and that's kind of worked for me. But I think a lot of mine, well, some of mine are quite niche plugins so they kind of get found because people are searching for very specific things, really. But yeah, tags are gonna help, obviously, if that's where people are searching and giving it a name, obviously, that's, I don't know, either unique or descriptive or something like that. And so someone mentioned actually about names and I'm probably guilty of this, is like don't always call your plugins like WP newsletter, because otherwise when people see it in the WordPress, in their plugins, it's like they're just all WP and you can't actually, you know, they're all the bottom. So it's like, if you actually forget that and just call it something more sensible, maybe, and more descriptive, it's easy to find as well in there. So, nothing. I have another question. So I guess you've talked about getting your plugin on to the WordPress.org repository. I'm wondering whether there's like some kind of process for if you want to stop having a plugin on the repository, like can you take it down or give transfer control of it to someone else or how does that work? I don't know about taking it down. I assume that yes, the answer is, but there's no, I don't think there's any automated way of taking it down as in, you know, you press a button when you've logged in and stuff. I think you'd probably have to email all these plugins at WordPress.org, but I'm sure they would. I don't know, maybe they wouldn't, I don't. In terms of like giving it to someone else, there is a tag that you can have, I think it's called adopt me, is a tag in the plugins repository. And obviously you can list all the ones that have the adopt me tag and then you can sort of see and you might think, well, I'll take over that one and then they can obviously give you access or you can give that person the access to that folder. So that's another way of sorting it out. And then what I tend to do, I have one or two plugins that are really old. In the readme file, I just literally put a banner across and say, I'm just not supporting this plugin anymore. So it's gonna go out of date. So, you know, just telling the users that perhaps, you know, if you want to use it, you're gonna have to look after it yourself. And the other thing that WordPress.org just obviously is if the plugin's not been updated for two years, you get the little banner across the top of the screen saying this plugin has not been updated in two years, you know, please test it with the latest version, et cetera. So that sort of thing. Okay. I think we're at the end of the whole word camp almost, not just this talk, but thank you Mark for rounding us out in style. Round of applause for Mark, I think. Thank you. Thanks.