 Okay, welcome folks. Sorry that I'm a few minutes late. I've been having some technical problems with my setup this week. Because I basically because I installed a few new pieces of hardware. Over the course of the last weeks. And that has caused me to have some, some hardware related problems and conflicts and very other things. I apologize for the delay. I'm just going to go off camera quickly and get something. And then we can get started. And in case you're wondering that thing that I'm getting is my cup of coffee. My workshop coffee. All right. So I apologize for the delay again. I certainly have this big light next to my desk. I have a desk lamp setup that hopefully will illuminate my face a bit better. And I've also changed my camera. So I'm hoping that a camera view is a bit clearer for you all. Hopefully you can see my face a bit better. I've got some things now that allow me to move myself around on the screen. So you might notice my face is moving. So Adrian says coffee is the lifeblood of web development. You're absolutely correct. Unfortunately, so. Okay. So today we are going to be looking at getting plugins ready for PHP. But while you are joining, please do let us know in the chat where you're joining us from. I see Anne is joining from Portland, Oregon. And then while you're doing that, if you would like to code along with me for the coding portion of today's session. There is a plugin that you can download from this GitHub repository. I do have it installed on my local install. So I will go through the code with you before we get going. But if you want to install it yourself, you're more welcome to. Also, before we get started, I didn't mention this in the meetup comment section yesterday. Part of this workshop we're going to be using or at least I'm going to be using composer. Composer is a package manager for PHP. It is the PHP equivalent of something like npm for JavaScript or Ruby gems for Ruby development. But it does have a slightly steep learning curve and setup curve. If you've never used it before. So while I would have liked us to have been able to actually sit and install composer in this workshop today. It's not really something we have time for. I am planning on doing a session in the future about setting up things like poser and npm and those things. But because it is a command line tool, it requires a different set of steps on windows versus if you're on a Mac versus if you're on Linux. So what you have to do in the future is a specific session of each one of those operating systems. I'll do one for windows and we'll go through the process of setting it up and help folks to get it set up and working. One for a macOS environments and how it works there and one for a Linux environment, probably a Brindu. And I expect it to be less for the Brindu workshop. Probably less people for the Brindu workshop than for the other two. So if you are here today and you're watching and you don't have composer installed, I can recommend that you watch what I do. And then when you have time of the session, work out, you know, work on getting a poser installed if you wanted that route. But I am also going to present a way to test plugins without using composer. Using the two together is a good combination using one or the other is an option as well. But I just want to mention that before we get going. So we've got running through the folks in the channel. We've got and who I mentioned, Oregon. We've got PC. Diego from Vancouver, Canada. Welcome. Adrian from Anaheim, California, home of Disneyland. We've got Kaiser from Darker Bangladesh, John from Chicago, creative mouse studio from Galveston, Texas. So Bob from, I'm going to mess this up, I'm going to do my best. Chandira, I think, Chandigarh, India. And then PCCampus is no job in the country. Chandigarh. Cool. Okay, thank you. Yeah, I'm terrible with non-English names and places. So thank you for clarifying that, so Bob. CP Web Designs Chuck from San Antonio, Texas. Welcome. Glad to have everybody here from all over the world. If you don't know me, if you've never met me before, my name is Jonathan. I come from Cape Town in South Africa. I have a little bit of a nasal thing going on. I'm recovering from a bit of a cold. I had to reschedule this workshop because I just wasn't feeling up to presenting. So I apologize if I have to perhaps blow my nose off. I'll do my best to do it offscreen and mute my mic if I have to do that. But I am on the tail end of it. So hopefully less of a chance of that happening. All right. So today, originally when I posted this workshop, I had called it testing plugins for PHP 8 compatibility. But really it's just testing plugins for any future version of PHP compatibility. This is a practice and a process that if you're building anything for WordPress that uses PHP, you should be doing regularly. It should ideally be something that is part of your process. Getting to know where to find information about new PHP versions and what's coming and what's being removed is a good thing to do as well. So chat about that a little bit. The focus at the moment right now is on PHP 8 because PHP 8 is the newest version of PHP. And there's a little bit of history around why PHP 8 is causing folks in the WordPress space and problems. Before we get going, a few announcements. I have said this already, but welcome everybody, thank you for joining. If you can't see my shared screen. So right now my screen is shared and you should be able to see this announcement slide with the title of announcements on the top. If you can't see it, please let me know either in the chat or using using your mic. And I can just re-enable the screen share and make sure that you can see it. So if you can't ever see what's on screen and you just see my face, then please know. As always, we are presenting in focus mode, but please feel free to enable your video if you would like to. I don't have a co-host with me today, just because I forgot to ask for a co-host. So it'll basically just be me being able to see all of you, but you won't be able to see each other. You're always welcome to ask questions. You're welcome to post your questions in the chat or unmute to ask questions. The only thing that I do ask is unless your question is specifically related to what we're doing on screen, please keep them for the sort of breaks where I leave breaks for questions if unrelated to what we're doing. If it's related to what we're doing, if you're not understanding something that I'm presenting or something that I'm talking about, you're welcome to ask the question. Just shout out my name and I'll stop and we can chat about your question. I will do my best to keep an eye on the chat and make sure that I follow up on any questions that come along there. Alright, then as I mentioned earlier, if you would like to code along with me for the coding portion of this workshop, you can grab the plug-in from this download and install it on your local WordPress installation. If I am going too fast, please send me down. I do tend to get very speed in my talking. So if I do speed up too much, let me know and I will slow down. And I also leave that note there for myself to remind myself to slow down before I get into the workshop itself. And then finally we will be posting this to WordPress TV afterwards. So Adrian, you're probably finding if you click on the link it's extracting the PHP code if you're on a Mac it might be extracting the code ideally get the zip download. And then you'll just be able to install it that way. But otherwise you could just put it in a folder in the plug-in folder and call it learn PHP 8, whichever one works for you. I know sometimes on a Mac environment, if it's a direct.zip link, it downloads it and then automatically extracts it and I think that's on Safari. I think if you do it on a different browser it'll just download the actual zip files somewhere on your desktop. I tend to use Brave, which is a Chrome browser. So I don't tend to see that activity. Oh yeah, and then yeah, we will be posting this to WordPress TV onwards. I usually post it on the Friday after the workshop. And as always, if you're looking for more content, you can go to learn.wordpress.org. We have tutorials there, we have courses there, we have lesson plans, we have these online workshops. And all the learning information that you might want to find or hopefully what might want to find should be available to you there. All right. Our learning outcomes for today. We're going to dive a little bit into the history of WordPress and PHP 8 specifically, and also a little bit of the history around WordPress, sorry, around PHP's developments, life cycles, and kind of why PHP 8 has caused some problems. And where you can find information about PHP versions. So where you go to look, how to sort of read the updates and understand them. And then we're going to look at two ways of testing your plugins. We're going to use the plugin that I've given you as an example today to do the testing. We're going to look at a manual testing process, which is the, I would say, easier but more prone to missing things, way of doing things. And then we're going to look at an automated way of doing it. There are a lot of automated ways that I will share with you later on in the workshop, but I want to just focus on one today and talk about pros and cons of both, both processes. Okay, any questions on anything before we get started. I'm going to grab a sip of coffee and leave it open if anybody has any questions otherwise we will dive into the history of WordPress and PHP 8 coffee is super fresh. All right. This link in the slide is the make word or core blog post that related to PHP 8 specifically. I'm going to open it up in my browser and I'm going to share the link with you in the chat as well if you would like to open it up. This is on November the 23rd 2020 so that was two and a half years ago. And this was when PHP 8 was in the final stages of its release cycle. You'll see this ball text in the middle here WordPress core aims to be compatible with PHP 8 5.6 release currently scheduled for December 8 2020. They also mentioned that PHP 8 is a major version update with a large number of changes that break back with compatibility and many features that were deprecated within the PHP 7 feature release cycle. So in this blog post if we scroll down a little bit. They talk about the state of PHP support within the border ecosystem plugins themes etc is impossible to know in other words WordPress core can focus on its code and make sure that it is compatible with PHP 8 8.0 8.1 8.2 so on and so forth. But it can't control the plugins or themes. So at this point in time WordPress 5.6 was considered to be beta compatible with PHP. In other words you could install WordPress 5.6 on a server running PHP 8 and WordPress itself would work and be fine, but nobody knew whether you would have any problems with any plugins. Since then, and this was in November as I said November 2020. Since then PHP 8.1 has come out 8.2 has come out and I think 8.3 years out as well and it's in development I can't remember right now. And that included more breaking changes. So there are a couple of open tickets specifically around PHP 8 development and if you go to the bottom of this blog. This post should I say right down the bottom here there is a link which links you through to track. And it has the full list of PHP 8 this is quite a long blog post. So I'm going to find it at the bottom here. Here we go a full list of tickets related to PHP 8 support. If we open that up and I'll share that with you in the chat as well. You will see that there are a bunch of tickets listed. You'll see that under the status column, most of these are closed. And there are specific to specific milestones all the 5.6 ones are closed 5.6.1 was closed and this is WordPress releases. But as we scroll down, we'll see that here around 6.2.1 6.3. There are now some open and assigned issues that folks are working on. Most of these bags are specific to 8.1 and 8.2 because there was some changes in 8.1 8.2 that caused issues. But they are sort of being worked on internally by a team. And the goal is to get WordPress up to date with the latest release of PHP as quickly as possible. Now, we might wonder, well, why did WordPress kind of fall behind a little bit that came to keeping up to date with versions of PHP? And to understand that, you need to have a look at the PHP release history, which the easiest sort of graphic that I find for this is on Wikipedia, funnily enough. So in the Wikipedia article about PHP, there is this release history table. And if we have a look at PHP 5.0, that was released on the 13th of July 2004, and it had support up until the 5th of December 2005. It's about normal to have about a year of support for any given version of PHP. But you'll notice that PHP 4.0 before it was released in 2000. And the last version, which was 4.4, was released in 2005 and support 4.4 ended in 2008. But between 2000 and 2008, that's an 8-year gap, PHP 4.0 or some version of PHP 4.0 was available. Then PHP 5.0 came along. And it ran from 2004, which was when PHP 5.0 came out, to 2018, which was when PHP 5.6 support ended. So PHP 5.0 was around for a long time, effectively 14 years worth of PHP 5.0. And it was a time in the PHP's life where there was this sort of massively long-extended life of a specific major version. One of the reasons for that is the PHP 6.0 version, which was never released. And I'm not going to dive into what happened there or why it was never released. But a lot of the features that were supposed to come out in PHP 6.0 got added to the later versions of PHP 5.0. So PHP 5.0 should have probably only had four major releases. It should have gone 5.0, 5.1, 5.2, 5.3, 5.4. And then PHP 6.0 should have come out and 6.0 should have had a 1, 2, 3, and maybe a 4.0. So that happened, PHP 5.6 went all the way to 5.6 and also noticed that 5.6 was released in 2014, but support only ended in 2018. So 5.6 as a version had four years of support. So it was a very extended lifecycle of this version 5. And folks kind of got used to that. Then PHP 7.0 came out and PHP 7.0 went back to what it should be. Now in 2011, you can go and find the RFC for this on the PHP website. In 2011, the PHP developers decided to stick to formalize their release cycle and stick to having, I think it works out to a total of three years of support per release. So your first two years were what's known as active support. So bags and security features will be fixed. And then your third year is security support only. So only security features will be fixed. And during that three-year cycle, the next version will be worked on. And then by the sort of halfway through that cycle roughly or sometime in that cycle, the new version would come out and they would move forward from there. And so because that decision was made in this big five release lifecycle, it only got implemented at version 7. So at version 7, you'll see the lifespan of a specific version is again much shorter. So version 7.0 was 2015 to 2019. 7.1 was 2016 to 2019. 7.2 was 2017 to 2020. So we're sticking to this roughly three-year timeframe. But because PHP 5 had been around for so long, folks kind of got almost lazy in going, we don't have to worry too much about version changes because it's not going to change anytime soon. When 7 happened, a lot of developers kind of expected it to continue the way it had at 5.6 didn't keep up to date with what was happening in the PHP ecosystem. And so when PHP 7.0, when support ended in 2019, folks kind of went, oh, there is this serious recycle now that they're sticking to that we need to be made aware of. The other thing that happened, and this is specifically between 7.4, 8 and 8.1, was the PHP developers decided to remove a lot of things that they thought were no good anymore. They decided it was time to, excuse me, stop being able to support things so far back in time, and have a hard deadline on we're going to deprecate things in this version deprecate means warn folks to stop using it. And then the next version after the deprecated version, it'll then be removed. And this also caught a lot of people by surprise because a lot of functionality that existed in PHP 4 and PHP 5 that was still supported in PHP 7 suddenly went away in PHP, because folks weren't keeping up to date with the changes that were happening. So the good news out of all of that is that we can now safely assume that this is the way PHP development is going to continue. We need to be more aware of these changes as developers, we need to keep up to date with the changes that are happening, and we need to find the tools to be able to keep ourselves up to date and make sure we're not using this old code. Okay, any questions around hopefully that very brief and not too boring history of HP versions and how to fix us as WordPress developers. Otherwise we will continue on. Okay. I don't see any questions. So the I'm going to come back to this link a little bit later, but I want to show you the PHP manuals appendices location. It's this URL over here. It is basically a list of any additional information about the PHP project that you might need. It includes the history of PHP. And then right after the history of PHP starts including all the migration guides. So for every if you scroll down this page for every single version upgrade of PHP, there is a migration guide. So it goes all the way back to where is it now? Here we go. All the way back to make writing from 5.5 to 5.6. And then it goes from there. 5.5 to 5.6 is run about the time they decided on sticking to this very specific release cycle. So if we jump, I'm going to go straight to the 7.4 to 8.0 migration guide. I'll share the link with you in the chat if you want to open that up. You'll see it has four main sections. It has new features, backward incompatible changes, breaking changes, deprecated features. In other words, features that are going to be removed in a future version of PHP. So be aware of them. They're going to be changed soon. And then the other changes. So your new features obviously anything new that's coming to the language. Your backward incompatible changes are the ones that you need to be aware of as a PHP developer as a WordPress PHP developer. So these are the things that are being removed in this next version. So when it went from 7.4 to 8.0, these things got removed. They stopped working. They're going to break your site. And it's things like strings and under comparison changes and various other things. I'm not going to go through all of these changes. We're going to look at some of them when we look at the code in a second. But it's a good idea to keep up to date to these of these things. Then there are deprecated features. Deprecated features are features that they're going to include a deprecation notice now in this version. So that if your code is still using it, it's going to set up a warning letting you know that that's a problem. And then in a future release, it's going to be removed. So start making changes. So these are good features to keep an eye whenever a new version of PHP comes out. Have a look at the deprecated features. Have a look at see if you're doing any of those things in your code and start looking at ways to fix it. And then there are other changes which you can read through as well. But basically this is the page to be on whenever there are new PHP versions coming out. There is a mailing list that you can keep up to date with. I don't know where it is right now. I couldn't hear you. It's on the help page. So on the help page, if you click on PHP.net support, there is a mailing list area. And if you click on this list describes all the mailing lists. And you can then keep up to date with changes. And if we have a look at announcements is probably the most important one to keep up to date to. So if you subscribe to that mailing list, you will get an email whenever new versions are coming out. And that's a good way to keep up to date with what's happening and what's going on. Okay. So now that we know how to keep up to date, how do we now use this information? As I mentioned, there are two ways we can test. The one way is to test manually, which is what we're going to do next. And effectively what testing manually means is it means taking a local version of works, setting it up with the next version of PHP that's coming, or is about to be released or has been released, and then effectively running your code. Okay. Depending on your local development environment that you use, or your staging environments that your web host uses, if you develop on staging environments or whatever you use, that will determine how you switch up to the next version. So as an example, if we have a look at this first link here, which is the local WP docs. You'll see this was out when local beta 5.9.7 came out. And it was the first version of local to include PHP 8. So this would have been back whenever PHP 8 came out. And you would then be able to, if we swelled down a bit, I think there's some pictures down at the bottom here, you would then be able to, in your local WP setup for your site, you would be able to select the PHP version. It would switch a WordPress over to that version, and then you could test your plugin on that version of the site. Now, there are many ways of developing WordPress sites. There's local WP, there's DevKinster, there's LaraGon, there's MAMP, there's WAMP. There's Jamp or Champ, I think it's called. There's all these different local development environments. And if we had to do a workshop on how to change every single one of them, we'd be there probably all afternoon. So whatever you're using, if you are a plugin developer, if you're working on plugins, specifically themes, not so much because themes don't tend to be affected that badly, unless you're doing sort of advanced functionality in themes. But if you're a developer of a theme or a plugin and using some version of a local development environment, I recommend knowing and learning how to change PHP versions. There's one additional little tool I want to show you today, which is a very, very cool thing. It's brand, brand, brand new. It's called the WordPress Playground VS Code Extension. Now, I mean, I don't know why that was not the link. I wanted this link. So I will show this in the chat. So this is a project that a couple of WordPress contributors and they've spelled this right. I actually love this issue this morning in their GitHub. So it's actually this link over here. I'll share this with you in the chat as well. They've been working on a way to run WordPress in your browser. So there's this cool thing called WebAssembly, which basically allows you to run different languages in a web browser. And if you go to, for example, developer.wordpress.org slash playground, it'll actually fire up the playground. And this is a version of WordPress inside this browser instance. And you'll see it's busy preparing WordPress and it's doing its thing and eventually it'll pop up and I'll be able to then browse WordPress and two things and test things. Excuse me. And it's a very cool way of running like a local development environment without needing to install anything else. You have to have local. You don't have to have any of these others. You can just run this in your browser. At the moment the developers have been, I'm going to let this, let this finish over here. The developers have been working on a VS Code extension. So if you're using VS Code, you can run this from your VS Code setup, which I'm going to show you very quickly how it works. This is still running, so I'll switch to VS Code now. So in VS Code, there's a couple of ways you can do it. But the way I like to do it is I like to open up my WordPress install of whatever I'm testing on. And then I'll make sure that the extension is installed. And when it's installed, it pops this little WordPress playground button in your extensions in your sidebar. You click on that and you literally just click start WordPress server. It'll download whatever it needs to download off the internet. It automatically opens up your browser. And now I have this website running in my browser from my VS Code extension. I can log into the dashboard. It's logged in automatically for you as an admin user. And you will see that I've got in my, in my VS Code, so in my, in my local site, I've got this learn PHP plugin setup. And you will see if I go to the playground site, it's got the plugin installed and ready to activate automatically. Okay. It uses a SQL database, not a MySQL database. So that's basically a file based version of MySQL, which makes it a lot faster. It's perfect for testing out these kinds of things. The downside to it is because it is so brand new, there's a lot of functionality that isn't quite there yet for, for us who are developers. I've been working with the, the folks on this project. And one of the things that I logged recently was I noticed that it's not possible to view the debug log. So here's the issue over here. Sorry, not that one. That's another thing that they're working on. Here we go. So it'd be great if we could expose the debug log because when you're digging a plugin, you would like to be able to see the logs. So I'm hoping that this functionality comes to this extension soon because it's going to make it a lot more developer friendly. You'll see that also working with something called, there's a couple of packages for this, for this thing. There's something called GP now, which is a command line way of setting this up as a local development environment, which is quite exciting as well. And I can see this if, if, if, if folks can use this test to help log bugs, I can see this becoming a global universal local development environment that anybody can use on any platform without any dependencies of anything else. One thing that I do like about it going back to the local one that I've just set up is in VS code. If I go to the sidebar, I can very quickly switch PHP versions. And just say from here, I want to switch this to PHP 8 and it'll reset the sites in PHP 8.0. And then I can test on PHP 8.0. I can go back to VS code and I can say, right now I want to test on PHP 8.1 and it'll read. So it's like this cool little in browser WordPress server that just works. It's very exciting. It's very, very cool. It's not quite ready for day to day use yet, but I do recommend keeping it on the GitHub repository, keeping it on the different places. I do recommend keeping it on the GitHub repository for you in the, in the chat as well. Keep an eye on this because I think it's going to be very, very cool for those of us who are developers. All right. I'm going to switch all that off now because I need my debug log for today's today's session. So the way that I test, I'm going to just stop the server quickly. The way that I test my plugins is number one, I enable my debug log. I set the WP config for my site and I make sure that I switch WP debug to true. That's the first step. The next step is I disable WP debug display. And the reason I do this is because I don't want the errors to break the front end of the site. I just want to see whatever the front end does, but I don't want to see the errors there. Where I want the errors is in the debug log file. To make that working, I set the, sorry, what have I done here? The WP debug log in the WP config file. So WP debug log and I set that to true. All right. So what the three sets in what those three constants do is they enable debugging. In other words, start logging the errors somewhere. I default the errors are logged to the screen, which is what I don't want. You can do it if you want to, that's fine, but I prefer to do it in a log file. One of the reasons I prefer a log file is I can keep a hold of that file and I can refer back to it later. So then I set WP debug display to false so that it doesn't log into screen. The site won't break. But I set WP debug log to true so it will log it to a debug log file. The debug log file is created in the WP content directory. And it's just called d.log. You can also set a custom path for the debug log. We're not going to do that today. I'm going to do a session in the future about how to set that and how to use it and how to get some fun with it. But for today, we're just going to use the standard debug log file. And then you need to switch your WordPress version to PHP 8 or whatever the case may be and run your plugin functionality. So let's run through this plugin code to see what it does so we can start testing it. So the first thing you'll see at the top of this file, so this is the plugin code that you have possibly installed on your WordPress site. If you haven't, you're welcome to follow along. Right at the top of the plugin, there is a class, a postfetcher class. And all this postfetcher class is when it's instantiated, it gets a list of posts and it stores it to the this posts variable for the class. Then there is a fetch posts function, which effectively just uses the posts set up in the get in this posts loops through it. Checks if the post has a title value, which it should do, but just in case it doesn't check that does. And if it does, it'll echo out or at least it'll use the sprint f functionality to set up a string variable, which contains the post title. With the post link in a H4 header. That's all it's doing. So just a list of so it's cool if you're doing like a maybe a chapter thing for a book, or if you just want to list of your post title somewhere. This is what this is effectively doing. Then on the bottom here I'm registering the shortcode. The shortcode render callback is just basically setting up a new instance of the postfetcher class. And then it uses a fetch post method of the first feature class to fetch posts, build the string, return it to this post HTML variable, and then output that variable to the screen. So it's very, very simple functionality. If I put this on the front end of my site, let me show you what that looks like. So I'm going to go back to my learnprest site over here. I'm going to. Okay, this is not what I want. Hang on one sec. Okay, this thing is sorry, folks. This WordPress. So as breaking my, my local environments, I'm just going to have to clear the cache quickly. Just give me one second here. This is probably a bug that I'm going to have to let the developers know it seems that oh, hang on. I think I know what this is. It sets up this database integration. And it changes my config settings, I think to the. Yeah, it changes it to the. The sequel play around version, which I don't want. So I'm just going to revert those very quickly. So this is a bug that needs to log. That's. Okay. I'm just going to set up my thing. So database name is learn press. Yeah, so that should all work now. Let me go back to here. There we go. Okay. All right. So now things working again. So if I go into my set of plugins, there's my learn PHP plugin good to go if I go into my pages. I've already created an all posts page and it's got the learn PHP eight short code in there. So if I view this page, you will see there is I only have one post on my site. So there is the one post listed. Let's create another post just so we can see it working. So let's say. Another post. And I'm not going to give it any content for now. So we'll publish that we'll go to my pages. It was the all post page. I added that short code. And as the page, so that's all that the plugin is doing. Okay. Kaiser says is screen share visible to everyone if you're having let me let me read. Okay, so it looks like Kaiser might be having trouble with screen share. So let me fix that. I'm going to disable screen share first. Remember how that works. Yes, stop share. And then let me share again. Okay, Kaiser is working now. Can you see you should be able to see my screen says all posts. And then another post in Hello World are linked. I listed underneath that. Okay, perfect. Everybody's on the same page. All right. Excellent. Okay, so that's how the plugin works. It fetches the posts gets the list of post titles if it has a post title exports it. Sorry, puts it in the variable and then prints it on screen. So that's working. I'm running and I didn't show you this earlier because I had that issue with my WordPress versions. This version of WordPress is running PHP 7.4. And I can show you that because I've created this info dot PHP page. You'll see the top version 7.4.3.3. If you want to test that yourself, it's very easy. You can create a file called info dot PHP in the root of your WordPress install. You just give it these two lines of code. And then you call the PHP info function. I'll share this code in the chat with you all. And once you have that file, you can just browse that page. And sorry, I've got my phone doing weird things to me now. So happens you don't disable your phone sound before. And that will then will then output the versions and all the PHP information on your on that file on that page. So I'm running currently 7.4.3. I now want to test this plugin, for example, on PHP 8.0. So if I was using local WP or any one of these other ones, I would go into that site. I would find the dropdown that changes the PHP version and I would change it from 7.4 to whatever version of PHP. I don't use those tools. As I've mentioned previously, I use a custom environment that I've set up for myself. So for me to do, I need to, I run this WP local command, which basically logs into my local server. And then I edit the, the virtual host sites enabled learn press. And I basically remove the handler for running it on PHP 7.4. So I'm just going to comment that out now. I'm going to comment out these lines as well. This is not something that you would do unless you were using my same environment, which I don't recommend because I have a customized the way I do things that I'm kind of different. And then it was a different, I just, sometimes I like certain things a certain way. And then I just restart the Apache server. Especially restart. And now if I run the PHP info page, now it's running PHP 8.1. So that's how I do it on my environment. You would do whatever you would do it on your environment. Once you've done that, the best thing to then do is to run the functionality again. So in this case, if we fire off this functionality, suddenly we see this short code breaks. My this aren't there, which means something has gone wrong somewhere. So now we go and have a look at the logs. And this is why I set up the logs first before I made any changes. Because I want to make sure the logs are logging before I switch to PHP 8 or anything else. Okay, I'm going to take a break there before I have a look at the logs. I'm just coding along and they've got stuck with it. I have any questions while I have some coffee and slow myself down a bit because I'm running a little bit out of breath. And then we'll have a look at the logs and see what you can find. I'm still going to remove this. There's a video of this floating panel. Soon gives me. Yeah, so let's take a look at the logs. And let's see what the logs have told us. So in the debug log, the 17th of May ones, I was busy. The language, so we'll ignore those. So here we go. The most recent one says PHP warning for each argument must be of type. Array object null given. And it tells me, so it tells me the error. That's the most recent one. I'll look at the second. So that's the most recent warning. It says that the for each argument must be of a type array object null. It then tells me the path to the file. So it's this learn PHP 8 file. And it's online 21. It also tells me above that that there is a PHP deprecation for the array exists function. And then right at the top here, it says method. This name is the class will not be constructors. Now what you're seeing here is you're seeing the first session, the first set of logs are from when I was still running PHP 7.4. If you look at the timestamp, I'm at 440 at the moment, roughly. But at 1436, that's when we were roughly running PHP 7.4. There were some deprecations there already that were telling me things were changing. Then I switched to PHP 8. And the only thing that I got was a warning that there was a problem. Now, if I wasn't tracking these deprecations in the past, this will be the only error I'll see. And I won't know what's happening. So it's another good reason to have your debug was running when you are developing because then you will pick up any kind of possible future deprecations in the current version and be able to prepare for them. But anyway, so let's start with this warning. Before each must be of array object type. If we have a look at the code, the line is noted on line. There it is, line 21. So if I go to line 21 of my code, here it says for each of this posts. So it's saying that this post is currently null. So it can't loop over anything. So I go, okay, well, where does this post come from? This post comes here from this post fetch a method. Now, I happen to know that one of the removals that happened in PHP eight was the ability to set up like what's known as a class constructor. As the same name as the class name. And sure enough, if we go and have a look at the PHP appendices that we were looking at earlier, which I'm not going to find now because I've jumped around. So let me go back once one step. And we have a look at migrating from 7.4 PHP 8.0. And we scroll down a little bit. We will see that here. Now I'm going to find it. Let me just do a quick search constructor. There it is. There we go. Methods with the same name as the class are no longer interpreted as constructors. This is something that's been around since PHP four. It was allowed in PHP five. It was depated in one of the versions of PHP seven and nine PHP eight. It's been removed. So if I'm using it in my code, my code is going to break. And it says I need to be using the construct that instead. So what I can do now is I can copy this code. And I switch back to here and change post fischer to underscore underscore construct. And that fixes that problem. Okay. So let's run this again and see if any, if the issues go away. So let's press this page. Okay. Now there's a critical error. So I fixed one problem, but there's now another problem. And this is another reason to be logging to a debug log file. So let's go back to our debug log. Look at the most recent error. And here we go. And it says PHP. Let me minimize this a little bit. PHP fatal error. Uncore type error array key exists. Must be of type array. WP post given. And if we have a look at the deprecations from PHP seven point four, it says array key exists. Objects is deprecated. So now again, let's go and search for array key exists in that migration guide. So I'll just do a search for that. There it is. The ability to use array key exists with objects has been removed for obvious reasons because it's supposed to work on array. At some point it was allowed to run objects. And you're supposed to be using either is set or property exists. So now this is a good place to pause because this is an interesting little bit of history into how PHP has worked in the past and how it's working now. In the past, the PHP developers were very forgiving. Our folks, excuse me, using things incorrectly. So what happened with this example, I'm guessing, was that array key exists when probably existed before objects were added to PHP. Then objects oriented programming classes and things like that were added to PHP and nothing existed to be able to check if an object had a property. So folks tried using array key exists and that worked for a reason. So they're not using it. Or maybe they changed it to work like that or whatever the case was instead of creating the property exists method or function to use properly. So folks just kind of let it happen and let it be that sort of flexible. And that is almost one of the arguments that folks that developers have had against PHP is it's too flexible. It's too forgiving. It should be more strict because the problem with using something like array key exists on an object is it could create any consequences. And the more strict you are. So if you're using a property exists function, which specifically looks for an object and then a property on the object, the less chance there are of errors and problems. So with PHP seven and to a smaller degree PHP seven to a larger degree PHP eight, this idea about being more strict with how we do things has come about. So a lot of the changes that are happening are in this line of thinking. So you might find that when you start testing for PHP eight, you're going to be finding things that were actually problems in PHP seven already, but they were still allowed up until this point. Okay, just wanted to share that with you. So it's not something that you're ever going to be scared of. But since you use either a rate is set to a property exists, I'm going to use property exists. If I have a look at the property exists. Documentation. Which I will share with you. You'll see it's been around since PHP five point one seven and eight to check if the object or class has a property. The parameter first the first parameter is the object or class. The second parameter is the property. So if we go back to our code. And we look for where a key exists as being used. It's over here. So this post that is returned from the list of posts is an art. And the property we're looking for is post title. So all we have to do is swap those two parameters around when we change to this new function. So it's called property exists. I'm going to copy that out. So we'll change that to property exists. And then we'll just move the two parameters around. So we'll do post first. And then the property that we want to check for. And now we should be to go. So let's test our code again. Yeah, that's not the one I want to be on. I want to be on. Go back to my site, refresh my page. And my posts are working. I fixed all the bugs that I could find. Now is a good idea to check the debug log again and see if anything new has been logged. And in this case, we will see no, nothing new has been logged. So running on this version. This works. We're happy with it. All good. We feel like our plugin is safe and we can move on. Okay. Any questions on all of that before we move on to a more automated way. So yeah, that's fine. If you want to watch the rest of this, you can catch it on WordPress sometimes in the course of the day tomorrow. Please do go get your order from school. Very important to leave it for your kids. This is one of the reasons why I do these workshops at this time on a Thursday, because there's nothing that I have to do to fetch my kids from school on a Thursday at 4 p.m. my time. So please do go ahead. Any questions on all of that, anything that anybody didn't understand. Before we move on. Yeah. Before we move on, the other thing that I'm going to do now is I'm going to switch my site back to PHP 7.4. And I'm going to show you why I'm doing that in a second. My site's running PHP 7.4. Right. So that's the manual way. Now, the benefits of the manual way is it's easy. You don't have to install anything else. You just use your WordPress, your local environment that you're comfortable with, whatever code it is you're comfortable with. Enable, enable logging. And I would even say enable logging and then test before changing PHP versions and see if you get any deprecations or warnings then because maybe there are some issues that you're going to wear off. So enable your logging during development always. Then switch your PHP version on your local development environment. Test the functionality of your plugin. See what areas you get. Look for the problems and fix them. So that's the pro about doing it this way. The downside about doing it this way is you can only test on a per version instance. So you can't. So let's say, for example, you're testing your plugin for PHP. In my case, I was testing on 8.1. I can't test for 8.2 or 8.3. I would need to switch to 8.2 and 8.3 and run through this type of find issue, log issue, fix issue, finding issue, log issue, fix issue. That's the one thing. The other thing is my example is a very simple plugin. It's one file with one class and one short code. If you're dealing with a more complicated plugin, then you need to make sure that you're A testing all the functionality in that plugin, number one. And number two, you're also testing all functionality that may or may not be used on a regular basis. So for example, let's say a podcasting plugin. I'm using podcasting because I used to work. It was one of my jobs. I maintained a podcasting plugin for WordPress. And while the majority of the functionality was related to creating a podcast episode and setting up your file and setting up your content and all of that. Other bits of functionality were related to the RSS feed. Other bits of functionality were related to if you were hosting with a certain podcast host. Other bits of functionality were related to your stats, which are less easy to test because it's related on people hitting your websites and listening to your podcast. So you have to have a whole range of sort of manual tests that you have to go through to this functionality. One surefire way to work around that is making sure that there are automated tests for all of your bits of functionality. That's a whole other workshop. So there's this other thing that you can do and it's called PHP Compatibility. So PHP Compatibility is this compatibility check for a tool called PHP Code Sniffer. PHP Code Sniffer is a command line tool that you can install on your Mac, Linux, or Windows command line that you can run against your entire code base and it'll do various checks and lints and whatever else. It's primarily used to do WordPress Coding Standards checks. So if you're the kind of person that wants to follow the WordPress Coding Standards, you can run PHP, it's known as PHPCS, so PHP Code Sniffer, with the WordPress Coding Standards WPCS installed and it'll automatically check all your plugin files and it'll notify you if there are any coding standards violations. What PHP Compatibility does is it allows you to check your code against future PHP versions, which is very, very cool because it means I run through all of my PHP code and I can test it against all of the possible PHP versions that are coming and find if there are any problems. So I want to show you how this works. If you don't have Composer installed, you're just going to have to follow along and make your latest stage. If you do have Composer installed, you're welcome to join me on this journey. But basically what it looks like is this. Inside of, so let me exit out of here and go to my site. Wplearn.hpx and I'm going to just clear the screen so we can all see what's happening here. Once I've got Composer installed, I'm going to, before we do that, I want to just share the Composer links with everybody. So this is Composer itself. If you want to install it, you click on the Getting Started link and there is the installation for Linux Unix and Mac OS and there is the installation options for Windows. There's also a Docker image. If you're using Docker, then you can run Composer in the Docker image and then there's some information on how Composer works. So that's the Composer information there. PHP compatibility. I'm going to share that link with you as well. This is basically the package in GitHub that includes information on how it uses and how it works. Okay, so to install these things once you have Composer installed is a couple of commands, which I'm going to find very quickly for you. I will share them in the chat as we go along. The first thing you will need to do is you'll need to make sure that Composer is installed and working so you can run Composer v minus v and that tells you information about Composer. And then inside of your package, you simply run Composer init. Now what that does is that initializes the plugin to use Composer. It will create a Composer package file with various information and it picks up things like the package name based on the folder structure and various other things and the GitHub repositories and all of that. So I'm going to share these things you can just accept. So the package name I'm going to accept as is. I'm not going to worry about the description right now. I'm going to leave the author as is. I'm not going to worry about minimum stability. I'm not going to worry about package type. License, I'm just going to put GPL. Again, that doesn't matter too much. Then I'm not going to define my dependencies because I don't need to do that now. Sorry, no. And I'm also not going to define my dev dependencies. So I'm going to say no to that. I'm just going to skip the auto loading unless you want to use auto loading, but I'm going to skip it. That's a whole different workshop. Then it'll just check and say, are you wanting to generate this? And I'm going to go yes. And it says, do you want to add the vendor directory to get ignore? If you're using get, you can say yes or no to that. It doesn't matter either way or our purposes. And that's all that's needed to set this all up. And what this will do is this will create a, let's close this down. Inside of your plugin directory, it will create the composer file, which is you saw that code on screen earlier. So it was just that code in there. It also creates a get ignore and it just adds the vendor to the get ignore if you're using it. And that's all that that does. So now we can use composer within this plugin. It's set up. It knows what it needs to do on the ring rock and roll. The next thing you do is you require the PHP compatibility package. And you do that by running following command. I'm going to pause there for a second. And Adrian says random to anyone on a Mac. I found that with the latest OS for Mac, there isn't PHP. So that needs to be installed first. Yes, correct. Which I haven't researched yet before you can install composer. That's 100% correct Adrian. The easiest way to do that is using homebrew, which is what I'm using. So if you're on a Mac, that was something I had to learn when I switched to Mac when I joined what's a magic a year ago, because I used to be a Linux guy, but you have the quickest ways to install homebrew and then install PHP with homebrew. And what I do is I generally have my custom development environment set up for my sites. I run the stable version of PHP on my Mac in the command line. It's currently, it's from 7.4. Let me just check that by going PHP minus V. Yeah, currently it's running 7.4. I could probably update it to 8.0 now because WordPress is stable on 8.0. I just haven't got around to it yet. Okay. So the commands are running. I'm going to share this in the chat, but I don't want to chat with you about it as well before we run it. The monitor run is this. So let's just clear this out. And the meeting roles. And this is the composer require dash dash. It's a dev dependency. Dev dependency means it doesn't get packaged with the main plugin. We're only using it during development. And then you use the PHP compatibility name, but then you specify the dev developed version. Now the reason for this, the PHP compatibility package, which I have now closed down. So let me close some of these things. And let's, oh, here we go. Doesn't have a main or trunk branch that is very, very active right now. The branch that is the most active is the telep branch. You'll see that the last official version of PHP compatibility was released in December 27, 2019. So that is almost three years old now. That was before PHP eight came out, but you'll see that four days ago, somebody merged effects to develop, which updated something. So currently the develop version of PHP compatibility is the one to use. And that's why when you install it, you specify the dev develop branch in the name. When you install that, it's going to go and install any other dependencies that might need. So it involves this PHP code sniffer composer installer. It installs PHP compatibility. It installs PHP CS utils and PHP code sniffer for you, which is great. And the last thing it says is, do you trust this PHP composer installer, which I do. So I'm just going to say yes to that. It is a trust with the package. So we can trust it. And what that does is that allows you to install PHP utils and PHP compatibility. This is now installed, but we would also like to install the WordPress coding standards to this project. So it uses the coding standards for WordPress for our plugin. This is not a hard requirement, but if you're using the WordPress coding standards, I do recommend it. So to do that, you run the following command, which I will share in the chat and also on screen. So it is composer require dash dash dev WP hyphen coding hyphen standards slash WPCS. So that is the WPCS package. You install that and I will install all that for you. Once that's all done, now you can start running PHP compatibility. Is there anybody who is busy doing this and needs me to wait a little bit? Because I know once you install it the first time, it's a lot quicker. That's why it's quick for me. So is anybody doing this and needs me to wait? I will wait for a few seconds. Otherwise, if everybody's happy for me to continue and show you how this works, I'll do so once I've taken a break. Okay. The other thing I need to do to make sure that this test works is I need to revert this code so that we have some errors in this. So let me do that quickly. Creators says awesome information. Have another meeting. So I hope I will catch everything on the replay. Perfect. That's no problem. Adrian says personally, this is above my pay grade. That's fine. That's totally fine. If all I do is just share the knowledge with you and you know it's there for when you're ready for it. That's perfect. So that's just too much. Cool. All right. Now here's what I think is the fun part. With this all installed. All I need to do is run the following command. And it will give me the same information that I got doing the manual test without having to do the manual test. So the command is that I've shared it in the chat. I'm going to paste it on screen and talk you through it. So I'm running the PHP CS, which is installed inside the vendor bin directly inside of my plugin. This was installed when I set up these packages. I'll show you quickly. Right using composer creates this vendor folder and inside of vendor is all the packages that are going to be used. So I'm running the PHP CS executable. I run it with a dash P and the path and I can basically set it to the whole, the whole directory or I can set it to specific files. I'm using the specific file for now, just so that I can just focus on that file. And then I just use this dash dash standard equals PHP compatibility. That's all I have to use. Now remember I'm running. Let me just confirm that with you. I'm running the site on PHP 7.4. So I don't have any way of actually physically testing these problems. But if I run PHP compatibility, it tells me straight away declaration. And this is even more useful. Declaration of a PHP 4 style class constructor is deprecated since PHP 7.0 and removed since PHP 8.0. So it warns me that this change is happening in PHP 8 and I need to fix this. It also tells me about the PHP 4 style class constructor. So it's giving me more information. It tells me it's on line 15, which is useful. It's an error in this plugin file. Notice however, that it doesn't tell doesn't warn me about the array key exist issue. And I'll show you why that is in a second. But this tells us, okay, cool. The class constructor is a problem. So we go and do the same amount of research. And now we can fix our code. We didn't have to run anything. We didn't have to change PHP versions. And it's a lot quicker as well. When when done this way. So let's fix the constructor in the same way we did previously. So using the dash dash underscore construct keyword. And if we again, we will see that now it tells us 100% no problems. So that's a bit of a problem because we know about that array key exist issue. And this is the downside to PHP compatibility. So let me, let me share another link with you. Let me find it quickly. I'm going to pop it in my notes here. It's not in my notes. I do apologize. I've got it in my other notes. I'll share it with you now. And I pop it in the chat. I'm also going to add it to my resources at the end of the slide. It'll update the slides. And I'll open it up over here. It's issue 808 of the PHP compatibility package. And you will see that. Jet. Who is one of the maintainers of this project. She's noticed that this is an issue to keep track of the implemented RTS for PHP 7.4. And if we scroll down to the bottom here deprecations 7.4 array key exists within objects. So that hasn't been implemented yet into PHP compatibility. So this is why I'm showing you both tools because using PHP compatibility currently will get you so far. It'll find a lot of the issues. It'll do it in an automated very, very quick way. It'll do it without you having to switch PHP versions. However, because it is an open source project, because it is reliant on contributors contributing fixes to it, there may be some things missing. So that's where the manual testing also will help. So the answer is can do one or the other. The answer actually is you should really be doing both. And there are other things that you could be doing as well. But hopefully I've shown you that the compatibility method, if there were a lot more issues, it could pick up. We could fix all those issues without having to change PHP versions and switch things around and manually refresh. And it'll scan your entire code base without having to physically update and fix that functionality. Cool. Any questions on PHP compatibility, how to set it up, how it's used, or anything around that before I want to show you a few more things before we wrap up for the day. OK. They don't seem to have any questions. So I'm going to wrap up today's session with an article. I'm not trying to blow my horn here. But this is an article that I wrote on November the 25th, 2020 for WPTab. Specifically titled getting your WordPress plugins and themes ready for PHP 8. And in this article, I spoke to Juliet, who I mentioned earlier. She is the maintainer of the WordPress coding standards for PHP code sniffer. She's also one of the maintainers for the PHP compatibility plugin. She also was sponsored to write on the developer.yos.com blog, an article on the 2020, it's called the 2020 WordPress and PHP 8 compatibility report, where she details a lot of the things that were happening in 2020 with the changes in PHP. I do recommend reading that as well. In this post, we covered PHP compatibility, but we also covered additional things that you could do. And so the best way to think about this process is you can use something called PHP, which does require you to switch to a PHP version. There's also a package called PHP parallel and basically is a linter on your PHP code. Then you can run as we showed you PHP compatibility. And here it's mentioned that you must use the dev develop branch. At this point in 2020 10.0.0 hadn't been released and it hasn't still been released. So if there are any developers out there want to help get that package to 10.0, please do let them know. Then if you have unit tests and integration tests for your plugin or theme, run those. If you don't, start thinking about adding them, because unit tests and integration tests are basically automated ways of what we did right up front. So right up front, we physically click buttons. We physically tested functionality. Unit tests and integration tests are automated ways, automated way of doing that. I am adding a session on how unit tests work and how integration tests work. So I do recommend getting those as well. Then there are the WordPress unit tests and the WordPress end-to-end tests that you can run. They require you to have the unit testing and end-to-end testing set up on your local environment, but you can run as well. And then you can do things like checking whether the strict coverage of your test is enough. And if not, then the last one is to test things manually. The important thing that I want to mention in this list is Juliette mentions the unhappy parts. Unhappy parts are what if the plugin code works, but it doesn't work the way you expect to use it. So let me give you an example. The happy part of this plugin code, and we're going to talk about this when we talk about testing in that workshop. The happy part of this plugin code is the shortcode fires. It sets up the class. It sets up the posts. It loops through the posts. Every post has a title. It gets the title and puts the title into the string and outputs the string onto the screen. That's the happy part. Now, at each one of those steps, things could go wrong. The first thing that can go wrong is WordPress core removes support for short codes in your template files, which if anybody's been following the WordPress news over the last couple of days, there was a bit of a brouhaha around WordPress 6.2.1 and that specific problem. So that's the first thing you might want to think about testing on. The shortcode doesn't work for some reason. The second one you might want to think about testing is what if the class doesn't instantiate? What if the post fetcher over here at this point returns false or not? Then what? Then what if get posts fails for some reason? What if the post doesn't have a post title? What then? And those are all the unhappy parts. So when you're manually testing your plugin, most folks just test that, oh, this does what it should do. Most folks don't think about, well, what happens if it doesn't do what it should be and how do I test that when I'm testing manually? So it's a great article to read even today. I do recommend if you're maintaining any kind of plugins out there in the WordPress ecosystem that you go through this document and read through it. My recommendation is what we covered today. Make sure you're at least doing PHP compatibility, combination of PHP compatibility and manual testing. If you do those two regularly, you should catch most issues. You might still miss a couple of edge cases, but those edge cases will hopefully come out in the wash either through support of your plugin or through customers using it. And at least then it's only a small percentage versus the entire 100% of any PHP compatibility issues. And last but not least, make this part of your process. The great thing about running PHP compatibility and running unit tests and those kind of things is you can run it when your code is committed to your GitHub or your SVN or whatever repository. You can make it an automated process on your local environment. Make testing for these compatibility issues part of your process because now we understand how PHP is being developed and how it's changing. Keep an eye on those updates and announcements for new versions come out. Unfortunately, it's one of those things where because of the way the PHP world is changing, because of the way it's moving forward, it has part of effects, meaning PHP gets a better, what's the word I'm looking for, better name in the developer community because it's stricter and it's more focused. The downside is it affects those of us who have been doing things sort of the old way, but the more you can keep your code up to date and the more you can keep up to date with the PHP versions, the more secure your customer site is running the newer versions of PHP and the faster your plugins will run and the more effectively they will run. So I do recommend reading this article and at least implementing the two that we've covered today, the PHP compatibility tests and the manual testing in your plugins and themes as you develop them. Okay, Stuart says the WP Tavern link in the chat. I'll copy paste that now. Kaiser says as a developer, I'm going to go through those questions. Should I use try catch more to handle such problems? Okay, so the answer to my again, my personal answer. This is not necessarily an official WordPress stance. This is Jonathan Bosner's opinion is try catch should only be used when you are dealing with something that is out of your control. So when you're trying to do an API request, when you're trying to use a third party service and you have no control over what response you're going to get. Or you're going to be doing something that could go wrong because you don't have control over it. I wouldn't be using try catches to try and prevent fatal error and deprecation issues. I would try and fix that problem because if it is deprecated and it has a breaking a backward incompatible breaking change, there is an updated version of this. Remember, the more you try catch, the more code is being executed. So for example, if you're using try catch to fix like that array key exists around, you could just fix it by fixing the bug. So I wouldn't use it for that. I would use it for things that I have no control over. Can you suggest what to follow to know about standard practices for development specific to WordPress? There are a couple of places that I can recommend. These are not specific to WordPress itself. WordPress doesn't have a like WordPress, the open source project doesn't have a very specific developer best practices way of doing things. What it does have is a coding standard which I can recommend. It does have the WordPress developer documentation which talks about how to develop plugins develop themes. Those are about the best in terms of standard practices. Alternatively, and I think I have shared these in a previous previous workshop but companies like human made companies like 10 up you can see I've searched for these before and companies like XWP have all got their own not going to find it now their own engineering best practice. I recommend reading through those and understanding how those work. Another one you could try. Let me just see if I can fix one that's probably in here somewhere. I'll share these links in the chat. Here we go. There's the XWP best practice. Looks like they've moved it to here. Okay. We'll leave that one. So here's the human made one. These are all WordPress VIP agencies that are very similar. Well, here's the 10 up one as well. I'm busy doing that now. There's the old XWP one. I don't know where they've changed it to. They've moved it somewhere. I'm not sure it is not. It might be on their site somewhere and then WordPress VIP also has an engineering best practices. I think it's engineering handbook. You will see that's a lot of them are the same. I think it's here. Yeah, this is basically it. A lot of it is the same. A little bits and pieces here and they are slightly different. I recommend reading them and then finding what works for you. Obviously, if you're working for those companies, you'll follow those practices. What I'm actually trying to do within Learn WordPress right now is kind of codify the WordPress.org official practices. So looking at what does WordPress recommend and kind of putting them together into courses and tutorials. But WordPress itself, besides the developer documentation, besides the plug-in handbook and the theme handbook, which I'll share with you now, those are about the sort of best practice documentation that you can have for those two in terms of how to do things. You will notice that theme and plug-in handbooks are not as prescriptive as the VIP agency handbooks. But you won't go wrong. I think it was I can't remember which way it worked, but one of these companies released their best practices and then the others forked the original one and tweaked it slightly for theirs. So you'll see a lot of it is very, very similar. I think it was 10-up that released this first and then I think XWP and HumanMade forked the 10-up ones and then changed it to their company specifically. I'm not 100% sure on that, so don't quote me on that. But they're all very, very similar. They're all good documents to follow in terms of engineering best practices. So those are the ones that I can recommend. Okay. Any other questions before we call it for today? Okay, so hopefully I have shown you a couple of ways to test your plugins for PHP 8. The manual way, as I mentioned, is the easier of the two, which requires the least amount of dependencies, but it is the most time consuming. The PHP compatibility method requires some dependencies, requires some setup is the quickest, but it has some missing pieces. Combine the two and you should have a good combination. One of the other final bits of it that I can give you is if you're working on your own, find someone else that you trust and let them think about testing your plugin because when you find somebody who doesn't work with the plugin and they start testing it, they find problems very, very quickly and start listing the things, the steps that they take. When I was working at Kastos we had a testing doc and a manual testing of all the things we had to test before release and every single person in the team went through that and tested those things and you can unit test and integration test all you want, but sometimes there's no better thing than just somebody sitting and testing it manually. But make sure you're doing those tests, use the compatibility tool and hopefully you will be able to get your plugins updated and get yourself going for future versions of PHP. Last but not least, keep an eye on those mailing lists, keep an eye on those updates, even if you just make a point of visiting the PHP manual pages and going to that appendices section where is it, it's in the documentation English I'm not going to find it, it's down the bottom here somewhere. Here we go, appendices and just keep an eye on this page some folks have a script that runs on the page and checks for things the PHP project is pretty good at keeping the site updated with the animation so do keep an eye on that otherwise thank you all for joining me today I hope it was informative and interesting if you do decide to install Composer at a later stage and you get stuck you're welcome to reach out to me, I'm always glad to help if I can I do have Mac OS and Ubuntu and Windows around so I can test on all three environments but I do recommend that's something that you get into if you haven't already there are some amazing tools that you can install via Composer for your PHP plugins so do check those out otherwise thank you all for joining me, it was lovely to see you all and next week we're going to be diving into the WordPress database I think that's the plan, I haven't checked it but otherwise, enjoy the rest of your Thursday, enjoy your weekend and I'll see you all next week