 Thanks for that introduction, Paul. Totally overselling me there. Good to see you all here. There's quite a few more people than last time I spoke to WordCamp, which is nice to see. So today, I'll be presenting an introduction to plugin development and proving that anyone can make a plugin. So hands up, anyone who has made a plugin before. Cool. So I'd say about half of you who has written code for WordPress before, like added code to your functions.php file or customized some CSS, something like that. So the same most of you. Cool. See, this is an introduction to plugin development. And this is what we're going to be building. So we're going to make a really simple plugin that's going to customize the WordPress login screen and replace the WordPress branding with our own branding. So is there anyone here who was intending to code along while I presented this? Anyone? Nope, cool. If you are intending to code along because there's not much code, it's simple. But yeah, just put your hand up or something if you want me to hold out so you can see all the code. So me, I'm a freelance WordPress developer. Like Paul mentioned, I live on the Gold Coast. I'm the founder of Mongoose Marketplace, which is a store for WordPress plugins. So my Mongoose page plugin is used on 30,000 websites. Used to be known as the responsive Facebook page plugin. But then I rebranded it and also Facebook yelled at me. So it's no longer called that. You can find me online at Cameron Jones' web on all the socials. So yeah, if you see that handle, it's me. I made my first website back in 2006 when I was in primary school using Microsoft Publisher. I wouldn't recommend. I started programming in 2008, making Flash games with Flash Action Script. So that was the first time I started writing code. Then I went to uni and did some code and stuff and then found WordPress. And quickly fell in love with it. And soon after, I released my first plug-in on the WordPress.org repository. And earlier this year, I released my first premium plug-in. So yeah, I like plug-ins and I've been writing them for some time. I wouldn't say I'm the most qualified person to talk about them though. I mean, I'll take the compliment. So what I'm hoping that you will know already is what a plug-in is, where plug-ins are installed, and just a little bit of PHP. So is anyone not familiar with those? One person? Google. So first thing we need, well, there's only really two things that we need to build a plug-in, a local development environment, and a text editor. So first of all, local development environments. These are the two that I would recommend using. Local by Flywheel, which is a really easy to use GUI that you have to install and manage local WordPress sites. Or Chassis, which is a more command line driven one, which is really cool. And I recommend that as well, which is based off of Begrant, whereas local users Docker. There's also plenty of others like MAMP and ZAMP and plenty of others out there, but those are the two that I recommend. The other thing that you'll need is a text editor. So I use Sublime. It's quite lightweight and easy to customize to suit how you work. A couple of other options are like VS Code, PHP Storm, Atom, or even the default text editor on Mac or Windows. We'll be fine. And so that's all we need, right? There's a couple of things that we should understand about how WordPress works to have it be worthwhile making a plugin. So the WordPress hook system is what WordPress uses to run code at certain times. And the way the hook system works is pretty much being the reason why WordPress has become as popular as it has. It means that WordPress is really flexible and easy to customize. And so that's why there's so many different amazing plugins out there. There are two types of hooks. There's actions and there's filters. So this is the syntax that you'll use for actions and filters. It's exactly the same for each one, just a different function. So you've got the hook name. So that's the name of the hook. So when a certain thing happens, that's what you'll use to reference it. A callback. So often a function, it could be, an anonymous function or a class or a namespace function, any of that sort of thing, any sort of callback you can use there. Priority. So this is what order that it runs in. So the smaller, the better. You can even use negative numbers. A default for that is 10. And arguments, which is parameters that get passed through to your callback. And so in the examples, you'll see how those work. So an action is like an event. So a certain thing happens and it runs an action and so you can hook in there and so when a certain event happens, you can run your custom code. So a filter on the other hand is like a sieve. It changes a variable rather than runs an event. So for example, an action. So there's the save post action. So when you hit save on your post, this code will run. And for example, this would create a tweet which would say I just saved a post on my website. I don't recommend you do that because that will also run like every time it auto saves and stuff like that. So yeah, don't recommend, but that's a simple example. Whereas a filter, you can see that it is replacing hello with newt. So if you have your default WordPress site, it comes with the hello world post instead of saying hello world or say newt world because we all like Pingu. And you can see there it is returning a variable. So we've changed the title, so that gets returned. Whereas the action didn't have that because we're doing code rather than changing a value. So a pro tip, you can add your own hooks. For example, WooCommerce is very good at this. So if you want other developers to be able to extend your plugin and not just be extending WordPress, you can add your own custom hooks and then other people can extend your plugin and you can even create an ecosystem around your plugin itself. And you can learn more at that link. So now, if we understand the hook system, we're right to get started on building our own plugin. So the three steps to building our plugin, set up the file structure, add the plugin file header and then write our code. So the first step, create a file structure. So in your wp-content-plugins folder, you're gonna have to create a folder for your plugin and inside that, we're gonna need to create a PHP file which will be our main plugin file where all our code will go. A CSS file so we can change the styles and copy the logo image that we're gonna use to replace the WordPress logo with. So pro tips, have a custom name for your folder. So like as custom as possible because WordPress will try and look for that folder name on WordPress.org. So if you call yours something that already exists on WordPress.org, WordPress will update it and overwrite yours which you probably don't want. I made that mistake very early on and yeah, learned from it the hard way because I lost all my code. And it's a best practice to use the same name for the file as you have with the folder. And so next up, we're gonna have to add the plugin file header. So if you've added those files and you look at your plugins page on in your WordPress dashboard, you're not gonna see anything because WordPress doesn't know that it's a plugin yet. So this is what you add to the main PHP file in your plugin and it has all the important information about your plugin to make WordPress understand that it is a plugin. So this is an example of what the file header looks like. So it's got the name, the author, the authors and plugin URLs, current version number, description, license and text domain and there's a couple others I think you can add. So it's all pretty self-explanatory that those details there are what you'll see on the plugin screen when it gets to your plugin in the list. Tip though, if you wanna distribute your plugin, you're gonna have to license it as GPL version two or later. I don't like the GPL, but that's, yeah, part of WordPress and yeah, you don't have a choice, unfortunately. So next up, we're gonna start writing some code. So this is the first thing that you should do is prevent direct file access. So all this does is it checks for a constant that WordPress defines. So if someone types in the URL and goes your domain.com slash WP content slash plugin slash your plugin and then a PHP file. If you have this, nothing will happen. If you have some more complicated code that would say delete files on your website or delete posts or something and it runs when that file's accessed, you really don't want people just to be able to type in your URL and it starts deleting stuff. So if you add this, it means that it can only be called if WordPress is being loaded and loading your plugin properly. And so next up, we can actually start writing our code now that our plugin is safe. So we have a function here, an introduction to plugin development, WCB and E19 style sheet. And so this is the same sort of code that you would use to enqueue a style for a theme. Tastes the same, like uses the same function, tastes the same arguments, that sort of thing. We use the plugins URL function to reference style files within our own plugin folder. So you can see here that we're looking for the styles.css file within the plugins URL and then the second parameter is the PHP constant file which is the current file. And then we're using the login enqueue scripts action and then referencing our function as the callback. Pro tip for making functions is make them as unique as possible because you're not the only plugin out there. So as we heard in Tony's talk, there are some people who have a hundred plugins on their side. So if you have like simple name like save posts as your function name and someone else has that same name, it's gonna break because it's gonna say this function already exists. I don't know what to do. So make your function names as unique as possible to prevent conflicts with other people's code. So next up, we're gonna wanna add some styles to the style sheet that we put in our folder. So this is all that you'll need to replace the logo. So you set the background image to our image that we've put in our folder and then I've got some other code which I think makes most images that you replace it with look a little nicer. And so that goes in your style.css file within that folder and the URL of the background image is whatever the name of the images that you've put there to replace the WordPress logo with. So now we'd go back to our PHP file and so that WordPress logo will now be changed but when you click on that logo by default it'll go through to WordPress.org and that doesn't really make sense if my logo is going through to WordPress.org. Yeah, a bit confusing. So WordPress provides a filter this time. Last time we were adding an action so this time we're adding a filter because we wanna change a value rather than add something in. And so you can see that we're replacing the variable that's getting passed in, the login header URL and we're making it my website instead of WordPress.org. And WordPress also has some link text with that logo. You probably can't see it but screen readers will see it and by default I think it says powered by WordPress or something like that. So now we're adding in some more relevant text saying visit Mongoose marketplace. And so exactly the same as when we changed the URL you set the text to be something different and return it and use a filter. And that's what it should look like once you've added that code. And see, as you can see it's pretty simple. You only need a few lines of code to get a working plugin up. Yeah, and I'm sure some of you are wondering like can you release it on WordPress.org? You could but you probably shouldn't because there's a lot more things that you should keep in mind if you wanna distribute something on WordPress.org. So a couple tips. So your plugin should adhere to the plugin guidelines. So it pretty much can be summed up with don't do bad things, don't spam people, don't break people's sites, that sort of thing. But yeah, there's some plugin guidelines that you'll need to adhere to. You'll also need to learn how to use SVN which is a worse version of version control and git. So I only ever use SVN for WordPress.org stuff. So yeah, it's not really used much anymore so you probably won't use it other than for this. You should also adhere to the WordPress coding standards. So WordPress has defined coding standards for the different languages, CSS, PHP, in JavaScript and all that sort of thing. So the code is familiar if another developer wants to look into it. This includes stuff like naming conventions for your files and classes and functions and spacing and that sort of thing. You should also make sure your plugin is able to be translated. This is something that took me a while to get my head around. So WordPress is in lots of different languages. So if someone who's not speaking your native language uses your plugin and your plugin isn't set up to be translated, then they're gonna have to learn a new language just to use your plugin. So it's always good to make sure your plugin is translatable if you want other people to use it. If you're using forms, you should use nonces and capability checks and escape and sanitize user inputs. So making sure that your plugin is doing things securely and not allowing it to be exploited and things like that. You can find more details on that link there. So I have a WordPress plugin development for beginners course which you can access at that link and you can take it for free. It's similar to what I have just presented but it goes into a bit more depth about how plugins work and a couple more of the more involved topics like getting into coding standards and translating your plugin and that sort of thing. So if you're interested in taking that, that's the link you can follow. And for the demo code, if you wanna look at the demo code that I've put up, you can find it at that link and you can also find the slides there too. Thank you. And by my first proposition that you are one of the best plugin developers that I know. So that was pretty cool, really well spoken. Who's gonna go home and make a plugin after tonight? Yeah, I think we all will. Cool, all right, well, we've got heaps of time. Four questions. So let's just, yeah, questions. Ask, Amy, ask away, not literally, come on. Thank you. Is it worth considering using namespaces in your plugins so you don't have to worry about the function name collisions? Or does that bring a little bit of overhead into the whole thing? What do you recommend? Like if you're creating a plugin, do you think in an object-oriented approach and then not having to worry about function names, as you mentioned? Yeah, I tend to use classes. I haven't really used namespaces much, but yeah, definitely use classes and namespaces if you're familiar with them. It definitely helps with avoiding naming conflicts and means that you're writing less code in the end because yeah, you can write your functions within your class or your namespace a lot shorter and that sort of thing. So yeah, definitely a good idea. Good job, Cameron, thank you. Could you just expand a little bit about the localization? So in the code that you presented, you said that you were replacing the mouseover powered by WordPress thing. How would you do that? How would you make that localize? Okay, so if I go back to that one, right? Yeah, so where I have the login header text variable, I'd wanna wrap that in a function. So it would be underscore underscore and then wrap that. And that would be the first parameter and then the second parameter would be the text domain. So if I go back to the plugin head, wait, I think I got past it. Yeah, the file header. So you'll see that last one is the text domain. So you declare that in the head of your plugin and so then you use the localization functions which usually start with an underscore. And so you wrap your text with that and the first parameter will be the text you want translated and the second parameter will be that text domain that's declared there. And then you will need to run some sort of script to build PO and MO files. I've got a grunt script on GitHub that does that. And so yeah, it creates a PO or MO file and then if you are distributing on .org WordPress like manages the translations automatically. But if you're distributing it elsewhere you'll have to add in another function that loads in those language files. And so you can use a free editor like poetic is what I use to actually do the translations. So yeah, I might have to show you how it all works sometime. Yeah, it'll probably be my next talk topic then. And you just put those PO files in like a sub folder in the plugin? Yeah, you don't have to put them in a sub folder. If it's on .org, you just have to wrap them in the right functions. But yeah, if you're having like a local theme or something like that. Yeah, you put them in a sub folder that has all your languages in and then yeah, you just call another function that tells WordPress where those languages, language files are. Cool, thank you very much. Hey, thanks for that Cameron. Question for you, at what point would you typically recommend that you create a plugin rather than adding something to a child theme? That is a very good question. Something that I'm sure is very subjective. Typically what you would say is anything that you want to reuse on multiple sites is better served in a plugin. So let's just say you have some function that you put on every site that you build or manage or whatever. And it's a lot easier to just have a plugin and drop that into all your sites and activate it rather than copying, pasting that code onto all your different function files. So that would be my gauge as to whether it should be in a theme or a plugin. There are other guidelines like WordPress.org says that you should only register post types in a plugin rather than a theme, that sort of thing. So there's some, it's not like necessary but there are some recommended guidelines as well there. So yeah, if you want to reuse it on multiple sites make it a plugin, it's easy to manage in my opinion. All right, you mentioned that if you have a plugin with a particular name and then that matches with the name that's in the WordPress repository, it will get overwritten. Is that a problem where you have a plugin that you're using for your own stuff and then one gets added in the future to the WordPress repository and you're not aware of it and then it kind of gets overwritten? Is it, do you have ways around that? Off the top of my head, yes that definitely can happen and that's why you should always try and make it as unique a folder name as possible. Yeah, thankfully the one time that happens to me it was very early on so it didn't cost me much but yeah, I don't really have anything in mind. There is probably a way of doing it but not that I know of off the top of my head. Thank you Cameron, that was a pretty good talk. This is more of a just a fun question so what's a pain point or a plugin that you wish existed that somebody here could write for you or just yeah, what are some other ideas that you might want to plant and see what plugins come back from people over the rest of the next few months? Cool, that's a dangerous question because I could just keep all my ideas to myself and make more money. Yeah, that is a good question. If someone could make a plugin that removed the post meta table and changed all the meta fields into columns in the post thing and split out post types into their own individual tables that would be really nice because the WordPress database structure has always driven me insane so yeah. That's a quick one, did you start it with? So yeah, I'm sure someone can whip that up in the next five minutes, yeah? Cool, thank you. Howdy Cameron, do you have any debugging tips or go to tools? Good question. I'd say query monitor is a pretty good place to start. Gives you a list of every hook that runs on a page that loads so and it tells you PHP errors and that sort of thing so that's usually a good place to start. I know PHP Storm has some pretty cool debugging tools but I don't really like PHP Storm because it's really bloaty but yeah, query monitor is probably a good place to start. Depends like what sort of thing you're looking for like you're looking for just whether your code works or not or unit tests or code standards or yeah, is there anything in particular? Mainly just debugging for issues is the big one, obviously. Okay, yeah, I'd say just start with query monitor. That's probably a good place to start. Cool, thank you. What's the minimum due diligence in terms of ensuring quality before you release? That's a really good question. That differs from person to person but for me it- A good person. A good person. For me it's just following the WordPress coding standards and making sure that your plugin is secure and has the right capability checks and sanitization and that sort of thing. It obviously differs from plugin to plugin. Like that sort of plugin that I just walked through is not complicated at all. It doesn't take any user input or anything so it's pretty fine but yeah, just follow the guidelines and standards and that sort of thing that WordPress declases pretty much the best place to start. Thank you for your talk. I'm coming from the other end so I'm a project manager more so and developer, front end developer but I do have a couple of guys in the team who do custom plugins for us. My biggest concern I guess and apologies, early apologies but plugin developers like all of us can be hit by bus. So my biggest concern I guess is that when we have a custom plugin built I don't wanna trap our clients into relying on that plugin developer for any updates to it in the future. How particular is the code to the plugin developer themselves? That's yeah, good question. Yeah, like every plugin and plugin developer has their own style and that sort of thing but we do have coding standards that are recommended to be followed so it should be at least readable and familiar enough for someone to just be able to jump in. So that's why those sorts of things exist so that if you've got more than one person in a team or someone needs to take over that sort of thing they can still understand the code because it should be a similar structure and that sort of thing. Yeah, that's mainly where I'm at and I understand that there might be some time in familiarizing yourself with the process of that plugin but as long as it's a possibility in most cases. Yeah, there are some plugins that are just absolute rabbit holes and you're trying to figure out how they work forever but if they're following standards and guidelines and that sort of thing they should be pretty right for someone to be able to jump in at least. Excellent, good to know. Thank you. There's been a few cases on with different open source plugin or tools that have open source plugins where the plugin developer has a few thousand installs but then they sell up to someone else and then they rewrite the plugin so it is now a hack or a backdoor or someone that. Can you talk to that at all? Or just your opinion on that or like how if you've seen anything that space. Yeah, there's a bit of that in WordPress, unfortunately. I've had a few of those people approach me and they couldn't offer me enough money to sell it to because it's so obvious that they're scams but yeah, it is unfortunate when that happens and so having plugins like WordFence or something like that running on your site is a good idea because they'll pick up on that sort of thing. It's a tough one because WordPress.org like to update your plugin like there's no sort of checks that it goes through. Like when you submit it, they check it but once it's approved there's no further checks so that's how that sort of thing is able to get out. Unfortunately, like there's not much you can do except like put security plugins on that will hopefully catch that. It's yeah, just unfortunate reality and open source software, unfortunately. Back on the standards thing you were talking about before is there any automated tools or anything to help but adhere to those WordPress standards like is there a PHP code sniffer rule set or anything that you've found helpful for what you do? Yeah, so I've got my text editor will do a check in the background while I'm coding and I'll flag a line if it doesn't meet the standards. Yeah, I've also got some scripts that I've set up with like Travis and CircleCI that'll run when I deploy when I push something up into the repo and it'll run and then return errors or that sort of thing. So I do have some stuff on GitHub that I can send you a link if you want. Me again. I just really like asking you questions because you've got such great hair, so. Thanks. So question you mentioned towards the start about plugins that have their own hooks and stuff that you can jump onto and I think you gave WooCommerce as an example of one that sort of built an entire marketplace around it. Is there anything unique that you need to know if you're looking at creating a plugin that is based around another plugin? Not really, just a familiarity of how that plugin works really. Custom hooks are no different to normal WordPress hooks, like it runs the same function and it takes the same arguments, that sort of thing. So obviously, WooCommerce is very different to how WordPress Core works, so you'd need some familiarity with how WooCommerce works and what you're actually trying to achieve with that. But yeah, just some familiarity with how that plugin works is all you'd really need. Yeah, excuse me. Just a question regarding PHP versions and plugins. What's WordPress's policy as far as plugins keeping up to date with the current release of PHP? Yeah, so WordPress recommends version at least 7.0, I write my stuff to work with at least 5.6 or up. The official stance is that it's recommended that you have 7.0 or more. There's no sort of policy or anything enforced though, so if you wanna write your plugin to only support PHP 7.3 and up, then that's fine and if you wanna support all the way back to PHP 4, that's also fine, yeah, nothing's really enforced, but it is recommended that it's from 7.0 up. We've got time for a couple more questions, guys, if you have any. Or we could just get food. Right. Yeah, so there's a lot of hooks and filters out there and obviously that's the kind of bread and butter of what you're gonna build. And you mentioned obviously WooCommerce or other kind of platforms that provide those. So do you have any kind of go-to resources that you go to find out what's available and to kind of work out how you're gonna go about solving your problem? Some of it just comes from guessing, honestly. Some of it's just guessing, WordPress is pretty consistently named, so you can guess that when a post is saved, it's the save post action. If you use query monitor, it'll output a log of every single hook that runs, so you can go through and trace this runs at this time, so this would be a good hook to add things on. A lot of the documentation has recommended hooks to use for certain things like you use the WP and Q scripts to enqueue your JavaScript in CSS, for example. Yeah, if you wanna see a list of all the hooks, you use query monitor or something like that. Yeah, other than that, just dig into the code. That's what I find myself doing a lot is just, yeah, going through rabbit holes of other plugins code if I wanna change something. I've got a question for you. No. Do you get plugin envy? In what way? Well, when you sort of see a plugin that's been developed and you go, oh, that's really good. I really wish I'd done that. Or, you know, I love the code, you look at it and go, wow, that's amazing. Yeah, yeah, yeah, I kind of made an inferior version of Gutenberg a few years ago, so yeah, I'm shaking my fists at automatic. Right, okay. Cool, all right, well, thank you. Personal question. All right, guys, well, I might wrap up there. The other session starts in 10 minutes. So, so thank you, thank you, Cameron. Yeah, please.