 All right, recording is live. So welcome everybody. Adrian, lovely to see you this week. I hope you are well rested from your WP Accessibility Day last week. For those of you who don't know, Adrian and I were, well, Adrian was actually one of the organizers. I just volunteered for the WP Accessibility Day sessions last week. It was a 24 hour event. And Adrian and I, I think, discovered a new hatred for Zoom during that event. I think we're gonna have lots of user experience suggestions and things to suggest to the Zoom folks. It was certainly an interesting day. There is nothing, Adrian will probably agree with me on this. There is nothing like a shot to the heart of adrenaline when you realize you can't enable the American Sign Language Interpreter video correctly while the session is going. It's quite an experience. We had that a few times. So yes, that was fun. Was it not? I don't know if you are, I don't know if fun is the word that I would use. Anyway, welcome to everybody else. Sorry to go off on a tangent there, but yeah, it was just interesting to chat about. Welcome to everybody who's joining us. As you are joining us today, please let us know where you're joining us from. I just realized I don't even have my welcome slide. How terrible. So please let us know where you're joining us from and maybe share a little bit about what you do with WordPress. How do you work with WordPress? How do you use WordPress? As we get started, I'll do my introductions. My name is Jonathan. I live in Cape Town in South Africa. I'm wearing a short sleeve today because it's starting to get warmer here. Yay, we're finally getting spring weather at last in October, which seems very, very weird to me. But yes, I'm starting to be able to work in a T-shirt and not have to wear multiple layers of clothing. So that's always good. I am a developer educator at Automatic and I'm sponsored to work with the training team. And what that means is I create tutorials and workshops like these and lesson plans and courses. And we recently launched something called a course cohort where we run a live cohort to folks joining a course. So I do all kinds of things like that with the WordPress training team. If you want to find me online, best place to find me is at my personal blog. It's jonathanbossinger.com and all my multiple social media platforms all linked up there. All right, so as I know, we have Adrian in the chat who said I'm surprised Jonathan even didn't come back to the sessions. No, not at all. I'm more than happy to have you back. I enjoyed it, I'll be honest. I did enjoy the day, it was fun. I definitely, I said to, for those of you don't know, the other organizers were Amber and Joe and a few other folks, but I was saying to Joe that I'd be more than happy. Now that I've learned how to do it, I'd be more than happy to come back next year and help out in the UTC time zone. We've got Mark from Issaquah. We've got Anatoly, welcome from Ukraine. Welcome Anatoly, good to see you again. Kai from San Francisco, Diana from Florida. Benja from Bangladesh, welcome. Arto, welcome back from Frankfurt. It's lovely to see folks that I know and recognize. Jim from Philly PA, casual developer retired. I like that, Jim. I look forward to being a casual developer retired one day. But maybe that's what I am now. Hello, Cynthia from Ontario, Canada. Cynthia says the colors are beautiful right now. I pulled WordPress sites and educate people on how to use WordPress, correct. And Cynthia, can I just say how lovely it is to see colors spot properly? Apologies to all my American friends. I'm from Beijing, is from Anaheim, California. We're going to be 35 degrees today. Wow, that is warm. And John is from Chicago. Excellent, welcome everybody. Cool, I think we can get going. I think everybody who wants to be is here. If anybody else does join as we go along, I'll let them in. Today we are chatting about PHP compatibility testing using a tool called PHP compatibility WP. Now, if you feel like you've heard about this before, it's very possible because I literally a month ago, no, two months ago, August the 10th, so just under two months ago, I hosted a workshop on this exact topic. And during the process of hosting that workshop, I then created a tutorial on it. And then, and this is a fun little bit of backstory into how my day went that week, the creator and maintainer of one of the maintainers of the PHP compatibility snuffs, who is also the creator of the PHP compatibility WP snuffs, contacted me via GitHub and pointed out all the errors in my tutorial. So that was great because now I've got brilliant feedback from the person who works on this project every single day, which is what we're going to be focusing on today. I'm going to be sharing the majority of the updates to that workshop will be from that feedback that I got from Jennifer. So that was amazing. But yes, I did have to, I didn't have to put my ego aside a little bit and just listen. Sorry, not Jennifer, Juliet, her name is. So Juliet is the person who maintains PHP compatibility WP. She's one of the maintainers of the PHP compatibility snuffs. She also does various other things in the WordPress project. And yes, I love the fact that she did care enough to give me that feedback. It was really, really great. So it'll help me create a better workshop now and update the tutorials. The tutorial is better. And so that's why we're doing this again today. All right, a few announcements before we get going. First of all, welcome everybody. I hope you are all well today. I don't have a co-host today, so please bear with me if I have to jump off and admit folks or look for questions as we go along. Please let me know if you can't see my shared screen right now. So right now you should see a slide that says announcements on your screen. If you don't see that, please let me know. Or at any time during the course of the session, if you can't see what I'm sharing on screen, let me know in the chat and I will re-enable the share. As always, we are presenting in focus mode. That means I can see all of your video, but you can't see each other. This just prevents any kind of zoom bombing problems that we have had in the past. If you would like to enable your video, you're more than welcome to. It's always easier for me to interact with folks if they enable their video. I do see a couple of folks have enabled their video. So thank you, I appreciate that. But you don't have to enable your video. If you don't want to, I totally understand. Literally the other day, I was hosting on Wednesday. I was hosting a session in my home office, which is in our bedroom. And there was all kinds of stuff behind me. And so I just blew it out my background. And I would have preferred to not have my video enabled that day. So I don't expect you to enable your video. You are, as always, welcome to ask questions. You're welcome to post them in the chat or ask them verbally if you want to unmute. The only thing I do ask is if your question is not specifically related to what we're doing, then rather post in the chat or keep it for when we have breaks for questions. But if I'm going too fast or you don't understand something, then do stop me and let me know. And it totally says, where are your brilliant notification about speed talks? I'm not actually sure. I need to go and have a look for that one. OK, so as I mentioned, this is an update to an existing workshop. So this workshop recording, I will upload over the previous workshop recording, and I will share it with you in the Meetup channel tomorrow if you want to watch this again. But because it's an update, I don't want to keep the old one around. So do keep an eye out for that. As always, if I start going off too fast, if I start speaking too fast or something isn't clear, please do slow me down and let me know. And then if you're looking for more developer resources, you can go to learn.wordpress.org, which is the site where we post all of our lesson plans, tutorials, where all the courses exist. You can also go to the recently launched WordPress Developer News blog, which is at developer.wordpress.org slash news. I will share that with you in the chat now. And then finally, the 2023 annual WordPress survey was released recently. And this is a survey that the WordPress project hosts every year, and we try and get feedback from WordPress users all over the world of every different type and job role and whatever the case may be. So this is not specifically for developers. It's for anybody using WordPress. So if you would like to take a few moments, I think Tracy, who was hosting with me last week said it took him about 15 minutes to complete. So I don't think it's going to take long, but please do give that a shot. We are talking. I have raised the idea with a couple of people that it would be nice to actually have a developer focused survey as part of the 2023 survey. Something like the Stack Overflow state of developer survey that they do every year, where they ask things like what operating system do you work on, what local developing environment do you use, what tools are you learning, all those kind of things. That would be very interesting for me to know, because that would help me inform all of the content I create. So I'm trying to see if I can make that happen sometime, maybe next year. We'll see how that goes. All right, our learning outcomes for today as mentioned, this is a re-recording, re-hosting of a previous workshop. So our focus today is primarily going to be on the PHP Compatibility WP tool. But we will chat briefly about why you should test for PHP version compatibility in your plugins, where to find more information, how you can do manual testing, and then how you can use the PHP Compatibility tool to do your testing. Then there's also a quick note on PHP compatibility versions because of the versioning at the moment. This is going to change in the future, but it's good to know. And then just some considerations towards the end. Before we go on, I just wanted to check on a scale of 1 to 5, and this is now an opportunity to give you to fire up your keyboards and answer in the chat. One being, you know, little to nothing about PHP compatibility testing. Five being, you've either attended this workshop before or you know it very well. Please give me an idea of what your sort of knowledge level is on this topic. I just want to get a feel for where we all are in the group. OK, so we've got some 1s, we've got some 2s, a few more 1s, a couple of 2s, 1, 3, a couple more 1s, a couple of 2s. OK, couple of 3s, that's great, that's excellent. So we're all kind of on a similar sort of middle to bottom of the scale, which is really, really great. I literally only started worrying about PHP compatibility testing when PHP 8 came out. And I'll dive into why in a second. So it's something that I don't have the most amount of knowledge of. But there is an article that I'd like to share with you towards the end of the session, which is kind of where my understanding of these things came from. And ironically, it's also the article that is one of the reasons my career changed. So if you don't mind a little personal story, I'll share that with you as well. But we'll do that at the end once we've got through all the hard stuff. OK, so requirements for today. Now, usually in these sessions, the whole session that I plan is fully interactive. So everything that I'm doing on screen, you can do along with me if you want to. Or if you're watching this at home as a recording, you can do it while I'm presenting it. Today is a little different. Today is a little more me just showing you things and imparting some hopefully knowledge. I'd like to hope you consider it knowledge, just stuff that I know. But some of the steps you can't actually do in a live environment because there are some detailed steps involved in installing certain pieces of software. So for example, if you're on an operating system, possibly like Windows, and you're not used to using the terminal yet, you might be struggling with what terminals should I use and how should I go about using the terminal. I used to be that kind of Windows users. I know exactly how you feel. If you've never installed, OK, hang on. JS says I'm sorry, but I don't see your screen. Thank you for letting me know, JS. Let me re-enable my screen share. Thank you so much for letting me know. It is important that we all are on this thing together if I can remember how to do screen. Stopping my screen share. There we go. That's stopped. And then we share it again. And JS, if you can let me know that you can see my screen in the chat, that'll be great while I continue. The second thing that you're going to need to use for the major part of today is to have a software package called Composer Install. I'll dive into what Composer is in a few moments. But you are going to need to have that installed. To have Composer Install, there are other requirements you have. We'll talk about that. And if you don't have those two things, then you can't do the rest of the PHP compatibility testing with me. You will be able to see your message there, JS. I'll try again. You will be able to follow the manual testing process. That we'll be able to do together. But when it comes to using PHP Compatibility WP, you will need to have these things installed. And unfortunately, it's just not easy to guide folks through that in a live environment. OK, JS says I still can't see the screen. So I'm going to stop the share again and then re-enable it. And if anybody else can't see it, let me know. JS, if you can't see it specifically, then it might be an issue on your side. Because normally, just enabling the screen share fixes it. So let me do it again. Let me go back to desktop. And let me share that again. And if you can let me know whether or not you can't see that. Otherwise, if you can't see it, the other option is I did share the I'm going to share the link in the chat now. You go to meetup.com. And let me find the link. So what I'm going to do, JS, is I'm going to make two suggestions to you. Number one, I'm going to share the slides with you in the in the chat. If you'd like to open up those, I will also share. And I do this anyway. I share all the links that I open so you can open them in your browser as well. And I'll share any other things or any code that I'm working with. I'll share that with you as well. And you should be able to follow along that way. Otherwise, the other option is catch the recording, which will also show everything. That'll be live sometime tomorrow and follow along that way. OK. Perfect. So there's always a way we can figure this out. So thank you for bearing with us there. All right. Then, as I mentioned, if you want to do the local WordPress manual part, having a local WordPress install will be helpful. Having a text editor will be helpful. And then the plugin code we'll be using. I'll share this in the chat now. I'm going to be using this plugin code. It's a very simple little bit of code. I'll talk you through it when we get there. So those are the things that you that you might want to get ready if you have time to get them ready now. OK, let's dive in and let's do a little bit of theory first before we start diving into the practical. So the first question that was at least the first learning outcome that I have is why would you want to test for PHP compatibility or what is PHP compatibility? And as I mentioned at the start of this chat, I didn't worry about PHP compatibility until PHP 8 came out. So this is the PHP.net website. You'll see that PHP 8.2 is the brand new stable version. And if you go to the PHP Supported Versions page, which I will share with you in the chat and I will paste into my browser here. If you scroll down, there's a Currently Supported Versions table. And you'll see that the current stable version is version 8. It's the one right at the top. It's in orange. It was released on the 26th of November 2022. It had active support up until 10 months ago, until 26 November 2022. So that's bag fixes, feature enhancements, that kind of things. And then it has security support. So security fixes only until the 26th of November 2023. That's literally about a month and a bit away. 8.1 came out in November 2021, active support until 25 November 2023, security support until 25 November 2024 and so on and so forth. Now, I don't want to dive too much into the history of PHP versions and all that kind of thing. But the short version of it is that PHP 5 came out. PHP 5 was quite a big change. PHP 5 was a number of years ago now. And then the PHP developers started working on PHP 6. And PHP 6 went horribly wrong for a number of reasons, which I don't want to dive into today. What it meant was that eventually the PHP developers scrapped version 6 entirely and just jumped straight ahead to PHP 7. What this meant was that PHP 5 had a number of releases in the five, the big major version release cycle. I think PHP 5 eventually got up to 5.6 eventually. And that is not typical, or at least that wasn't supposed to be typical for a PHP release cycle. Somewhere along the line, I can't remember exactly where it was, but somewhere along the line, the PHP developers decided that they would only end up having a certain version for a certain number of releases. You can see if you scroll down on this currently supported versions, 7.4 only went up to 7. Sorry, should I say? Version 7 only went up to 7.4 and then 8.0 kicked over. And it was basically a time-based thing. So they said we will have so much time. If you look at 8.1, for example, it was released a year ago. It stops being supported for security releases in another year. So it's about a two-year period. And they would stick to this two-year cycle. And then at a certain point, they would change up to the new version. So we're probably going to see that 8 ends on 8.2. If we go back to the home page, I don't think there is an 8.3 being developed. 8.3 will probably be the last version of version 8. Maybe I don't know. They might go to a point four. But then soon after that, they'll upgrade again to version 9. So you won't have this big gap like we had in PHP version 5. What that meant was is that because nothing drastically changed over the course of PHP 5, when PHP 7 came out, all the PHP developers thought, or anybody working with PHP thought, we'll have a similar kind of thing. We'll have PHP 7 for years and years and years. And that wasn't the case. When PHP 8 came out, there were a lot of breaking changes. A lot of folks got caught. I ended up actually working on a bunch of sites that when 8 was forced by hosts, the sites just died. And I had to help folks get things fixed up. They reached out to me very late in the game and I had to quickly scramble. It could be an Ubuntu thing. Sorry, I just saw JS's question about the Ubuntu OS thing. When we tested this problem, me re-enabling the screen today seemed to fix it. I have an Ubuntu machine that I'm testing on. So maybe try exiting and joining again, JS, and then we can try the screen share again. But that should have fixed it, unless it's an update that's broken, which is also possible, unfortunately. OK, so when... So if we have a look at WordPress, I'm actually going to just open up the WordPress.org homepage and I'm going to go to the about WordPress page. I'll share the link with you in a second. And the requirements are here somewhere. There it is, the requirements. I'll share the requirements with you. You'll notice that WordPress's minimum required is PHP 7.4 or greater. So even WordPress is taking a while to get up to date. There is a big project underway to get WordPress fully supported and up to date with PHP 8, 8.1 and 8.2 and then be able to move forward from there. Juliet, who I mentioned earlier, is one of the people working on this, which is why she's the perfect person to talk about PHP compatibility. And so the project as a whole is in the process of getting WordPress to a point where we recommend version 8 or greater and eventually version 7.4 will get dropped. One of the other reasons that the project can't recommend anything greater than 7.4 is there are a bunch of plugins out there that haven't updated yet. Some of those plugins are by developers who are just doing it in their spare time and they just haven't had time to do it. Some of it is they've written code that's been around for so long that it's just taking so long to get there. So it is a bit of a process, which is why this workshop, I believe, and this tutorial is so important because if we can find an easy way to do these updates and do these tests, then we can help everybody get their plugins and things updated and we can all move forward from there. Okay. The last thing I want to mention is if you go, sorry, let me just move something off my screen here that keeps jumping in my way. If you go to the PHP home page and you go to the, he says, checking his notes, the appendice in the documentation, so if you click on the documentation on the PHP home page, and if you look on the, now I'm not going to find it, am I? But yeah, first you have to select a language and then there is an Appendicee section which I think is right at the bottom of this page. So right at the bottom of the documentation for whatever language you've selected, there's an Appendices. I will share that link with you in the chat now. This is the English version. The Appendices section contains, right at the top, a history of the project and then the migration guides. So the first one is migrating from 8.2 to 8.3, second one is 8.1 to 8.2 and then the third one is 8.0 to 8.1 and then so on and so forth and all the migration guides exist there. And if we have a look at migrating from 7.4 to 8.0, for example, which I will share with you in the chat as well, you will see it includes new features, backward incompatible changes, which is what we're talking about today, as well as deprecated features. So backward incompatible changes means things have changed and if your code is still using these things, your code will break. Most of these backward incompatible changes would have been deprecated in a previous version. So if you had been testing on say 7.0 or 7.1, you might have known about these changes and you would have probably fixed them by then. But if you hadn't, when your hosting provider or your user's hosting provider forces them to PHP 8, it's going to break. Deprecated features are basically features that they are planning on removing in future versions. So what the PHP developers will do is that once they've made a decision to deprecate something, they will mark it as a deprecation. They will say this is going to change in the future and they will issue a warning. And if you use this code, it will log a warning to your error logs, your PHP logs, your debug logs or wherever, and then you are hopefully warned about it and you can know to do something about it. As you can imagine, the downside of deprecating PHP features in a WordPress plugin environment is if your user is running that plugin or your customer or your whatever and they don't have logging enabled, they're not going to know that logging is happening, that this deprecation warning is happening. They're not going to know to tell you about it. So it is my opinion and my opinion alone, I don't speak on behalf of the WordPress project, yeah, I speak on behalf of myself as an ex-plugin developer who used to maintain a fairly large plugin, services and podcasting, to do this kind of testing yourself, to make sure that when new PHP versions are coming out that you're aware of these versions, that you do testing for deprecations, that you have your logs enabled when you're doing testing and all the things we're going to chat about today. So hopefully if you're not doing this, if you are a plugin developer and you're not doing these things yet, hopefully today inspires you to look at implementing some of these things. All right, I'm going to take a pause there. I see that JS did exit and come back. So I want to give you the opportunity to see whether you can see the screen now. While I take a break and refresh my voice and check if there are any other questions or anything before we dive into how we would do this. Sorry about that, JS. But as I said, watch the recording tomorrow. You'll have to just listen to my voice now and follow along with the links that I share. All right. So the first way that you can test is to manually test your plugin. Now, the way you need to do this essentially is figure out how to get an updated version of PHP running on whatever local development environment you use. So if you're using something like local WP, DevKinster, any one of these pre-built packages, they normally support either, excuse me, installing or using multiple PHP versions. Some of them allow you to, when you fire up a new site, they allow you to pick which PHP version you're using. So you will need to figure out in your local development environment how to fire up a new version of PHP or a different version of PHP to do the testing on. One way that you can check if you're not sure what version of PHP you're using on your local development environment is in the root of a WordPress site that you have, you can create a PHP info page. So you can call this whatever you want. I tend to call mine info.php. And you can use this code in this info.php file. So I'm gonna copy the code into the chat. And it's a simple little PHP function called PHP info. It's really not a difficult one to remember. And it literally will just output all the information about your PHP version, all the extensions for PHP that are installed on your local environment. So if I open up my local site here, which is learnpress, and I browse to this info.php page, you will see that currently this is running PHP version 7.433. That's the current version of PHP that I have for this site. And so that's what it's running on. Now I need to upgrade this. And as I say, depending on your local environment, depending on what you're using, you'll need to go and read the documentation, find out, A, does your local environment support different PHP versions? And if it does, then upgrade to that version. The other thing that you could do, and I'm going to share this with you in the chat as well, there is a new tool that was released recently, earlier this year called WordPress Playground. And if you try WordPress Playground, opens up a browser and it fires up a version of WordPress in your browser. And with this version installed, you can see at the top of the screen, unfortunately, JS, you can't see, but if you load it up your side, there is a little button here that you can select and you can say, I want to run PHP version, whatever, 8.2, 8.1, 7.4, whatever the case may be. And I want to run a specific WordPress version, 6.3, 6.2, whatever the case may be. You can then in this contained WordPress environment, you can install your WordPress plugin. And you will see that if you install your plugin and try and use it and it breaks the site running PHP 8, then you start knowing, okay, there's a problem with your environment and that's a good way to get started. So that's one way you can test it and see what's going on. Sorry, my phone just beeped, so I just want to make sure it's not important. Okay, so on my local environment specifically, I'm using a virtual environment which uses something called multi-pass. So where's my terminal? We just clear this out here. So for me to change things on my environment, I run a command called WP local, which logs into my virtual environment. It's an Ubuntu server. And then I'm going to edit the Apache Virtual Hosts file for my site. This is my virtual site here. And I'm using the PHP 7.4 FPM CGI to run the site on PHP 7.4. The server itself is actually running, I think, 8.1 or 8.2, whatever the most recent version is on Ubuntu because it's an Ubuntu server. So if I simply just comment this out and I restart Apache, then when I browse back to my PHP info, it tells me I'm now running PHP 8.1. So that's the first step, is get yourself a local version of whatever PHP version you're testing to and be able to test your WordPress site on that local version. All right, I'm going to switch that back quickly because we need to show you the working code and then break it. So I'm just going to comment that out if you'll give me a second here. Here we go. And then let's restart Apache and let's make sure it works. Yes, it does work. Okay, excellent. So this is the plugin code. I'm going to share this with you in the chat. It's a very sort of simple plugin. It doesn't do much. It has a post-fetcher class right at the top. And all the post-fetcher class does is it fetches the posts from a WordPress site. So it just calls the get posts function. It doesn't pass it any arguments so that'll get the default to 10 most recent posts. It then loops through those posts and essentially just exports or outputs ahead of tag with the title, the link to the post and the post title. That's all it's doing. This class is being used inside of a short code called PHP learn PHP, sorry, WP learn PHP compatibility. The short code essentially just creates a new instance of the post-fetcher class, generates the post HTML using that fetch posts method and returns the HTML to the browser. So it's very simple stuff, not doing anything overly complicated. So what I'm going to do is I'm going to click on the raw button and I'm going to copy this code so we can create a new plugin from it. And then inside of my text editor, my visual code studio, I'm going to go into the WP content directory. I'm going to into the plugins directory and I'm going to create a new folder called WP learn PHP and I always struggle to spell compatibility, compact T and inside of that folder, I'm going to create a new file and call it WP learn PHP, compact ability dot PHP. And then I'm simply going to paste that code into the editor. So that's the code that I'm working with today. I'm then going to grab the short code. So there it is WP learn PHP compatibility. I think I've already created this page. So I'll show it to you now. The first thing I'm going to obviously want to do is enable the plugin. So if I go into my dashboard, we go to plugins, there is compatibility. So we activated, there it is. And then if I go into my pages, I've already created a post list page, which is in draft mode currently. There the short code is all good. And if I now preview this page, we will see the output. So there it is. There is only one post at the moment. So it's just outputting the one post of hello world. I can click on that that takes me through to that post. So the code is working. So in PHP 7.4, the code works. Excellent. We can call this a day and move on with our lives, no? All right, let's break this code. Well, at least let's break the plugin. So if I switch back to my local environment and I decide, okay, now I want to start testing this on PHP 8, I'm going to disable the PHP 7.4 and I'm going to restart my environment and now I'm going to load that page. And we can see straight away the plugin breaks. Now, so the average user using this plugin, they just see that the plugin stops working. They don't understand why. They don't know where to look for problems. Those of you who've done plugin support, you know, this is a bit of an nightmare. So if you're testing your plugin for compatibility, the first thing that you can start doing is what I like to call manual testing. So if you enable your WordPress debugging, your debug log, you can then see if any of those deprecations that I mentioned or any removal warnings are being logged somewhere. I'm going to find the WordPress debug log because for some reason I didn't include it in my slides. So I'm going to find that link. But this is the documentation about debugging in WordPress and essentially you are going to go to your wpconfig.php file. You're going to enable the wpdebug constant. You're going to set it to true. Then you're going to define the wpdebug log file and set that to true. And then up to you, whether you want to disable or enable the debug display option. What I like to do is I like to disable the display option but leave the log option on just because I don't like all the errors logged to the screen. But that's entirely up to you how you want to do that. I'm not going to tell you either way. If you prefer to see it on screen, that's great. If you prefer to see it in the log, that's great as well. So if we hop on over to my wpconfig file, you will see that I already have my logging enabled and I'm going to just disable that debug log there. Here we go. There's my logging enabled. So I have wpdebug set to true, debug display set to false and debug log set to true. The other thing that you can do, and this is actually my preference and I'll tell you why in a second, is you can, this is a recent-ish addition to the debug log constant. You can define the debug log constant instead of saying debug log true. You can actually point it to a physical file or file name, should I say. And I like to use this format. So I like to say define wpdebug log and then point it to a location that includes a date string. So this is the local path for my local sites. And so I say, put it in the logs directory. So I'll have to create that logs directory. Then call the file debug dot and then concatenate that with today's date. I prefer the year month day format. You can do whatever format you like. The reason I like that is because then every day you start a new debug log and you get the logs for that day and it means you don't have to worry about deleting old logs and whatever on your local environment and whatever you're focusing on for that day you can focus on. If you want, you can even take it a step further. You can say log it by the hour, create a new log every hour or every 24 hours or whatever the case may be. But this is a nice process that I like to use. For this to work, I need to make sure that I create a logs folder in my local WordPress install. There you'll see it there, logs. You could just leave out the logs and just do it in the root and do it in the WP content wherever it suits you. My preference is to do it in logs. With logging enabled and with the debug log enabled if I now browse back to my site where I've got my post shortcode running and I hit refresh, well, you'll see it's actually giving me an error about debug log being defined because I've made another mistake. So let me take that out. But if we have a look at the log file now, okay, now it's not gonna work because I had a different area. Sorry folks, there we go. If we go and have a look at the log file now, there it is. And there we will see it says right at the top of this page let me enable word wrapping here. PHP warning for each argument must be of type array or object null given. It tells you what line of code the issue is existing in. So it's in the WP learn PHP compatibility on line 21. So that at least gives us an idea of where things are going wrong. If I go over to that plugin and I scroll down to line 21, I'll see it says, okay, it's in the four each. So in the four each, I'm trying to four each loops through a series of arrays or sorry loops through an array. I'm trying to loop through something which is supposed to be an array but for some reason it's not. So let's go back to where I get this post from. So this post is set up in the class constructor this one over here, public function postfetcher. It sets up this post and it calls get posts. So this was working. So that must mean somewhere there's a problem here. Now the downside, this is why I wanted to show you the manual method versus PHP compatibility WP. The downside to this method is it doesn't really give me a lot of good information. It just tells me there's an error in the four each loop but then it doesn't tell me in the class what the problem is. If you go to the deprecated, sorry, not deprecated features, if you go to the backward incompatible changes for PHP eight and this is where you kind of, you need to have been watching this, you need to have been reading these things and you scroll down a little bit. You'll see here, I'm going to find it now. Hopefully I'm going to have to search for it. I can't even find it. Let's just go, oh, there it is. Here we go, here we go. It is the, if you open up this page it's under other incompatible changes. It's the one, two, three, fourth one down. It says the methods with the same name as the class are no longer interpreted as constructors. The underscore underscore construct method should be used instead. Now, if you've never worked with a class before this might be completely new to you and I would understand that, but essentially in PHP four when classes were first or at least when object oriented programming was first added to PHP, your, what they call the class constructor the function that automatically runs when you create a new instance of this class was named the same as the class itself. Later on that changed and you could use what's known as the underscore construct method. And then in PHP eight that was made the default way of doing it. So let's say for example someone wrote this class in this plug-in that you're managing years and years and years ago and it's sitting there and it's been working ever since and you've now picked up this error. You're not gonna really know what's going on unless you've been following these changes. So it does make the manual method a little bit more difficult to kind of figure out what's going on. However, with this change made so I basically changed I'm gonna just copy it in the code. So this was the old code for those of you who are following along and then the new, yeah, I've lost everything. What have I done? There we go. The new function looks like this underscore construct, let me get rid of this. So this is what we update that code to in the plugin and if I now run this on my WordPress site things should be happy and good to go. And there we go. My short code is working again happy days we can call it a day. All right, so that's the manual method. Are there any questions on that before we carry on? Otherwise I want to go into how we can use PHP compatibility WP. There, we don't seem to have questions. So we're gonna dive straight in. The other thing that I wanted to mention is while manual testing is great. This is a very simple plugin. It has 44 lines of code. If you're working with a plugin that's been around for years it has hundreds and hundreds of lines of code. For you to manually test every single possibility is just not gonna work. So there's this thing in PHP LAN called automated tests and we use a tool called PHP unit. Now PHP unit is unfortunately not something that is in the scope of this workshop today. I am planning a workshop on how PHP unit works and how we can use it to write unit tests for our PHP code in WordPress. But if you can get into the framework of automating your tests. So in this example, you would write a small piece of code that creates an instance of the post-fetcher class and essentially let me just show you how that would look. So I'm gonna create a random test. Now this may or may not work but I wanna show you an example of what it could look like. So if we create a test folder you would create something like this WP test. Let's say short code for example and inside of your test you would have certain classes and things set up but then what you would do is inside of your test you would essentially use this code. You would say, so let's say this was your just this way, class. This is very much pseudo-code so don't quote me on this kind of code and what it should look like. So you'd have something like class test post-fetcher and it would have a test post-fetcher method and then you would do something like this. You would say create a new instance of post-fetcher, fetch the post into the post HTML and then you would use something called assertion. So you would say assert and then you would say something like insert contains might be one example and you would say the post HTML contains maybe let's look at a good example contains an H4 tag could be a good example. So you could do something like that and then you would make sure that it does certain other things. So you would basically use the test code you would then be able to run this test code against your code and if the test fails then you know something's gone wrong. So automated testing is better than manual testing and manual testing is good and if you're not doing any testing I recommend manual testing but if you can switch to automating those tests even better because then you can just every time a new version comes out you can run your automated tests you can check for failures and then when you see those failures and then making sure your tests are running over all of your code when you see those failures you can then look into why those things are failing and what you need to do to be able to fix them. Okay, I'm just going to do that. All right, so that's automated testing. So I don't need to do really with compatibility but it helps with compatibility testing. Now let's talk about PHP compatibility WP itself. So PHP compatibility WP is a, let me just open up the file here. Give it here and let me get the link in the chat. PHP compatibility WP is a set of rules for WordPress projects that you can run against your WordPress code and look for compatibility issues. PHP compatibility WP is runs on top of something called PHP compatibility. I'm going to close down some of these tabs because they're just getting bigger and longer here. So I'm going to close some of these down. And so what PHP compatibility does is it allows you to test any project against future versions of PHP. PHP compatibility WP is specifically for WordPress projects. So it has specific rules and checks for WordPress code, WordPress functions, WordPress functionality. And that was one of the things that I didn't know. I didn't know there was a WordPress version of PHP compatibility. And that was one of the things that Juliet pointed out to me is there's very specifically a WordPress version that you can use that you can run on your local environment. So we're going to be talking about all three of these things. PHP compatibility WP, PHP compatibility. And then PHP compatibility you'll see is a compatibility check on top of PHP code sniffer. Now PHP code sniffer is another tool that I could do a workshop on another time and probably should. Basically PHP code sniffer is a tool that you can run on your code to check that you're following a certain code standards. And if you've never noticed before when I write my PHP code, I'm going to make some changes here. I'm going to just remove some spaces just to do that, that nut. When I write my PHP code, there's a command in the VS code that Adrian kindly shared with me how to do. But if I hit that keyboard command, you'll notice a change happened to that function. It automatically pops the spaces in between the function parameters. Now that's very specifically a WordPress coding standard requirement. So I have an extension for VS code install which is connected to PHP code sniffer another tool called PHP beautifier set to the WordPress coding standard. So when I'm writing my code, either when the text editor saves the changes or when I hit that keyboard shortcut, it automatically scans through my code and makes all those fixes for me. It's a great time saver if you're like me and you like to follow standards. But we'll do a workshop on that another day. For today, what the PHP compatibility tool does is it uses the code sniffer functionality of reading through your code and checking for code standard issues. And what it does is it looks specifically for PHP compatibility issues. So it has a list of all of those deprecations and all of those warnings and then it checks for any of those. To use these tools, you need to have something called composer installed. So composer is a package manager for WordPress projects. You don't have to use composer if you're developing for WordPress because most of your dependencies or your packages that you're gonna use are inside of WordPress. But it's great for using external developer tools like PHP compatibility WP. For composer to work, you do need two things. You need a terminal to run commands in and then you need to be able to run PHP scripts or PHP commands from the terminal. Now, if you're on a Windows environment, this may or may not be tricky if you're not used to running in a terminal. What I found to be a good terminal to use in Windows is something called PowerShell. I do recommend installing the PowerShell version from the Microsoft website. So I'm gonna go there quickly. So it's just Microsoft. You can actually just go to microsoft.com forward slash PowerShell. And then from there you can download the installable, install it on your machine and then you will have this version running. There is, I noticed in Windows 11, I upgraded my, I have it, not that screen, that screen, that's another screen. That screen behind me. That's my sort of workstation for doing Windows and Linux testing. And so I have Windows on one boot drive and Ubuntu on the other. And I updated it to Windows 11 recently and discovered that Windows actually ships with a PowerShell now as well. So there is a Windows PowerShell and a Microsoft PowerShell. And I did a bit of research and apparently the Microsoft PowerShell one, the one that I'm pointing to here is a little bit more powerful. It can do a little bit more. So that's why I recommend it. But I believe that what I'm proposing you to do in the Microsoft PowerShell is also possible in the Windows PowerShell. So that's my recommendation for Windows users. Once you have PowerShell installed, then you can install PHP either manually or you can use something called Chocolatey. Now Chocolatey is something that I discovered very, very recently. I'm gonna share these links in the chat for my Windows users and I'll include these as well. Chocolatey is like a package manager for Windows. You can install all kinds of software using Chocolatey and you can install PHP in Windows using Chocolatey. So if you go to the Chocolatey packages and you search for PHP, it comes up with a single command, Choco install PHP, it installs PHP for you and you're good to go. What I like about this method is the way Chocolatey installs your packages. It installs it inside of a directory in the root of your Windows install called tools. And everything that you install through Chocolatey is installed in that tools directory. One of the things that I used to hate when I was still developing on Windows is sometimes a tool would install itself because it's a 32 bit tool, it would install it into the program files, x86 directory, or it would install it in the program files directory or it would install it in my user directory. And I found that very frustrating. What I like about Chocolatey is everything is under tool so you can always find it there, no problem. Once you've got that done, then you can just install in Windows, there is an installer, a composer setup.exe. I actually have a video, I'm gonna just share with you quickly that I recorded the other day of myself installing this process. And if you're not a Windows user in this session, I do apologize, but I'm doing this for anybody who might be a Windows user and needs to know how all this work. So here's the video of me setting things up. And essentially you install, Choco install PHP, that works great. Then when you install Composer, it automatically picks up, I'm just trying to get, there we go. It automatically picks up that PHP is installed in that tools directory and then installs Composer for you and you're good to go. It sets up your paths, it does everything else for you. So if you're on Windows, that's my recommendation. PowerShell, Chocolatey and then the Composer installer. If you're on a Mac, which is what I work on, then I recommend installing something called Homebrew, which is a package manager for Mac. I've said this before, I'm gonna say it again. I do find it interesting that in Windows, the package manager is to do with chocolates and on a Mac, the package manager has to do with beer. I don't know what that says about Mac developers and Windows developers, but it's a simple single command you can use. So it's this command in the middle of the page here to install Homebrew. You copy this, you stick it in your terminal, you run it, Homebrew will be installed. You can then install PHP in the same way you can with Chocolatey. So instead of Choco install, it's brew install on Homebrew to install PHP. And then you follow the Composer instructions for installing it on a Mac, which is right at the top here. There is also a Composer executable there that you run. You install it that way. If you're on a Linux environment, like Ubuntu, one of those, it's a similar process. Generally on Ubuntu, PHP can just be installed using the app package manager, YAM on other environments. And then Composer, you follow the same instructions for the Mac environment. As I say, I can't talk you through this whole process because it takes you about an hour or so to get this all installed. But to know that you've got it working and running and will work is if you open up your terminal and you run PHP minus V, that'll tell you you've got a working PHP version running. In this case, you can see I'm running 8.0.3 on my local Mac. And if you run Composer minus V, it'll tell you there's a Composer version running. It gives you a whole bunch of options. There I'm running Composer 2.3.5. So those are the two commands that you can run to test that everything is working. If you can run PHP minus V and Composer minus V, then you can do the next steps, which is setting up PHP compatibility WP. All right, those are a lot of words. So I wanna take a break and just check if there are any questions before we dive into how we would actually get the setup and running in our project. And I'm going to close down some windows as well. And then I'm also going to, I'm gonna leave, I'm just gonna see what we have here. Leave this, I think it's on 7.4 at the moment. Now I'm gonna switch this back to 7.4. This is my local environment. So I'm just going to open up a new tab. I'm gonna switch this back to 7.4 and I'm gonna show you why in a second. Not that one, not that one. Restart, no, don't, not exit, restart, come on. There we go. Okay, so I'm running on 7.4, excellent. Okay, so running on 7.4, let's set the code back to what it was. So let's go back up here. It's still on post-fetcher, so that's the old code, excellent. So now let's see how this works. Okay, to install PHP compatibility WP, let's open that up again. The instructions are on the GitHub repository. So it does make it a lot easier for you. Essentially, there's a few things you need to do. Before you can install it, you need to do what's known as initializing your project to use composer packages. That one's fairly straightforward. You open up your terminal and you browse to the location of the plugin that you're wanting to work with. In this case, my plugin is in my sites directory under learn, press, WP contents, plugins and the name of the directory that I'm in. Inside of that, you run the following command, composer, init. And what this will do is it will ask you a series of questions. If you've never used composer before and you are only doing this to run PHP compatibility, you can just accept all the defaults for these questions. The only time you don't want to accept the defaults is when it asks you about whether you want to define your dependencies or not. So you would say no to both of those. And you can skip the auto load mapping unless you're using auto load mapping, which if you did, you would know you could accept this but you can skip that. That creates a very simple package.json file which looks like this. So it asks me, do I want to generate? I say yes. And if you now look at your local directory, sorry, not package.json, composer.json file. So the composer.json file is the file that composer uses to manage which packages you're installing to use in this project. And you'll see it's got the most basic, just the name of the project, the authors in this case, me and any requirements. So the require part is any dependencies you're going to use. In our case, we're going to be depending on what you're using PHP compatibility WP. To do that, if you'll see down here at the installation instructions, I'll share this with you in the chat as well. There are essentially two commands you run. The first command is this composer config allow plugins, dealer direct PHP code sniffer composer installer. So that allows PHP compatibility WP to install PHP code sniffer. So we run that command first. So I'm going to pop that in the chat as well as run it in my terminal. Let's just clear this. Yeah. And we'll paste that there. And now that's enabled. So that's all we need to do. Then the next step is to install the two packages. The two packages are as follows. I'm going to share this in the chat. I'll paste it in my terminal and then we'll go through it together. So you run one composer require command. You pass it the dash dash dev option, which means install this as a dev dependency, meaning only want this for development purposes. The two packages are dealer direct PHP code sniffer installer and PHP compatibility WP. Those are the two requirements. You could do this in two separate commands. You could compose or require PHP code sniffer installer version seven and then separately compose or require dash dash dev PHP compatibility, compatibility WP, but one command also works. So when I hit into now, that updates my composer JSON, which I'll show you the update in a second. It connects to the packages.org. I think it is where all these packages are hosted or GitHub, if they set up for GitHub, it installs them into your vendor directory, which I'll show you in a second and then sets up your project to use them. So those are the changes that happen. If we have a look inside VS code, I want to dive through the changes with you. But it is my VS code, there is. So now inside of my PHP compatibility directory, I have a updated composer JSON and you'll see it's changed required to require dev and it's composer installer and PHP compatibility WP. There's the allowed plugins that we added. We set that to true. So we're saying allow that thing to be installed. This is the vendor directory. So the vendor directory installs all of these requirements, all of these dependencies. So there's all the dealer direct things. There's the PHP compatibility things. Squizlabs is the one that manages code sniffer. So this is where all this stuff gets installed. It also creates what's known as a composer lock file. This is if you want to add this information to your GitHub repository or SVN repositories. Essentially, if you commit the get composer.lock file and the composer.json file, you don't need to commit the vendor directory. When somebody else checks out this code, they just run composer install and based on those composer.json composer lock files, it'll go and do all the installations and everything for you. So vendor directory, if you are committing this code to GitHub somewhere, you shouldn't be committing the vendor directory. Right, that's all installed. That's all we need to do to install it. Now we need to use it. And so to use it, you'll see that you can run and it talks to you about running vendor bin PHP CS minus I or more specifically, you can apply it with a specific standard. So vendor bin PHP CS minus P dot dash dash standard. What does this mean? This means run the PHP code sniffer PHP CS tool dot P is path. So in this case, run it on all the files and then pass it the standard PHP compatibility WP. Now, what we're going to do today, or at least what I'm going to do today is we're going to just run it on the one file because that's the only file that we need to test it on. So I'm just gonna find that command here very quickly and then I will paste it into the chat. So that's the command I'm going to run. I will pop it into my terminal and show you what we're doing there. So there I'm running so it's vendor bin PHP CS that's inside the vendor directory. I'm setting the runtime test version to 7.4 or greater. So I'm specifically saying I'm on 7.4. I want to test for 7.4 or greater because ideally you should be testing for whatever version you're currently, you know it's working on and future versions. And then as you upgrade to those future versions, you upgrade your runtime test version. And then finally, I'm running it on one single file. The reason I'm doing this is because I don't want it to run on the vendor directory. I just want it to run on the single file. You can use XML files to set up your PHP code sniffer to exclude the vendor directories, which is not something we've got time for today. So I'm just running it on the single file. When I run this command, you will see that it gives me a lot more useful information. I'm gonna pop this in the chat so that folks who might not be able to see this can see this information as well. But you'll see first of all, it tells me what file it's running against. It tells me how many errors and how many warnings have been run. So if there were more, I would know about more. And then it specifically tells me warning, the use of the deprecated PHP 4 style class constructor is not supported since PHP 7. That is way more useful than the previous error I received. And that's why I was saying, automated testing or manual testing, if you must with PHP compatibility is a great combination. So you can run the manual testing and see where the error is happening. You can run the compatibility and see what the warning is and what it's about. And then using that information, you can much more easily determine where the code needs to be fixed. Here it tells me the class constructor. So I really, I know, okay, I need to look for it in the class. The class constructor, okay, the PHP 4 version, the post feature method, okay, now I know what it's talking about. So it's a lot more useful. And it's why you can't rely on just one or the other as a possible solution. Okay, I'm obviously not gonna go and fix that now because we have fixed it previously, but I just wanted to show you how that works and how you can use it. Are there any questions around how we install that, how we use it before we just wrap up and just chat about a couple of considerations and a couple of notes on PHP versions, PHP compatibility versions. I did say today was a lot of theory. So I hope folks are very with me. Okay, the first thing I wanted to mention is that currently PHP compatibility, not PHP compatibility WP. So let's get PHP compatibility open. Currently PHP compatibility, if you scroll down to the releases on the right hand side of the page is that PHP compatibility version 9.3.5 and this was released in 2019. So that's the last stable version of PHP compatibility. A lot has changed since then in terms of PHP, in terms of this tool. All of those changes are included in what's known as the developed branch of this repository. And when you install PHP compatibility the way I just showed you where you run just the install PHP compatibility with the stars, the version, excuse me, it will install the latest stable version which is 9.3.5. If you want to run the most recent version of the code there is a way to do it. And the WordPress VIP documentation actually has a section in there documentation on how to do that. Essentially what you do is you set up, you'll see that the command is here. I'm gonna zoom in on this a little bit so we can see it a bit bigger on the screen. You use the composer config command to set the minimum stability to dev. And then you require PHP compatibility WP and you require PHP compatibility and you set it to dev develop as 9.99.99. What that means is alias, the dev, the developed branch as version 9.99.99. So because there is no version 9.99.99 but it is 9.3.5 that is the highest version number you can go before 10. So if 9.3.6 comes out or 9.3.7 comes up you'll still be getting the developed branch and 9.3.5 and 6.7 or at least 6.7.8 won't come out. Everything's happening on develop. But it then means when 10 does come out then all you need to do is update your version for PHP compatibility WP to the new version which will be, if we have a look at WP I think it's on version two. So when the new version of PHP compatibility WP comes out and it'll be version three you will only need to update your compatibility WP version to version three, remove the compatibility this one and it'll then do the necessary. So if you want to go that route you can do I'm not going to do it now but there is that option if you want to go that route. And then the last thing I wanted to mention is that the thing to understand about all of this is you can't run one option without the other. So you can't just run PHP compatibility and think that it's going to pick everything up and you can't just do the manual or hopefully automated testing and think that's going to pick everything up and I'll tell you why. I'm going to go back to the migration guide. In the migration guide one of the backward incompatible changes was that the option to use array key exists. I'm going to copy this into the chat so that we can all see it. The ability to use array key exists with objects was removed. Now you might think, but hang on it's array key exists, why are you using it on an object? Well, before property exists or before options existed to use it that's what folks could do because that's how PHP worked. And then as PHP became more strict with these things they started deprecating some of these things that you shouldn't be doing and now in more recent versions they've removed it. The problem with a tool like PHP compatibility is if you have a look at that code where we are doing property exists here. Let's say I was doing array key exists here and I would be passing it in the post and I would be passing it in the post title the key to look for. The sniffer that scans through my code it has no idea of what's inside of that post. It doesn't have context about the fact that I'm calling posts and get post returns and an array of objects. So when I loop through this posts every post in that array is an object. It has no idea because how can it? It's just scanning the code. It doesn't have context of what's happening in the background. So PHP compatibility will take you to a certain point and then automated or if you have to manual testing will take you the rest of the way. And so that's why it's a good idea to use a combination of all three. And as I mentioned earlier and I'm gonna go and find it here quickly there was a post that I wrote for the WP Taven site. If you've never heard of WP Taven it's sort of a new site in the WordPress space. I think it was just called preparing or pair your plugins and you see if I can find it. Where there it was, I saw it there. Pairing plugins, no it wasn't that one. Maybe it was just PHP 8. I really should have looked for this before we did this. They're getting your WordPress plugins and themes ready for PHP 8, there it is. November 25, 2020 by some fool. So in 2020, folks like Juliet, folks like myself we knew this was coming. We knew PHP 8 was coming. It was going to affect folks running their WordPress plugins on all the versions of PHP. And I interviewed Juliet in this article and right at the bottom I asked her what should folks be doing? And she says, run PHP lint over your code, run PHP compatibility, run your unit tests, your integration tests, run WordPress tests. So there's a lot more that you should be doing using PHP compatibility WP and either an automated or a manual testing process will get you a lot of the way there. But you really need to be making sure that you're testing your code for these newer versions. If you get your code up to date with PHP 8 then it's easier to update with PHP 8.1, 8.2 and if you get into that habit and get into that process it's easier to then update to newer versions as they come out. The PHP world is becoming more strict when it comes to how things are done. So this is something that I highly recommend to all plugin developers to start integrating into your process if you aren't already theme developers as well. Themes don't tend to use a lot of functionality outside of core WordPress functionality. So it's easier to keep themes up to date with PHP versions because if WordPress is up to date and you're using WordPress theming functions you should be fine, especially with block themes even more so, but specifically for plugins if you're using any functionality that's over and above WordPress core functionality then make sure your plugins are updated and being tested for newer versions as they come out. Make it part of your process, part of your continuous integration, part of your automated testing, make it part of how you develop your plugins. All right, that is my bit for today. As I said, it was a lot of knowledge, a lot of theory, not a lot of practical because it's really the practical is just doing it every day. If you do have any questions on all of this please do feel to reach out to me. You can find me in the making WordPress Slack. You're welcome to also comment on any places you see me floating around or email me directly. My email address is on my personal blog. But thank you very much for your time. I hope that you have gone at least from a one to a two or a two to a three or a three to a four in understanding how this works and why it's important to do it. I just wanna check if there are any other questions on all of this before we wrap up today. While I have one last sip of something to drink. Thank you to Jim for the way over there. I appreciate that, Jim. We don't seem to have questions. Awesome, perfect, great. Thanks folks, have a great day. Have a great rest of your week, rest of your weekend and I'll see you next week for another workshop on something that I haven't figured out yet. Bye-bye. Have a good day, Jim.