WP Product Talk
WP Product Talk
Why your plugin needs to follow WordPress Coding Standards
Loading
/

Are you a WordPress plugin developer looking to take your work to the next level? In this episode, we dive into the importance of following WordPress Coding Standards when creating plugins. Whether you’re a seasoned developer or just starting out, understanding and implementing these standards can make a huge difference in the performance and compatibility of your plugins.

Joining us for this insightful discussion is renowned WordPress developer and coding standards expert, Joost de Valk. With years of experience in the industry, Joost has a wealth of knowledge to share on why adhering to WordPress Coding Standards is crucial for the success of your plugins. Tune in to hear their expert advice, practical tips, and real-world examples that will help you elevate your plugin development skills.

ep64 WP Product Talk – Why your plugin needs to follow WordPress Coding Standards with joost de Valk

[00:00:00] Matt Cromwell: What's the first thing you think about when you hear the words WordPress coding standards? Probably something like obligation, boring, uh, just stuff that you don't want to deal with. In one form or another though, these can be differentiators for your business. So today we're going to talk all about that, going deep and seeing how we can impact your business from the perspective of coding standards.

[00:00:34] Is WP Product Talk a place where every week we bring you insights, product marketing, business management, and growth, customer experience, product development, and more. It's your go-to podcast. For WordPress product owners buy WordPress product owners. And now enjoy the show.

[00:01:00] Zach, welcome to the show. Thanks for being here.

[00:01:04] Zack Katz: Thanks. I'm, uh, I'm Zach Katz, uh, founder of Gravity Kit and Trusted Login.

[00:01:10] Matt Cromwell: And, uh, are you excited to talk about this topic today?

[00:01:13] Zack Katz: I am absolutely excited to talk to this topic about this topic today. And I'm extra excited, uh, because we have such great guests to talk about it with.

[00:01:22] Um, so we're talking about WordPress coding standards today, and we've invited Yost DeVault to talk about it. So Yost, uh, welcome to the show and please introduce yourselves. Uh,

[00:01:37] Joost de Valk: hi everyone. Thanks for having me. So, uh, Yoast founder of a company called Yoast as well, but you write that with Y O A S T, uh, we sold that in 2021.

[00:01:49] And then I, um, my wife and I started investing into other companies in the WordPress space. Um, so that's what we do now. And I, yeah. Um, well, because of that, I look into a lot of software and a lot of plugins, and, um, I have opinions.

[00:02:09] Matt Cromwell: Uh oh. Never one to be short of opinions, for sure. Absolutely not. Nice.

[00:02:17] Well, this is a good subject, and the way that we always like to kick this off is to talk about why, This is so important for WordPress business owners. And by the way, if you all are here watching us on YouTube or on the Twitter X thinger, um, feel free to add comments. Uh, we love to highlight them and, uh, answer them live on the show.

[00:02:37] Uh, especially any comments that make Yost blush. Like if you can do that extra bonus points, we will answer them first. Um, but besides that, um, what do you, uh, why do you say this subject is so important in particular? I'm sure as you are. Um, consulting with folks who you are investing in at Amelia. Uh, this comes up.

[00:02:58] Uh, I'm certain that it's, uh, that it's raised in one way or another. We'd love to hear from you. Why is this so important for a WordPress business?

[00:03:05] Joost de Valk: So, the way I look at WPCS, it's, uh, is that it's actually important for quite a number of different reasons. So, WordPress coding standards is actually a bit of a misnomer, I think, because it's not just coding standards.

[00:03:20] It's, it's so much more. Gives you, um, a lot of feedback on your code and on, uh, things that you could or should not do, um, in ways where I'm, well, always a bit surprised when I run WPCS across someone's code base, and I find a lot of errors that I'm like, yeah, this is going to cause errors in real life. W WPCS is basically, um.

[00:03:51] It's the maintainers of WPCS in my mind. It's always Juliet, who's probably the most important maintainer of that sitting on my shoulder and telling me you're doing it wrong. You're doing it wrong. And, um, there are actually, I think, a couple of aspects to that. So, first of all. Adhering to the WordPress coding standards makes WordPress code a lot easier to read

[00:04:18] Matt Cromwell: and

[00:04:18] Joost de Valk: not just for you, but it's something that I, what I tell all of our companies that we invest in, if you take investment money, then you want to grow faster, and which all Almost always means bringing on more developers and at the point where you're no longer developing alone, you need to have standards that define what your code will look like and that make it easy for you to maintain someone else's code and and the other way around.

[00:04:48] And if you're doing that, then thinking about those coding standards for much longer than, than you should is stupid if the WordPress coding standards are out there now, you can, of course, make adjustments, slight adjustments to how you like to use those coding standards. There are things in there that developers might actually hate.

[00:05:08] I, for instance. Really, really dislike Yoda style comparisons. So I disabled them. Um, I also like dislike long array syntax, so I disable it. Um, but you can, you can make those decisions and that's fine. As at least your entire code base is at that point, consistent and easy to read. Um, that's one second bit is that it catches a lot of potential issues.

[00:05:35] And I think there are two types of potential issues that are important to know. One is it catches issues where WordPress has a better function or a newer function or, uh, a, a smarter way of doing things where you can really save yourself, prevent yourself from having issues. And the other one is it actually gives a lot of.

[00:06:02] Feedback regarding not properly sanitizing, uh, and escaping data. And, um, if you've seen last week, patch deck rel relate, release another state of WordPress security report, and they were saying like 60 percent plus of security issues was cross site scripting. Yeah. Well, to be fair, those are perfectly preventable issues for people to have issues like that.

[00:06:34] And to have them reported to you when you could have just caught them yourself, it's stupid. So I think that running WPCS on your, on your code base is something that pretty much everyone should probably do if they're building WordPress plugins. Even if you decide to, to completely morph it up and change your, uh, what the code style looks like, it's all the other stuff in there that is actually really, really, really valuable and, and makes your product better.

[00:07:07] Matt Cromwell: Yep.

[00:07:07] Joost de Valk: And I don't see why you wouldn't do that. And if your product is open source, then you can run these WPS WPCS in GitHub actions or wherever for basically free. So I don't know why you wouldn't do it.

[00:07:24] Matt Cromwell: Are there good examples out there of how you've seen some open source, uh, projects, uh, implementing GitHub actions for this?

[00:07:30] Um, so I, well, we tried, like, it'd be great if there was just like copy paste kind of ways that we can implement this. I mean, that sounds like a pipe dream, but is that the case?

[00:07:41] Joost de Valk: No, no, it's not a pipe dream. It's what I exist for. Um, so I have a plugin called fewer tags that I maintained together with my wonderful core, uh, colleague, uh, Ari.

[00:07:53] Um, and we, well, we tried to make that the example of how we think this, this sort of stuff should be done. Um, now I will say that that one is a relatively simple because it doesn't have a build step. Um, but yeah, it has all the, the, the GitHub workflow, but I mean, to get that workflow for, for doing this is basically one file and.

[00:08:17] And it's super easy to just copy, paste, modify, and you can get this running and you can really prevent yourself a lot of issues. It is, I mean, there are a couple of things that you need to figure out as you do this. You will want to look at like how this, uh, the configuration for WPCS work. It relies on PHPCS.

[00:08:44] Um, so you need to play with that a bit. Um. What I also think that, uh, people forget about doing quite often is enabling PHP compatibility, uh, and the specific WordPress rule set for that PHP compatibility WP, um, which basically helps you not use PHP functions that you can't use on different PHP versions.

[00:09:10] I mean, the. The gamut of PHP versions that we need to test that shrunk a bit, but it's, it's still like you're going from 7. 4 to 8. 3 at this point, um, you can have some help with that and it's free and it's simple. And it, I, yeah, I think it's really important for people to use.

[00:09:31] Matt Cromwell: Interesting.

[00:09:33] Zack Katz: And what, what is, uh, the, there's the plugin check plugin, which is new, uh, relatively new, uh, there, there's been a theme checker for a long time.

[00:09:42] And now that that's come to the plugin world. Um, do, does the plugin check plugin get you all the way there or do you still feel like, uh, there needs to be, uh, a full test on, on commit and GitHub actions or similar?

[00:09:57] Joost de Valk: I think the latter is actually probably a better practice. Um, you can, you can decide when, when and where to run that, right?

[00:10:05] You can run it in GitHub actions. You could run it in a pre commit hook on your own machine. You, you can do whatever you want with this. Um, I would prefer that. Because I would prefer to ha to have that check where my code is and, and run it there because that makes the most, that makes the most sense to me.

[00:10:27] It's also like, for me, when I'm inspecting your code, I, I expect to see stuff like that. I expect to see that you're well, that you can take care of the quality of your code. And if you're looking for investment, that's definitely one of the things I'm looking at. Hey, are you taking care of the quality of your code?

[00:10:50] Is that, uh, are you really thinking about how should we be doing this? And have you, have you thought about this? It doesn't mean that you can't get investment when you don't, when you haven't done that, but it does mean that I'll add a to do item. Like, okay, we need to fix this.

[00:11:09] Zack Katz: Sometimes fixing. PHP coding standards issues can also introduce other issues when you're trying to make things comply, uh, that results in a lot of different changes to a lot of different files and a lot of things can fall through the cracks.

[00:11:26] So like, uh, that's one of the things that I recently heard from a friend of mine, who's, uh, who has been applying these, the coding standards and, uh, they thankfully had unit tests in place that caught some issues that didn't cause Weren't caught by a visual code review. So when you're doing coding standards, like it seems like maybe you should also set up a unit test flow and, uh, and, uh, and the static code analysis and, uh, like past and like how, that's, Because as a developer who I, I love a UI, I'm, I can, I can make my way around a command line fine, but I like an interface.

[00:12:08] I use the GitHub desktop app. It's great for me. I don't want to do a pre commit step. Um, and honestly, configuring the relative path. For the PHP coding standards has cost me 15 hours of my life and it never seems to work on the first try. He goes, what, what can you tell me about this?

[00:12:30] Joost de Valk: Um, so the next time you just copy paste an existing repo where it works.

[00:12:36] Matt Cromwell: I don't ever touch that repo ever again. This is,

[00:12:40] Joost de Valk: this is how I work too. I mean, it's, there's nothing wrong with that. I feel your pain. Definitely been there. Um, I, so I agree with you in an ideal world, you'd set up unit tests, et cetera, too. I think the difference is that if you've done WPCS a couple of times before, um, running WPCS on a code base is something that I can do within 10 minutes and usually two or three.

[00:13:11] And, and it gives me a lot of feedback about the quality of that code. And building a unit test framework for a plugin can be a lot more work. And there's one thing I hate more than a, than a code base without a unit testing, uh, without unit tests, it's a code based with stupid unit tests. And the, because they give a false sense of security that, that is very, And I think WPCS is, is actually pretty well battle tested and doesn't do that as much.

[00:13:55] Um, and well, it might give you some false positives sometimes, but then it also forces you to document those false positives in a good way. Like, why are you, why is it okay for you to not escape this piece of code here? Um, why is that, why is that good? It's usually not a good idea, but there might be a reason why.

[00:14:19] And then it forces you to write inline documentation that matters.

[00:14:23] Matt Cromwell: Yeah.

[00:14:23] Joost de Valk: Um, so I, I think that's good. I, I think expanding on that can be even more interesting. So, um, back at Yoast and we now to have a more specific rule sets where we actually require documentation for functions to be, to be quite specific.

[00:14:41] Uh, and, and. And well, there's things that you can't get away with, which I think is good.

[00:14:47] Zack Katz: Yeah. Um,

[00:14:48] Joost de Valk: so

[00:14:48] Zack Katz: there's a PHP, why the PHP coding standards and not some coding standards, uh, that are accepted by the PHP community at large, like the, um, there's the PHP working group, which is. Um, has the second draft of the PER coding style 2.

[00:15:10] 0. Um, why not that? And why choose WordPress?

[00:15:14] Joost de Valk: Honestly, I'm not, I don't really, really care. I'm fine with you using that one too. And you just want a

[00:15:26] Zack Katz: coding style that is adhered to consistent. Yes.

[00:15:30] Joost de Valk: I mean, being dogmatic about these things never works. Um, I think what's important is that you think about WordPress naming conventions.

[00:15:42] Uh, so you, well, there's, there's a lot of. Um, rule sets from the work from the WPCS that you can also use if you use another coding style and, and where you, where you could, and at that point you need to invest a bit more time, but it's perfectly doable. I will say though. If you want to grow your company in the WordPress space, you're going to end up hiring more WordPress developers.

[00:16:09] They will know WordPress coding style, and it's easiest for them to do that. Um, yeah. So I, I, I mean, a large, large part of all of this is just preparing your code base for collaboration.

[00:16:25] Matt Cromwell: Hmm. Mm hmm. Yeah. You know, I'd have some standard rather than no standard is, is at least going from zero to a hundred pretty quickly.

[00:16:33] Joost de Valk: Yeah. And people can have very long discussions about whether tabs or spaces are better or other things. And I don't care. Yeah. I really don't. I just want you to maintain your code in a way that I can see that you're paying attention to detail and that you're not leaving stuff. Yeah. Unattended that really could, should be, and could be attended to.

[00:17:01] Matt Cromwell: Yeah, real quick where we do want to talk a little bit about some of our own personal experiences. Um, but, um, one, two, two things that are on my mind that I think a lot of plugin devs, um, are thinking about right now, one of them is like, um, what, what's the difference between just like. WPCS and being like VIP ready, like being able to be accepted on the VIP platform.

[00:17:25] I think there's a lot of overlap there. Um, and the other one is, uh, there's been a lot of conversation over the years for a long time, uh, between, uh, essentially, um, Do you want to have like a purely functional, uh, PHP approach to your, uh, code? Or of course, do you want to be more object oriented? Like a lot of folks are just getting their plugins out the door, all functional procedural code.

[00:17:49] Um, and, um, and then eventually later having to like level up to be object oriented, which is not always a hundred percent necessary. Um, but it kind of looks better to other folks who might be looking in. So, uh, those are two kind of. Moving target ones. I want to try to clarify around this subject real quick.

[00:18:08] Um, first the VIP one. What do you think? VIP ready? Does that matter? Is that how much is that, uh, a overlap with WPCS and things like that?

[00:18:19] Joost de Valk: I think a lot of its overlap and, um, some of the VIP specific rules and functions are Actually quite good things to talk about because they usually relate to performance.

[00:18:33] Matt Cromwell: Mm mm-Hmm? . Yeah.

[00:18:35] Joost de Valk: Uh, so if you're doing things that the VIP rule set prohibits or wants you to do differently, then most of the time if, if the VIP rule set has a wp.com specific function for that. Then you should also think about how to deal with that on non wp. com installs, because then it's a very heavy query where you're doing things that might not be a good idea for your other customers too.

[00:19:04] Matt Cromwell: Yeah, that's a good point. And then like procedural, um, versus, uh, object oriented, is that like a thing that, that, uh, young, uh, New product owners need to worry about.

[00:19:17] Joost de Valk: Well, product owners, not necessarily. I think developers at some point, it depends a bit on how big your code base is. I, uh, I personally prefer object oriented for, for most of these things, but there, but especially if it's a smaller plugin, then go functional and don't bother.

[00:19:36] I mean, the overhead of, of all that classes, et cetera, it might be, might be a lot, but, um, I think that if you've done this a few times and you've written a couple of plugins, um, things like auto loading, et cetera, should be relatively easy to implement. And if your plugin goes, grows bigger over time, you'll be happy to have it.

[00:20:06] Matt Cromwell: Good stuff. Good points.

[00:20:08] Zack Katz: Yeah. One of the things that we did recently at TrustedLogin, Was we did a full, uh, re analysis using the coding standards. Cause we, we, uh, we developed it, uh, multiple different people worked on it. And by the time we were done with it, it was not a cohesive, uh, coding standard. So I recently went through and made sure that that was the case.

[00:20:34] Uh, and it did come up with a bunch of results where. It said WordPress has a function for this. And I said, yes, I know WordPress has a function for this, uh, but we can't use it because WordPress has a filter that if the filter were tapped into would make our code insecure. Um, so there, there, there comes also a level of discretion that's necessary when you're, when you're applying these guidelines that, Oh, absolutely.

[00:21:05] Yeah.

[00:21:06] Joost de Valk: You can't, you can't stop thinking it's the same as using AI. I love using AI to help me code, but it shouldn't stop you from thinking about what it outputs and what are, what it outputs is any good. Right. It, it, it really, yeah. It is really super important to keep that, to keep that in mind. No, I agree.

[00:21:28] And it, and, and I hear you on the filters. I think there are some ways to meet, to. Prevent filters from happening. Uh, so you could look into that, but yeah,

[00:21:39] Zack Katz: like saving all the filters, removing all the hooks, calling the function, re adding all the filters. It's not like that's a pile of hacks that I didn't want to get.

[00:21:49] I just copied the function into our utility folder and, and, uh, remove the filter.

[00:21:57] Matt Cromwell: Yeah. Well, let's jump into some of our, uh, Personal experiences with this, uh, you know, the, I sometimes just talking about actual things that we've had to do over the years is what makes, uh, the point for why this is so important at the end of the day.

[00:22:12] Um, so, uh, at first I think I put Zach, right. Um, uh, Yeah, well, I'll keep, I'll, I'll keep

[00:22:20] Zack Katz: going with that. Cause that was my trusted login experience, trusted login, relatively new. Plugin and, uh, and application compared to gravity kit and gravity view is our oldest in gravity kit and, uh, gravity view. We've had a lot of different developers working on it over, over the years.

[00:22:38] And with a lot of different ideas of how things should be structured. And, uh, just this year, we are finally. standardizing. We're doing the coding standards implementation. We've had static analysis set up at different points, uh, but, and unit tests for years, but we're finally getting on board with the whole coding standards thing.

[00:22:57] And it's going to be a lot easier because we've had trouble bringing on developers. For example, from the Laravel world, uh, people come in and say, what is this? Going on with the WordPress, uh, way. And we had to say, well, we kind of do the WordPress way, but if you want to do the, like we, we had ad hoc conversations about how we would do, uh, different implementations based on the requirements.

[00:23:23] And now we're going to have a better process for doing that. So it really has helped guide. It's more like a, it's a handbook you can adopt that says, here's how to work. And, uh, that's really helpful. We always have had a backup, a fallback, um, for the 10 up developer documentation, which I love. Uh, they have really good, um, handbook for engineering.

[00:23:48] Best practices, the 10 engineering best practices are great. Uh, so we were, have referred to that in the past, but, uh, having the, um, the coding standards codified, it's really helpful and automated now.

[00:24:03] Matt Cromwell: That's awesome. Uh, Yoast, do you have a really practical, specific example that you can share on how things went maybe at Yoast.

[00:24:13] com or things you're seeing right now?

[00:24:15] Joost de Valk: So we, we were in the lucky circumstance and we had a pretty large team. So at that point you, you have a lot of different opinions. Um, and, um, At that point, it also becomes more important to codify like, Hey, what is our coding standard? What, how do we make these decisions and how do we, uh, try to, to, to make this all simple?

[00:24:43] Uh, we actually codified a lot of it on developer. eos. com too. There's a plugin development standards section there as well with, uh, how to do these things. A lot of PHP unit, best practices and other things. Um, I, I think it's super important to have an opinion about this, and I don't think it really matters which your, which opinion it is.

[00:25:08] I think it's important that as a team, you agree to a set of standards and that you keep to those. And of course, if if those standards are in your way and you adapt them a bit because it makes life easier for you as a team, then by all means, do it. But the gripe of an individual developer should not change your coding standards.

[00:25:29] I think that that is. Uh, the most important thing, um, I think another thing that we, that we used to do, um, as we were introducing more and more of this over a fairly large code base, so it's something we, we called code scouting, uh, where we basically said, every time you touch a file, you make sure that that file passes WPCS, um, And you don't go like do this for an entire code base all at once.

[00:26:06] Uh, because sometimes going, going through a code base all at once can become quite tricky because you have to,

[00:26:13] Matt Cromwell: yeah. That's also like the area where we're doing this work can become problematic because also 25 files instead of one.

[00:26:23] Joost de Valk: Yeah. So there are some things that you can do to help yourself with this is that you Um, you can allow it to have a number of errors.

[00:26:33] So you basically run WPCS and then you say, okay, the number of errors we have now is the number of allowed errors we have. And then you, you're, you're basically preventing yourself from. Adding more

[00:26:46] Matt Cromwell: snowballing

[00:26:47] Joost de Valk: over time as you, as you clean them up, you've reduced that number and you try to get as close to zero as you can.

[00:26:52] Matt Cromwell: Yeah. This actually touches a little bit on a question that Amber raised in the comments, um, can you talk about how fast this should be rolled out? We converted a more to a more object oriented workflow and went too fast, which broke some functionality, even with a very senior dev working on it. So it sounds almost like.

[00:27:11] I don't know. I don't want to speak for you, but are you suggesting that maybe they could have rolled it out slowly over time rather than all at once?

[00:27:20] Joost de Valk: This is putting me on the spot because we are an investor in Equalize Digital and Hypothetically. Might've been that we have given some feedback to Amber and the team on how to do certain things.

[00:27:35] Um, no, um, I, I agree with Amber that to going too fast on these things is, is, can be scary and daunting. And, um, especially in these cases, it's also like if, if there's not a big PHP unit. Uh, properly set up test case for this and maybe even some interface tests because quite a, quite a few of the things that you might, that might, might work well in PHP unit, but your interface might not, might not like what's been happening.

[00:28:03] Um, this can be, this can be an intriguing thing to do, which is why that whole code scouting principle of doing this one file by file as you go along sometimes makes sense. I will say that what Amber specifically said. Towards a more object oriented workflow. That's a bit harder to do step by step because well, the benefits don't really, you only really like 90 percent done.

[00:28:33] Um, so, so that might feel like a bit less, um, less of a good thing.

[00:28:40] Matt Cromwell: Yeah, totally. I'll say, uh, from my, uh, personal experiences, I, I definitely have developed, uh, along the way. Um, I'm not on the development team here and there, but, um, they, they love, I had loved to have a fun environment with them. I love to know all the things, why it works the way it works.

[00:28:59] They always call me the most dangerous developer on the team. They don't let me do stuff anymore. Um, but, um, Originally, Devon and I, we launched GiveWP extremely procedural. Everything was just, just function this, function that. Um, it got us out the door. It got us successful. It got us successful enough to hire people who knew how to fix it all.

[00:29:19] Um, and that was great. That's the way it should have been. But there was so much code already at that stage where, um, we have a really great dev who's been with us since the early, early, early days. He's still working with us today. His name's Ravinder. And there's so many things, still to this day, where it's like, uh, that's this one area that we're just like Nobody knows how it works.

[00:29:41] Ask for vendor. That's an ask for vendor thing. And it's because that's the way we ran Everything and the whole entire code base was covered in that way in that way from the beginning We've been cleaning it up and introducing more object oriented classes and things all along the way And that's been getting better and better on that front, but there's still to this day a lot of uh Um, asker vendor moments that we have, um,

[00:30:06] Joost de Valk: the

[00:30:06] Matt Cromwell: other one are

[00:30:07] Joost de Valk: definitely sections of WordPress that are like that, too.

[00:30:10] Yeah, yeah, I mean, rewrite is a section of WordPress that basically you don't want to touch.

[00:30:17] Matt Cromwell: Yeah, absolutely. I mean, I've asked, uh, Some folks like John Jacoby, like he knows some of the WordPress core stuff that I've just never even heard of before. Um, another one that we did have along the way too, is we were approached by, uh, a long, long, long time ago.

[00:30:32] We were approached by snopes. com. They wanted to use give WP on their website. Um, and we were super excited about that, but they were on VIP. Um, and again, it's, it was one of those things where, um, Uh, it's not exactly WPCS, but the things that they needed to see happen to give WP at the time were performance oriented.

[00:30:52] Since then, we've done a ton of work on the performance side because we've gotten more and more customers who are larger and more significant and hit their database a lot harder than others. Um, and so we've had to do, uh, the painful work of like, all right, I guess for the next like three months, we're not pushing anything fun and exciting out the door, we're just kind of like.

[00:31:13] Cleaning up all this performance stuff and that's like a kind of like rip the band aid off kind of moment That's not super fun, which maybe I don't know Maybe could have been prevented if we would have had a different approach from the early days I don't really regret any of the ways that we went about it, honestly But at the same time, you know, I I don't know there maybe could have been a more optimal approach Um, we've also had to spend a lot of time getting a lot of things modernized and updated.

[00:31:42] That's just the nature with, uh, with open source code. That's like getting on. I just realized next year, give, give WP is going to be 10 years old. That's like a ancient plugin. Um, it's crazy. So, yeah,

[00:31:57] Joost de Valk: yeah. I think what you're describing is very common though. Uh, quite a lot of plugins are basically developed as a proof of concept.

[00:32:05] Matt Cromwell: Yeah, yeah,

[00:32:06] Joost de Valk: and are released as a proof of concept with maybe a bit of a cream on it, but that's about it. And then over time, I mean, it was definitely the same for me when I released Yoast SEO or at that time called WordPress SEO, I was not a very good developer. Basically I had no formal training in this whatsoever.

[00:32:27] And later on, I was lucky enough to be able to hire a lot of smart people around me who could actually teach me how to code better. Uh, and now I think I'm no longer that bad,

[00:32:40] Matt Cromwell: although

[00:32:40] Joost de Valk: Ari will still be a much better developer than I, than I am. Um, but yeah, no, I, I, this is the way it goes. But I also think that because of that, this is a, I exactly why you should be using WPCS.

[00:32:55] It is super simple to set up. It can get you a lot of feedback very quickly, very early, and it can save you a lot of these issues.

[00:33:02] Zack Katz: So is, is applying the coding standards. Your first, if you're taking over a code base, an existing code base and a development team, you're coming into a company, you're saying, uh, I'm the host I'm helping out now is, is coding standards, the first thing that you put, uh, that you implement.

[00:33:18] What is your, what's your How do you approach that?

[00:33:22] Joost de Valk: Um, I, I think the first thing that we tend to do, and it's usually, uh, RME looking at the code together, it's just reading the code and then quite quickly, you'll get a feel for what's needed. Um, And if you feel like this is a mess, then yes, WPCS is the first thing I do, mostly because a lot of it can be auto fixed too.

[00:33:50] So quite a lot of the things that I, that annoy the hell out of me, otherwise I can just run the fixer once and suddenly I have a code base that I can, that I can at least read relatively

[00:34:03] Zack Katz: easily. That's, um, it was going to talk a little bit more about that, because I'm not sure that people know that coding, uh, WPCS includes, uh, a way to automatically apply fixes.

[00:34:14] Uh, it is actually

[00:34:15] Joost de Valk: super helpful. So, um, one of the things you could do, say you have. Use long array syntax everywhere in your code or in half of your code and short array syntax and the other, and you decide to say, Hey, we're going to standardize on short array syntax. Then you can actually run PHP CBF. I think it's the, uh, it's the command, which is the auto fixer that basically applies your code standard to your entire code base, and it just fixes it all.

[00:34:46] So everywhere where you have long array syntax, um, you can just make it short. Okay. Um, and it, it makes a lot of these things a lot easier to read. It can, it, it can make code inta, code indentation, uh, code documentation, all these things that you, that you expect. It won't generate the documentation for you, of course, but it can make it all, um, well, easier to read and in a format that you really understand well.

[00:35:15] Um, so I do grab it quite quickly. Um, usually the, the first step is just going through the code. Um. My own personal thing is always to look for any instance of WP remote or curl or whatever it is that people are doing to get data from elsewhere. Um, because that's usually where the, where the scary bits happen.

[00:35:41] Matt Cromwell: Um,

[00:35:43] Joost de Valk: and, and then I go through it one by one and you just, you know, you try and understand the whole thing and that's easier said than done in some cases. Some of these plugins are, are fairly big.

[00:36:00] Matt Cromwell: Yep. Nice. Well, last segment that we want to wrap up with always is we love to give folks, um, uh, our best advice, um, on how to move forward, um, and how to tackle this issue.

[00:36:16] Um, so, uh, kicking it off, um, Yost, what is your best advice for, let's say new or young product owners who are wanting to get into WPCS for the first time?

[00:36:29] Joost de Valk: Um, steal. This is what open source is for. Go into Fork.

[00:36:35] Matt Cromwell: It's called fork.

[00:36:36] Joost de Valk: Yeah, no, whatever you want to call it. Copy, steal, as long as you modify and fix it and do it towards your own needs.

[00:36:44] I think you really need to look at what others are doing and, and, and, well, just pick those that you think are very useful. And there is a lot of different implementations of this out there. Um, And you can just, well, you can copy, paste, modify to your own needs. You can look at all the different versions of it.

[00:37:04] You can go from fairly simple, such as what I, uh, we have in fewer tags, which I mentioned earlier. I'll drop a link. Uh, I don't know if you do show notes, but don't, don't want those, um, to a full blown implementation like Yoast CS, which is basically a layer on top of WPCS, which, which adds even more of their own rules and does more things.

[00:37:27] You can go. So you can go as, as weird as you want with this, but I'd start simple and then work on from that.

[00:37:34] Matt Cromwell: Nice one.

[00:37:35] Zack Katz: Zach, what about you? Uh, name all your functions using emoji. That is, do

[00:37:45] Matt Cromwell: we call anti advice?

[00:37:48] Zack Katz: No, that's not my, it's a day late for that joke. It's April 2nd. Um, Uh, mine is to ask for help.

[00:37:55] So, you know, says steal, that's going to get you, uh, to the point where you have the code on your computer or you have it in your repo, that doesn't mean it's going to work, it might not. Uh, my computer set up, uh, like, I don't know why, but my terminal just like doesn't work the way others, other people's works and it requires a lot of.

[00:38:17] Um, a lot of hacks sometimes to get it working. Ask for help. Uh, Danielizer of content control helped walk me through some problems I was having recently. Uh, it's really helpful when somebody just handholds you and says like, here's what to do now, this'll probably get you running. Uh, that's the beauty of the WordPress community.

[00:38:37] In addition to open source, like you can steal it and then WordPress community, uh, you can ask for help and people are generally very helpful with their time.

[00:38:45] Matt Cromwell: Nice. Absolutely. Daniel's such a helpful person. Uh, yeah. So many helpful folks in WordPress. Um, I'm going to be a little contrarian. I'm going to say don't do it.

[00:38:56] Don't do it when you're young and just starting out, like ship, like get things going, I'll give it a caveat because I do agree with Yost. That like, you can take it slow also. I, I think being like consistent and making sure that your code is documented well, so that others can jump in and, and understand and start coding quickly.

[00:39:16] Um, and especially, I'm just saying like, don't do it if it's going to like, hold you up, if it's going to slow you down so much that you're like, so anxious about shipping, it's like shipping is more important. Um, cause I do think it'll, it'll like. It'll come, you know, so that's the coding

[00:39:32] Zack Katz: standards part, but there's also the, like you also saying the security part and the best practices part, the public, the plugin check plugin is a great way to not have to know how to do anything and still get some of these benefits where you install it and you say, run this on my code.

[00:39:48] Uh, even if you don't know how to install. You know, composer, for example, or like, you know, get the, the build process up and running, uh, having the security checks, even if, especially when you're just getting started, I think is an important,

[00:40:01] Matt Cromwell: I think, I think there's so many folks out there who hear this whole subject and it's just daunting and it makes them scared and it makes them worried.

[00:40:08] And I just want to be that voice that just, just is like, it's okay. Like, but it's also not.

[00:40:17] Joost de Valk: So I, to a degree, I actually agree with you and Matt in, in saying, Hey, maybe don't start with this, but at the same time, I remember what I needed to do when I hired our first developer back in the day, and this is far too long ago.

[00:40:33] Um, I had to go in and, and document my entire code base because I hadn't done it before.

[00:40:40] Matt Cromwell: Yeah.

[00:40:42] Joost de Valk: And that is not a fun job. It took me two and a half weeks to go through every function and document it. But I did it because I knew like, if I'm not going to do this and nobody's going to ever understand how this all works

[00:40:54] Matt Cromwell: and

[00:40:56] Joost de Valk: it's easier to do that from the beginning and it, it feels like a bit of extra work, but it's not like in all fairness, if you get used to it, it doesn't really add that much time and it does save you from having annoying security issues.

[00:41:09] Zack Katz: Yeah. So here's the, here's the. Possibility. And this is not a good idea at all.

[00:41:14] Matt Cromwell: More anti advice. I love more anti

[00:41:16] Zack Katz: advice. You could submit a plugin to the dot order repo and they will run coding standards for you and tell you all the things that are wrong with your plugin.

[00:41:27] Joost de Valk: Oh my God. I think they've automated that too now.

[00:41:28] That's why we have the PHP plugin check thing.

[00:41:32] Matt Cromwell: Yeah, they reach out about the, they do scans and it's like, it's just a scan. It's not like they're going in like nitpicking on plugins. They're scanning stuff and they're like, this wasn't escaped properly. And like, just basically bulk scanning plugins, you know, It's a good indicator

[00:41:46] Zack Katz: for whether or not your plugin is ready for prime time.

[00:41:51] And if you don't pass the coding standards, security parts, especially, You shouldn't release your plugin, even if it's an MVP, don't do it. Fix those things first. You really should run this stuff before you put code out there.

[00:42:04] Matt Cromwell: Yes, I, I do agree. Technically. Um, I just want to also be like shipping.

[00:42:12] Joost de Valk: I agree.

[00:42:13] But shipping, shipping a product that has security issues is a good way to stifle your growth forever. Oh,

[00:42:19] Matt Cromwell: absolutely. Yeah. Nobody likes being able to be like, Oh crap, I just am getting my feet underneath me and now, uh, nobody trusts me anymore. Like that's not. What success looks like at all.

[00:42:30] Joost de Valk: I see that Katie is suggesting a new section for the, for the show in the future, and I have plenty to add to that section, that

[00:42:41] Zack Katz: would be a fun episode.

[00:42:42] I would love that worst advice. I'll be, I'll be there for that one.

[00:42:47] Matt Cromwell: We do put in, put in backdoors that like circumvent SSL and ship it. I would

[00:42:53] Joost de Valk: say adding an app, adding a banner to your admin on black Friday is one of those. Well, that's a good conversation to have, isn't it? From experience,

[00:43:03] Matt Cromwell: is that what you're saying?

[00:43:08] Yeah, well, it feels like the show just started. We can talk for a whole nother 45 minutes on this, but we

[00:43:14] Joost de Valk: could, if it were, since it wasn't so late in Europe,

[00:43:19] Matt Cromwell: but this was, this has been really great. You also, I really appreciate you coming on and especially talking about a subject that not a lot of folks have a lot of exposure to, um, uh, especially at scale.

[00:43:30] So thank you so much. And just tell the world, um, where can they find you? What's the best place to get ahold of you?

[00:43:36] Joost de Valk: Um, they can find me on post status in, in, uh, in the club room there. And, uh, well, I'll, I'll happily talk to you there. You can even DM me there on the WordPress slack or on Twitter or, uh, at Jadavalk on Yoast.

[00:43:51] blog. And if you can't guess my email address, then you should not be allowed to email me.

[00:43:58] Zack Katz: Nice. All right. Well, uh, thanks again and tune in next week for our talk with Jason Cohen. As we talk about finding product market fit important for every single product owner out there.

[00:44:10] Matt Cromwell: Absolutely. Thanks again to post status as our green room.

[00:44:14] Uh, if you're enjoying these shows, of course, we love it. If you would subscribe and like, and do all the things that make YouTube work, uh, especially for us. And most importantly, we'll see you next week. Thanks, everybody.

Related Episodes